i-MSCP (internet Multi Server Control Panel) was a free and open-source software for shared hosting environments management on Linux servers. It comes with a large choice of modules for various services such as Apache2, ProFTPd, Dovecot, Courier, Bind9, and can be easily extended through plugins, or listener files using its events-based API. Latest stable is the 1.5.3 version (build 2018120800) which has been released on 8 December 2018. The i-MSCP is no longer under development, although the developer has repeatedly claimed to be working on a new version, which has never has been published or even shown in any possible way. Whether development occurs or not, the current version of the software is not installable, as it only supports outdated versions of systems for which some of the necessary software to install i-MSCP cannot be installed. == Licensing == i-MSCP has a dual license. A part of the base code is licensed under the Mozilla Public License. All new code, and submissions to i-MSCP are licensed under the GNU Lesser General Public License Version 2.1 (LGPLv2). To solve this license conflict there is work on a complete rewrite for a completely LGPLv2 licensed i-MSCP. == Features == === Supported Linux Distributions === Debian Jessie (8.x), Stretch (9.x), Buster (10.x) Devuan Jessie (1.0), ASCII (2.x) Ubuntu Trusty Thar (14.04 LTS), Bionic Beaver (18.04 LTS) === Supported Daemons / Services === Web server: Apache (ITK, Fcgid and FastCGI/PHP-FPM), Nginx Name server: Bind9 MTA (Mail Transport Agent): Postfix MDA (Mail Delivery Agent): Courier, Dovecot Database: MySQL, MariaDB, Percona FTP-Server: ProFTPD, vsftpd Web statistics: AWStats === Addons === PhpMyAdmin Pydio, formerly AjaXplorer Net2ftp Roundcube Rainloop == Competing software == cPanel DTC Froxlor ISPConfig ispCP OpenPanel hestiacp Plesk SysCP Virtualmin
Spatiotemporal reservoir resampling
Spatiotemporal reservoir resampling, commonly known as ReSTIR (from "Reservoir-based SpatioTemporal Importance Resampling"), is a collection of computer graphics techniques for reusing samples during rendering. It was developed primarily to allow more realistic lighting in real-time rendering, because relatively few rays can be traced per pixel while maintaining an acceptable frame rate. It can also be used to speed up off-line path tracing. The first ReSTIR paper, published in 2020, provided algorithms for direct lighting, allowing scenes containing thousands of lights to be rendered in real time on a high-end GPU. Researchers later proposed versions for rendering indirect lighting (and more recently, motion blur and depth of field) and built up a framework of mathematical concepts and notation conventions that help analyze such algorithms. A major focus of this work is removing or reducing the bias that could be introduced when samples from other pixels or frames are reused—or selectively allowing some bias in order to speed up rendering and reduce variance (visible as "noise" in the image). Versions for path tracing apply transformations called shift mappings to samples, typically reusing parts of paths closer to the light and modifying the portion closer to the camera. ReSTIR-related papers and talks have been presented every year at the SIGGRAPH conference since 2020. One of the first games to incorporate ReSTIR into its rendering was Cyberpunk 2077. == Overview and motivation == According to Chris Wyman, one of the co-authors of the original paper, although developers commonly thought that bias was acceptable for real-time rendering, end users (e.g. gamers) are well-aware of the artifacts caused by bias and many have a negative opinion of common sample-reuse techniques such as temporal anti-aliasing (TAA), which may cause "ghosting" when the camera moves, and denoising, which causes blurring and other artifacts. ReSTIR techniques can reduce or avoid these types of bias by reusing samples of the set of possible paths taken by light to reach the camera, instead of reusing rendered pixel color values (which are typically the average of multiple samples, discarding information such as the direction of the light). While other techniques reuse samples in a generic post-processing step, ReSTIR passes can test for shadowing, and reused samples are converted into pixel color values by rendering code that takes the characteristics of different materials into account (e.g. by implementing BRDFs). However the output of ReSTIR is noisy, and a denoising pass is typically still used. Stochastic ray tracing techniques such as path tracing need to average multiple samples (produced by tracing individual rays) in order to render a visually acceptable image. When using a simple unbiased renderer based on Monte Carlo integration, halving the deviation of the result (apparent as "noise" in the image) requires multiplying the number of samples by four, meaning that a rapidly increasingly number of samples is needed to improve quality, Standard ways to mitigate this problem include importance sampling (which requires finding improved sampling distributions for specific situations), and quasi-Monte Carlo integration (which usually still requires tracing a large number of rays). ReSTIR offers a solution that multiplies the effective number of samples while tracing a fixed number of additional rays per frame. Temporal reuse multiplies the effective sample count by the number of frames rendered. Spatial reuse multiplies the effective count by the number of neighboring pixels examined. These two types of reuse can be combined, allowing spatial reuse to be applied recursively, which appears to offer an exponentially increasing effective sample count, however this is quickly limited by the size of the neighborhood used for spatial reuse. Spatial reuse is also potentially less effective near shadow and object edges, especially for objects with fine geometric detail, and temporal reuse is limited by movement of the camera and scene elements. == Variations == Many variations of ReSTIR have been proposed that generalize or improve the original technique (which builds on an earlier method called RIS), specialize it for particular types of illumination or other visual effects, or allow incorporation into rendering algorithms other than standard path tracing. Some published versions are listed below. == Algorithms == === Basic algorithm === ReSTIR uses a combination of resampled importance sampling (RIS) and weighted reservoir sampling (WRS) which the authors call streaming RIS. RIS processes samples from an initial probability distribution (e.g. a probability distribution for which a cheap sampling method exists) and generates samples in a new probability distribution (e.g. a sampling distribution that is optimal for rendering but is impractical to draw samples from directly). WRS allows this to be done while storing only a small number of samples in memory, which is especially helpful on a GPU. Information about the samples is stored in a data structure called a reservoir. WRS also allows samples from multiple reservoirs to be combined ("merged") into a single reservoir; this is crucial for sample reuse. Each pixel has a reservoir, typically containing only a single sample when ReSTIR is used for real-time rendering (some implementations use a larger number, e.g. four samples). The reservoir is typically initialized to a sample drawn using a simple method and is then updated by RIS steps and by reservoir merging, so that the pixel value produced by shading using the sample(s) currently in the reservoir, times the weight for the sample, is always an unbiased estimate of the correct pixel value. If appropriate resampling steps are used, the variance of this estimate (or some function of it, typically the luminance of the RGB color value) decreases with each step. A possible sequence of steps performed for each frame, suitable for computing unbiased direct illumination (DI) is: Perform reservoir resampling by drawing multiple light samples and using streaming RIS to choose one, using probabilities based on a target function, e.g. the luminance of the sample's contribution to the pixel. A weight is also computed for the sample. Typically, a single visibility check is performed here, after choosing a sample, setting the weight to 0 if the light is shadowed. Resampling (combined with the visibility check) ensures that the expected value of the weight times the sample brightness is the correct (unbiased) value for the pixel. (temporal reuse) For each pixel, merge the sample(s) from the previous frame into the current reservoir. Multiple importance sampling (MIS) weights are used to avoid bias due to the fact that the samples in the previous frame's reservoirs may have a different target probability distribution if the objects, lights, or camera have moved. (spatial reuse) For each pixel, choose one or more neighboring pixels and merge their samples into the current pixel's reservoir. Multiple importance sampling (MIS) weights are used to avoid bias due to the fact that the samples in each pixel's reservoir have a different target probability distribution. Because computing unbiased MIS weights requires tracing additional rays (along with other work such as evaluating BRDFs), real-time rendering often uses only a single neighboring pixel. Use the sample in each pixel's reservoir, along with its weight, to determine the color of the pixel for the current frame. Alternatively, multiple samples examined during the preceding steps may be averaged and used to shade the pixel instead (decoupled shading and sampling). For direct lighting, the initial samples used in step 1 are typically drawn by importance sampling from the set of lights in a scene. The algorithm above (from the original ReSTIR paper) draws many lower-quality light samples (e.g. 32) using a fast method, without considering visibility, and chooses one using streaming RIS. Visibility is then tested for the final chosen sample. Considering visibility for each sample drawn would require tracing 32 rays, which would make it much more expensive. The intent is to reduce the number of rays traced, relying on the sample reuse in steps 2 and 3 to make up for the loss of quality caused by rejecting many of the rays due to shadowing. A large part of the initial efforts to optimize ReSTIR (to make it run in real-time on available hardware) went into reducing the cost of randomly sampling the lights. Glossy surfaces may require a larger number of samples, and combining light sampling with BRDF sampling (using MIS) may increase quality. Step 2 (temporal reuse) is sometimes skipped for off-line rendering, and the output of multiple repetitions of initial sampling and spatial reuse is averaged instead; this helps avoids artifacts due to correlations. Step 3 (spatial reuse) may be repeated multiple times in a single frame.
Data transformation (computing)
In computing, data transformation is the process of converting data from one format or structure into another format or structure. It is a fundamental aspect of most data integration and data management tasks such as data wrangling, data warehousing, data integration and application integration. Data transformation can be simple or complex based on the required changes to the data between the source (initial) data and the target (final) data. Data transformation is typically performed via a mixture of manual and automated steps. Tools and technologies used for data transformation can vary widely based on the format, structure, complexity, and volume of the data being transformed. A master data recast is another form of data transformation where the entire database of data values is transformed or recast without extracting the data from the database. All data in a well-designed database is directly or indirectly related to a limited set of master database tables by a network of foreign key constraints. Each foreign key constraint is dependent upon a unique database index from the parent database table. Therefore, when the proper master database table is recast with a different unique index, the directly and indirectly related data are also recast or restated. The directly and indirectly related data may also still be viewed in the original form since the original unique index still exists with the master data. Also, the database recast must be done in such a way as to not impact the applications architecture software. When the data mapping is indirect via a mediating data model, the process is also called data mediation. == Data transformation process == Data transformation can be divided into the following steps, each applicable as needed based on the complexity of the transformation required. Data discovery Data mapping Code generation Code execution Data review These steps are often the focus of developers or technical data analysts who may use multiple specialized tools to perform their tasks. The steps can be described as follows: Data discovery is the first step in the data transformation process. Typically the data is profiled using profiling tools or sometimes using manually written profiling scripts to better understand the structure and characteristics of the data and decide how it needs to be transformed. Data mapping is the process of defining how individual fields are mapped, modified, joined, filtered, aggregated etc. to produce the final desired output. Developers or technical data analysts traditionally perform data mapping since they work in the specific technologies to define the transformation rules (e.g. visual ETL tools, transformation languages). Code generation is the process of generating executable code (e.g. SQL, Python, R, or other executable instructions) that will transform the data based on the desired and defined data mapping rules. Typically, the data transformation technologies generate this code based on the definitions or metadata defined by the developers. Code execution is the step whereby the generated code is executed against the data to create the desired output. The executed code may be tightly integrated into the transformation tool, or it may require separate steps by the developer to manually execute the generated code. Data review is the final step in the process, which focuses on ensuring the output data meets the transformation requirements. It is typically the business user or final end-user of the data that performs this step. Any anomalies or errors in the data that are found and communicated back to the developer or data analyst as new requirements to be implemented in the transformation process. == Types of data transformation == === Batch data transformation === Traditionally, data transformation has been a bulk or batch process, whereby developers write code or implement transformation rules in a data integration tool, and then execute that code or those rules on large volumes of data. This process can follow the linear set of steps as described in the data transformation process above. Batch data transformation is the cornerstone of virtually all data integration technologies such as data warehousing, data migration and application integration. When data must be transformed and delivered with low latency, the term "microbatch" is often used. This refers to small batches of data (e.g. a small number of rows or a small set of data objects) that can be processed very quickly and delivered to the target system when needed. === Benefits of batch data transformation === Traditional data transformation processes have served companies well for decades. The various tools and technologies (data profiling, data visualization, data cleansing, data integration etc.) have matured and most (if not all) enterprises transform enormous volumes of data that feed internal and external applications, data warehouses and other data stores. === Limitations of traditional data transformation === This traditional process also has limitations that hamper its overall efficiency and effectiveness. The people who need to use the data (e.g. business users) do not play a direct role in the data transformation process. Typically, users hand over the data transformation task to developers who have the necessary coding or technical skills to define the transformations and execute them on the data. This process leaves the bulk of the work of defining the required transformations to the developer, which often in turn do not have the same domain knowledge as the business user. The developer interprets the business user requirements and implements the related code/logic. This has the potential of introducing errors into the process (through misinterpreted requirements), and also increases the time to arrive at a solution. This problem has given rise to the need for agility and self-service in data integration (i.e. empowering the user of the data and enabling them to transform the data themselves interactively). There are companies that provide self-service data transformation tools. They are aiming to efficiently analyze, map and transform large volumes of data without the technical knowledge and process complexity that currently exists. While these companies use traditional batch transformation, their tools enable more interactivity for users through visual platforms and easily repeated scripts. Still, there might be some compatibility issues (e.g. new data sources like IoT may not work correctly with older tools) and compliance limitations due to the difference in data governance, preparation and audit practices. === Interactive data transformation === Interactive data transformation (IDT) is an emerging capability that allows business analysts and business users the ability to directly interact with large datasets through a visual interface, understand the characteristics of the data (via automated data profiling or visualization), and change or correct the data through simple interactions such as clicking or selecting certain elements of the data. Although interactive data transformation follows the same data integration process steps as batch data integration, the key difference is that the steps are not necessarily followed in a linear fashion and typically don't require significant technical skills for completion. There are a number of companies that provide interactive data transformation tools, including Trifacta, Alteryx and Paxata. They are aiming to efficiently analyze, map and transform large volumes of data while at the same time abstracting away some of the technical complexity and processes which take place under the hood. Interactive data transformation solutions provide an integrated visual interface that combines the previously disparate steps of data analysis, data mapping and code generation/execution and data inspection. That is, if changes are made at one step (like for example renaming), the software automatically updates the preceding or following steps accordingly. Interfaces for interactive data transformation incorporate visualizations to show the user patterns and anomalies in the data so they can identify erroneous or outlying values. Once they've finished transforming the data, the system can generate executable code/logic, which can be executed or applied to subsequent similar data sets. By removing the developer from the process, interactive data transformation systems shorten the time needed to prepare and transform the data, eliminate costly errors in the interpretation of user requirements and empower business users and analysts to control their data and interact with it as needed. == Transformational languages == There are numerous languages available for performing data transformation. Many transformation languages require a grammar to be provided. In many cases, the grammar is structured using something closely resembling Backus–Naur form (BNF). There are numerous languages
Harvest now, decrypt later
Harvest now, decrypt later (HNDL) is a surveillance strategy that relies on the acquisition and long-term storage of currently unreadable encrypted data awaiting possible breakthroughs in decryption technology that would render it readable in the future—a hypothetical date referred to as Y2Q (a reference to Y2K), or Q-Day. The most common concern is the prospect of developments in quantum computing which would allow current strong encryption algorithms to be broken at some time in the future, making it possible to decrypt any stored material that had been encrypted using those algorithms. However, the improvement in decryption technology need not be due to a quantum-cryptographic advance; any other form of attack capable of enabling decryption would be sufficient. The existence of this strategy has led to concerns about the need to urgently deploy post-quantum cryptography; even though no practical quantum attacks yet exist, some data stored now may still remain sensitive even decades into the future. As of 2022, the U.S. federal government has proposed a roadmap for organizations to start migrating toward quantum-cryptography-resistant algorithms to mitigate these threats. This new version of Commercial National Security Algorithm Suite uses publicly-available algorithms and is allowed for government use up to the TOP SECRET level. == Terminology and scope == The term “harvest now, decrypt later” encompasses various surveillance or espionage operations in which ciphertext or encrypted communications are collected today with the view that they may one day be decrypted, given sufficient advances in computing power or cryptanalysis. The abbreviation HNDL is sometimes used in technical and policy documents. The “Y2Q” (or “Q-Day”) label draws an analogy to the Y2K date-change issue, emphasising a potential future point at which current cryptography may collapse. The strategy is particularly relevant for data with long confidentiality lifetimes, such as diplomatic communications, personal health records, critical infrastructure logs, or intellectual property. == Mitigation strategies == The primary defense against HNDL attacks is the transition to post-quantum cryptography (PQC), which utilizes algorithms believed to be secure against quantum computer attacks. However, because PQC protects the data payload digitally, rather than the transmission itself, the encrypted data can still be harvested and stored. A complementary approach involves physical layer security (also known as optical layer encryption or photonic shielding). Unlike algorithmic encryption, this method modifies the optical waveform itself—often by burying the signal within optical noise or using spectral phase encoding—to render the transmission unrecordable by standard receivers. By preventing the attacker from capturing a valid signal in the first place, this approach aims to eliminate the "harvest" phase of the threat. Commercial implementations of harvest-proof optical encryption have been developed by firms such as CyberRidge to secure long-haul fiber networks. Field trials have demonstrated 100 Gbps throughput over legacy DWDM networks using this method.
Data thinking
Data Thinking is a framework that integrates data science with the design process. It combines computational thinking, statistical thinking, and domain-specific knowledge to guide the development of data-driven solutions in product development. The framework is used to explore, design, develop, and validate solutions, with a focus on user experience and data analytics, including data collection and interpretation The framework aims to apply data literacy and inform decision-making through data-driven insights. == Major components == According to "Computational thinking in the era of data science": Data thinking involves understanding that solutions require both data-driven and domain-knowledge-driven rules. Data thinking evaluates whether data accurately represents real-life scenarios and improves data collection where necessary. The framework highlights the importance of preserving domain-specific meaning during data analysis. Data thinking incorporates statistical and logical analysis to identify patterns and irregularities. Data thinking involves testing solutions in real-life contexts and iteratively improving models based on new data. The process requires evaluating problems from multiple abstraction levels and understanding the potential for biases in generalizations. == Major phases == === Strategic context and risk analysis === Analyzing the broader digital strategy and assessing risks and opportunities is a common step before beginning a project. Techniques like coolhunting, trend analysis, and scenario planning can be used to assist with this. === Ideation and exploration === In this phase, focus areas are identified, and use cases are developed by integrating organizational goals, user needs, and data requirements. Design thinking methods, such as personas and customer journey mapping, are applied. === Prototyping === A proof of concept is created to test feasibility and refine solutions through iterative evaluation to optimize for effective performance. === Implementation and monitoring === Solutions are tested and monitored for performance and continual improvement. == Implementing Data Thinking == The following resources explain more about data thinking and its applications: "Data Thinking: Framework for data-based solutions" by StackFuel "What is Data Thinking? A modern approach to designing a data strategy" by Mantel Group "Data Science Thinking" by SpringerLink These sources provide detailed insights into the methodology, phases, and benefits of adopting Data Thinking in organizational processes.
Central Equipment Identity Register
A Central Equipment Identity Register (CEIR) is a database of mobile equipment identifiers (IMEI – for networks of GSM standard, MEID – for networks of CDMA standard). Such an identifier is assigned to each SIM slot of the mobile device. Different kinds of IMEIs could be, White, for devices that are allowed to register in the cellular network; Black, for devices that are prohibited to register in the cellular network; and Grey, for devices in intermediate status (when it is not yet defined in which of the lists - black or white - the device should be placed). Depending on the rules of mobile equipment registration in a country the CEIR database may contain other lists or fields beside IMEI. For example, the subscriber number (MSISDN), which is bound to the IMEI, the ID of the individual (passport data, National ID, etc.) who registered IMEI in the database, details of the importer who brought the device into the country, etc. == History == Originally abbreviation CEIR stood for IMEI Database, created and provided by GSM Association. It was proposed to blacklist the IMEIs of stolen or lost phones. It was assumed that any MNO would be able to receive this list to block the registration of such devices on their network. Thus, it turns out that a stolen phone, once blacklisted by the GSMA CEIR, cannot be used on a large number of cellular networks, which means that the theft of mobile devices will become meaningless. However, it soon became clear that the MNOs on their initiative were not going to do this because if many phones stopped working in their networks, but works in another, it puts them at a disadvantage and can lead to an outflow of subscribers. It became clear that the blocking of stolen devices should be introduced simultaneously in all mobile networks of the country by legislative measures at the initiative of the communications regulator. In this case, as a rule, a national IMEI database is created, which contains general lists of blocked IMEIs. Since the registration in the cellular operator's network is directly blocked by a network node called EIR (Equipment Identity Register), the system that contains the national IMEI base became known as Central EIR (CEIR). To avoid confusion the database of GSM Association was renamed to IMEI Database - IMEI DB (it was in 2003-2008, see “Document History” at IMEI Database File Format Specification). Also sometimes a common IMEI database for several EIRs is called SEIR (Shared EIR). In each country, the CEIR can interact with IMEI DB differently. National CEIR may not communicate with IMEI DB at all. Firstly, it is separately decided whether CEIR will send information about its blacklist to IMEI DB (which IMEIs are placed in it or removed from there). Secondly, upon receipt of the blacklist from IMEI DB, the regulator decides from which countries it will receive it (IMEI DB stores the information exactly who blacklisted the IMEI). For example, you can get a list from neighboring countries, from countries in your region, from around the world. In addition to the blacklist, the GSMA is developing a list of IMEIs allocated to manufacturers for use in their devices. The manufacturer for each new device model gets at least one TAC (Type Allocation Code) allocated by GSMA, consisting of 8 digits, to which he can add a 6-digit serial number to obtain the IMEI. Thus, with one TAC, a manufacturer can release up to 1 million devices with a unique IMEI. Usually, CEIR receives a list of allocated TACs from the GSMA, since if the first 8 digits of the IMEI of a device are not in this list, this is a sign that it is counterfeit. If the central database of identifiers does not work with GSM networks, but with CDMA, then for the same purposes it is necessary to interact with another worldwide database that contains MEIDs – MEID Database. A system that directly blocks the registration of a mobile device on a cellular network – EIR. Each MNO must have at least one EIR, to which IMEI check requests (CheckIMEI) are sent when registering a device on the network. A typical EIR and CERI interaction scheme: The CEIR accumulates black, white, and grey lists using various data sources and verification methods. These lists are periodically transmitted to all EIRs. EIR uses them when processing every CheckIMEI request to determine whether to allow the device on the network or not. EIR can transmit some data to the CEIR database too. Usually, changes in a grey list – new IMEIs on the network that are not in any list – are transmitted from EIR to CEIR. In addition to synchronizing lists across multiple networks, the main function of CEIR is to implement the scenarios of changes at these lists. This usually requires interaction with various IT systems (databases) of other organizations and/or with subscribers. Еxamples of such scenarios: Whitelisting the IMEI of devices imported by the legal entity Whitelisting the IMEI of devices manufactured domestically Whitelisting the IMEI of devices imported by individual Blacklisting the IMEI of stolen/lost devices Binding IMEI to the subscriber's number and, vice versa, unbinding IMEI from the subscriber == System implementation results == The goals and results of CEIR implementation in a country are usually: Reducing mobile phone theft Reducing the import of devices stolen in other countries Reducing the presence of counterfeit devices on the market (null IMEI, incorrect IMEI, changed IMEI) Reducing illegal imports of mobile devices (increase in the collection of customs duties) Additionally, CEIR most often contributes to the solution of such problems: Combating various mobile fraud schemes Obtaining more accurate statistics on the state of the mobile communications market for the regulator Fight against terrorism (the ability to block the device at once in all mobile networks of the country). Known results achieved in some countries: Great Britain – reducing mobile phone theft. Turkey – reducing mobile phone theft, decreasing the current account deficit of Turkey and maximizing tax revenues. Uzbekistan – preventing black import of mobile devices by 98%, increase in revenues from the import of mobile devices by 700%. Kenya – disposing the market of counterfeit mobile equipment. Azerbaijan – disposing the market of counterfeit mobile equipment. Ukraine – increasing of legally imported mobile devices by 95%, increase in revenues from the import of mobile devices. == CEIR and EIR manufacturers == Some countries have used local developers to implement CEIR for their country (Great Britain, Turkey, India, and Azerbaijan). EIR is a system that is standardized in a 2G-5G networks. Such system may be established at mobile network even it doesn’t use black list and there are no CEIR in a country. Some developers of MNO’s signal core include EIR in a complex solution. However, its standard capabilities are usually lacking for specific requirements when implementing CEIR.
Brooklyn Bridge (software)
The Brooklyn Bridge from White Crane Systems was a data transfer enabler. Although it came with some hardware, it was the software which was the basis of the product. It also could transform the data's format. == Overview == The New York Times described its category as being among "communications packages used to transfer files." In an era of 300 baud, Brooklyn Bridge operated at "115,200 baud" so that a transfer which "at 300 baud took 4 minutes and 36 seconds" only needed 5 seconds. Unlike some communications packages, this one retains the original version-date, so as not to alarm people when they seem to have what looks like an update, when it's not. == Description == Once the software is installed, users comfortable with typing the word "COPY" can do so as readily as they sneakernet. An earlier review described it as "less cumbersome than conventional communications software" The use of neither specialized hardware nor specialized software is ideal in an era when this can be done using online or other "outside" services.