Myrinet

Myrinet

Myrinet, ANSI/VITA 26-1998, is a high-speed local area networking system designed by the company Myricom to be used as an interconnect between multiple machines to form computer clusters. == Description == Myrinet was promoted as having lower protocol overhead than standards such as Ethernet, and therefore better throughput, less interference, and lower latency while using the host CPU. Although it can be used as a traditional networking system, Myrinet is often used directly by programs that "know" about it, thereby bypassing a call into the operating system. Earlier versions of Myrinet used a variety of media and connectors: Generation 2 used copper media with DC-37 (Myrinet-LAN, M2L- controllers and switches) or microribbon (Myrinet-SAN, M2M-) connectors. Generation 3 used copper media with HSSDC (Myrinet-Serial, M3S-) or microribbon (Myrinet-SAN, M3M-) connectors, or fiber with LC-connectors (Myrinet-Fiber, M3F-). The later versions of Myrinet physically consist of two fibre optic cables, upstream and downstream, connected to the host computers with a single connector. Machines are connected via low-overhead routers and switches, as opposed to connecting one machine directly to another. Myrinet includes a number of fault-tolerance features, mostly backed by the switches. These include flow control, error control, and "heartbeat" monitoring on every link. The "fourth-generation" Myrinet, called Myri-10G, supported a 10 Gbit/s data rate and can use 10 Gigabit Ethernet on PHY, the physical layer (cables, connectors, distances, signaling). Myri-10G started shipping at the end of 2005. Myrinet was approved in 1998 by the American National Standards Institute for use on the VMEbus as ANSI/VITA 26-1998. One of the earliest publications on Myrinet is a 1995 IEEE article. === Performance === Myrinet is a lightweight protocol with little overhead that allows it to operate with throughput close to the basic signaling speed of the physical layer. For supercomputing, the low latency of Myrinet is even more important than its throughput performance, since, according to Amdahl's law, a high-performance parallel system tends to be bottlenecked by its slowest sequential process, which in all but the most embarrassingly parallel supercomputer workloads is often the latency of message transmission across the network. === Deployment === According to Myricom, 141 (28.2%) of the June 2005 TOP500 supercomputers used Myrinet technology. In the November 2005 TOP500, the number of supercomputers using Myrinet was down to 101 computers, or 20.2%, in November 2006, 79 (15.8%), and by November 2007, 18 (3.6%), a long way behind gigabit Ethernet at 54% and InfiniBand at 24.2%. In the June 2014 TOP500 list, the number of supercomputers using Myrinet interconnect was 1 (0.2%). In November 2013, the assets of Myricom (including the Myrinet technology) were acquired by CSP Inc. In 2016, it was reported that Google had also offered to buy the company.

Bayesian programming

Bayesian programming is a formalism and a methodology for having a technique to specify probabilistic models and solve problems when less than the necessary information is available. Edwin T. Jaynes proposed that probability could be considered as an alternative and an extension of logic for rational reasoning with incomplete and uncertain information. In his founding book Probability Theory: The Logic of Science he developed this theory and proposed what he called "the robot," which was not a physical device, but an inference engine to automate probabilistic reasoning—a kind of Prolog for probability instead of logic. Bayesian programming is a formal and concrete implementation of this "robot". Bayesian programming may also be seen as an algebraic formalism to specify graphical models such as, for instance, Bayesian networks, dynamic Bayesian networks, Kalman filters or hidden Markov models. Indeed, Bayesian programming is more general than Bayesian networks and has a power of expression equivalent to probabilistic factor graphs. == Formalism == A Bayesian program is a means of specifying a family of probability distributions. The constituent elements of a Bayesian program are presented below: Program { Description { Specification ( π ) { Variables Decomposition Forms Identification (based on δ ) Question {\displaystyle {\text{Program}}{\begin{cases}{\text{Description}}{\begin{cases}{\text{Specification}}(\pi ){\begin{cases}{\text{Variables}}\\{\text{Decomposition}}\\{\text{Forms}}\\\end{cases}}\\{\text{Identification (based on }}\delta )\end{cases}}\\{\text{Question}}\end{cases}}} A program is constructed from a description and a question. A description is constructed using some specification ( π {\displaystyle \pi } ) as given by the programmer and an identification or learning process for the parameters not completely specified by the specification, using a data set ( δ {\displaystyle \delta } ). A specification is constructed from a set of pertinent variables, a decomposition and a set of forms. Forms are either parametric forms or questions to other Bayesian programs. A question specifies which probability distribution has to be computed. === Description === The purpose of a description is to specify an effective method of computing a joint probability distribution on a set of variables { X 1 , X 2 , ⋯ , X N } {\displaystyle \left\{X_{1},X_{2},\cdots ,X_{N}\right\}} given a set of experimental data δ {\displaystyle \delta } and some specification π {\displaystyle \pi } . This joint distribution is denoted as: P ( X 1 ∧ X 2 ∧ ⋯ ∧ X N ∣ δ ∧ π ) {\displaystyle P\left(X_{1}\wedge X_{2}\wedge \cdots \wedge X_{N}\mid \delta \wedge \pi \right)} . To specify preliminary knowledge π {\displaystyle \pi } , the programmer must undertake the following: Define the set of relevant variables { X 1 , X 2 , ⋯ , X N } {\displaystyle \left\{X_{1},X_{2},\cdots ,X_{N}\right\}} on which the joint distribution is defined. Decompose the joint distribution (break it into relevant independent or conditional probabilities). Define the forms of each of the distributions (e.g., for each variable, one of the list of probability distributions). ==== Decomposition ==== Given a partition of { X 1 , X 2 , … , X N } {\displaystyle \left\{X_{1},X_{2},\ldots ,X_{N}\right\}} containing K {\displaystyle K} subsets, K {\displaystyle K} variables are defined L 1 , ⋯ , L K {\displaystyle L_{1},\cdots ,L_{K}} , each corresponding to one of these subsets. Each variable L k {\displaystyle L_{k}} is obtained as the conjunction of the variables { X k 1 , X k 2 , ⋯ } {\displaystyle \left\{X_{k_{1}},X_{k_{2}},\cdots \right\}} belonging to the k t h {\displaystyle k^{th}} subset. Recursive application of Bayes' theorem leads to: P ( X 1 ∧ X 2 ∧ ⋯ ∧ X N ∣ δ ∧ π ) = P ( L 1 ∧ ⋯ ∧ L K ∣ δ ∧ π ) = P ( L 1 ∣ δ ∧ π ) × P ( L 2 ∣ L 1 ∧ δ ∧ π ) × ⋯ × P ( L K ∣ L K − 1 ∧ ⋯ ∧ L 1 ∧ δ ∧ π ) {\displaystyle {\begin{aligned}&P\left(X_{1}\wedge X_{2}\wedge \cdots \wedge X_{N}\mid \delta \wedge \pi \right)\\={}&P\left(L_{1}\wedge \cdots \wedge L_{K}\mid \delta \wedge \pi \right)\\={}&P\left(L_{1}\mid \delta \wedge \pi \right)\times P\left(L_{2}\mid L_{1}\wedge \delta \wedge \pi \right)\times \cdots \times P\left(L_{K}\mid L_{K-1}\wedge \cdots \wedge L_{1}\wedge \delta \wedge \pi \right)\end{aligned}}} Conditional independence hypotheses then allow further simplifications. A conditional independence hypothesis for variable L k {\displaystyle L_{k}} is defined by choosing some variable X n {\displaystyle X_{n}} among the variables appearing in the conjunction L k − 1 ∧ ⋯ ∧ L 2 ∧ L 1 {\displaystyle L_{k-1}\wedge \cdots \wedge L_{2}\wedge L_{1}} , labelling R k {\displaystyle R_{k}} as the conjunction of these chosen variables and setting: P ( L k ∣ L k − 1 ∧ ⋯ ∧ L 1 ∧ δ ∧ π ) = P ( L k ∣ R k ∧ δ ∧ π ) {\displaystyle P\left(L_{k}\mid L_{k-1}\wedge \cdots \wedge L_{1}\wedge \delta \wedge \pi \right)=P\left(L_{k}\mid R_{k}\wedge \delta \wedge \pi \right)} We then obtain: P ( X 1 ∧ X 2 ∧ ⋯ ∧ X N ∣ δ ∧ π ) = P ( L 1 ∣ δ ∧ π ) × P ( L 2 ∣ R 2 ∧ δ ∧ π ) × ⋯ × P ( L K ∣ R K ∧ δ ∧ π ) {\displaystyle {\begin{aligned}&P\left(X_{1}\wedge X_{2}\wedge \cdots \wedge X_{N}\mid \delta \wedge \pi \right)\\={}&P\left(L_{1}\mid \delta \wedge \pi \right)\times P\left(L_{2}\mid R_{2}\wedge \delta \wedge \pi \right)\times \cdots \times P\left(L_{K}\mid R_{K}\wedge \delta \wedge \pi \right)\end{aligned}}} Such a simplification of the joint distribution as a product of simpler distributions is called a decomposition, derived using the chain rule. This ensures that each variable appears at the most once on the left of a conditioning bar, which is the necessary and sufficient condition to write mathematically valid decompositions. ==== Forms ==== Each distribution P ( L k ∣ R k ∧ δ ∧ π ) {\displaystyle P\left(L_{k}\mid R_{k}\wedge \delta \wedge \pi \right)} appearing in the product is then associated with either a parametric form (i.e., a function f μ ( L k ) {\displaystyle f_{\mu }\left(L_{k}\right)} ) or a question to another Bayesian program P ( L k ∣ R k ∧ δ ∧ π ) = P ( L ∣ R ∧ δ ^ ∧ π ^ ) {\displaystyle P\left(L_{k}\mid R_{k}\wedge \delta \wedge \pi \right)=P\left(L\mid R\wedge {\widehat {\delta }}\wedge {\widehat {\pi }}\right)} . When it is a form f μ ( L k ) {\displaystyle f_{\mu }\left(L_{k}\right)} , in general, μ {\displaystyle \mu } is a vector of parameters that may depend on R k {\displaystyle R_{k}} or δ {\displaystyle \delta } or both. Learning takes place when some of these parameters are computed using the data set δ {\displaystyle \delta } . An important feature of Bayesian programming is this capacity to use questions to other Bayesian programs as components of the definition of a new Bayesian program. P ( L k ∣ R k ∧ δ ∧ π ) {\displaystyle P\left(L_{k}\mid R_{k}\wedge \delta \wedge \pi \right)} is obtained by some inferences done by another Bayesian program defined by the specifications π ^ {\displaystyle {\widehat {\pi }}} and the data δ ^ {\displaystyle {\widehat {\delta }}} . This is similar to calling a subroutine in classical programming and provides an easy way to build hierarchical models. === Question === Given a description (i.e., P ( X 1 ∧ X 2 ∧ ⋯ ∧ X N ∣ δ ∧ π ) {\displaystyle P\left(X_{1}\wedge X_{2}\wedge \cdots \wedge X_{N}\mid \delta \wedge \pi \right)} ), a question is obtained by partitioning { X 1 , X 2 , ⋯ , X N } {\displaystyle \left\{X_{1},X_{2},\cdots ,X_{N}\right\}} into three sets: the searched variables, the known variables and the free variables. The 3 variables S e a r c h e d {\displaystyle Searched} , K n o w n {\displaystyle Known} and F r e e {\displaystyle Free} are defined as the conjunction of the variables belonging to these sets. A question is defined as the set of distributions: P ( S e a r c h e d ∣ Known ∧ δ ∧ π ) {\displaystyle P\left(Searched\mid {\text{Known}}\wedge \delta \wedge \pi \right)} made of many "instantiated questions" as the cardinal of K n o w n {\displaystyle Known} , each instantiated question being the distribution: P ( Searched ∣ Known ∧ δ ∧ π ) {\displaystyle P\left({\text{Searched}}\mid {\text{Known}}\wedge \delta \wedge \pi \right)} === Inference === Given the joint distribution P ( X 1 ∧ X 2 ∧ ⋯ ∧ X N ∣ δ ∧ π ) {\displaystyle P\left(X_{1}\wedge X_{2}\wedge \cdots \wedge X_{N}\mid \delta \wedge \pi \right)} , it is always possible to compute any possible question using the following general inference: P ( Searched ∣ Known ∧ δ ∧ π ) = ∑ Free [ P ( Searched ∧ Free ∣ Known ∧ δ ∧ π ) ] = ∑ Free [ P ( Searched ∧ Free ∧ Known ∣ δ ∧ π ) ] P ( Known ∣ δ ∧ π ) = ∑ Free [ P ( Searched ∧ Free ∧ Known ∣ δ ∧ π ) ] ∑ Free ∧ Searched [ P ( Searched ∧ Free ∧ Known ∣ δ ∧ π ) ] = 1 Z × ∑ Free [ P ( Searched ∧ Free ∧ Known ∣ δ ∧ π ) ] {\displaystyle {\begin{aligned}&P\left({\text{Searched}}\mid {\text{Known}}\wedge \delta \wedge \pi \right)\\={}&\sum _{\text{Free}}\left[P\left({\text{Searched}}\wedge {\text{Free}}\mid {\text{Known}}\wedge \delta \wedge \

CityEngine

ArcGIS CityEngine is a commercial 3D modeling program. Developed by Esri R&D Center Zurich (formerly Procedural Inc.), it specializes in the generation of 3D urban environments to support the creation of detailed large-scale 3D city models. Unlike traditional 3D modeling methodology, which uses computer-aided design (CAD) tools and techniques, CityEngine takes a procedural modeling approach which shapes generation via a rules-based system. Due to its integration with the wider ArcGIS platform, CityEngine can also be used with geographic information system (GIS) datasets. CityEngine can be used for urban planning and architecture, graphics visualization, game development, entertainment, and archeology. CityEngine can be used to visualize the building information modeling (BIM) data of buildings in a larger urban context, making for more realistic construction projects. == History and releases == === Software history === ArcGIS CityEngine, originally named Esri CityEngine, was developed at Swiss technology university ETH Zurich by Pascal Mueller, the co-founder and CEO of Procedural Inc. While researching for his PhD at the ETH Computer Vision Lab, Mueller invented a number of techniques for procedural modeling of 3D architecture that make up the foundation of CityEngine. CityEngine publically debuted at the 2001 SIGGRAPH conference; since then, additional research papers have been published that have contributed to CityEngine and its features. The first commercial version of CityEngine was released in 2008. In 2007, Procedural Inc. was founded and separated from ETH Zurich, the top-ranking technology university in Switzerland. In the summer of 2011, Procedural Inc. was acquired by Esri Inc., becoming Esri R&D Center Zurich. Esri CityEngine was renamed to ArcGIS CityEngine in June 2020 to offically make it a part of the ArcGIS software suite. === Releases === === Licensing and pricing === ArcGIS CityEngine is included in the Professional and Professional Plus tiers of ArcGIS Online. Pricing may vary by region and distributors. In the US, the professional tier costs US$2,200 per year; in the UK, it is £4,200 per year (excluding VAT). CityEngine can be purchased elsewhere via a local Esri partner. . Once purchased, users can download and obtain license details from the MyEsri portal. == Features == CGA (computer generated architecture) parametric modeling rules to control mass, geometry assets, proportions, or texturing of buildings or streets on a citywide scale Select a target location and import geo-referenced satellite imagery and 3D terrain of the location to more quickly build accurate urban environments through OpenStreetMap integration Interactively control specific street or building parameters, such as height or age Import/export geo-spatial/vector data with industry-standard formats such as Esri Shapefile, File Geodatabase, and OpenStreetMap, as well as file formats for WebGL, KMZ, Collada, Autodesk FBX, Autodesk Maya, 3DS, Wavefront OBJ, RenderMan RIB, Alembic, e-on software's Vue, Universal Scene Description USD, Khronos Group GLTF, Unreal Engine, and Unreal Datasmith Script and generate rules-based reports to show socioeconomic figures (e.g., Gross Floor Area (GFA) and Floor Area Ratio (FAR)) to analyze their urban design proposals. VR viewing of modeled environments with Samsung Gear VR Use a variety of materials through the Esri materials library == Procedural modeling == ArcGIS CityEngine uses a procedural modeling approach to automatically generate models through a predefined rule set. The rules are defined through a CGA shape grammar system, enabling the creation of complex parametric models. Users can change or add the shape grammar as needed. Urban environments can be modeled within CityEngine by starting with creating a street network (either from the street drawing tool or with data imported from map data). Then, lots may be subdivided as many times as specified, resulting in a map of multiple lots and streets. CityEngine can then be instructed to start generating the buildings using defined procedural modeling rules. At this point, the city model can be re-designed and adjusted by changing the parameters or the shape grammar. === Geodesign === Though CityEngine is not an analytical tool like GIS, discussions about geodesign often mention the use of ArcGIS CityEngine. As it can be used to enhance 3D shape generation in ArcGIS, ArcGIS CityEngine is a critical product to improve the applicability of geodesign by using geospatial information to design or analyze a city. == Applications == === Urban design and planning === Garsdale Design used ArcGIS CityEngine in the creation of city master plans in Iraq before 2013, both to model existing historic areas and also model future plans. Larger companies like Foster+Partners and HOK Architects have also used CityEngine in their urban planning projects. === Urban and environmental studies === Because its primary feature is building informative city models, some urban researchers use CityEngine to compare land-use planning schemes, for example in very dense global cities such as Hong Kong and Seoul. Environmental scientists can also utilize the instant 3D model generation in CityEngine, which can make for more convenient informative research than modeling a city by creating each building individually. === Game development === CityEngine can be used as a tool in the creation of video games that require detailed 3D environments to assign interactive scripts. === Movie industry === Zootopia (also known outside of the US as Zootopolis), which won the 2016 Academy Award for Best Animated Feature Film, used CityEngine to model the city in its movie. multi-scaling city, the designers used CityEngine due to its rule-based system. CityEngine was also used to create Big Hero 6's San-Fransokyo. === Military === Due to its integration with the Esri product suite and its ability to process geospatial data to create 3D scenes/maps, CityEngine can be used within military/defense organizations. == List of movies and TV shows using CityEngine == Studios and companies rarely state what software they use in their pipelines. When CityEngine is mentioned as a tool in production, it's often in a small reference in a larger article. Movies only claimed to use CityEngine by a single Esri employee Presented at FMX 2025 workshop == Ports == ArcGIS CityEngine is built on top of Eclipse IDE, and has therefore able to be used on Windows and Linux operating systems. Support for macOS was stopped in March 2021. == Plugins and extensions == ArcGIS CityEngine currently works with a number of third party 3D modeling, rendering, and analytical software products via its SDK and API; these currently are: ArcGIS CityEngine for ArcGIS Urban: ArcGIS Urban Suite Puma: ArcGIS CityEngine for Rhinoceros 3D Palladio: ArcGIS CityEngine for Houdini Serlio: ArcGIS CityEngine for Maya PyPRT: ArcGIS CityEngine for Python ArcGIS CityEngine provides a Python scripting interface built on Jython (current version 2.7.0) which allows users to create their own tools and functionality. == Publications ==

WebGPU Shading Language

WebGPU Shading Language (WGSL, internet media type: text/wgsl) is a high-level shading language and the normative shader language for the WebGPU API on the web. WGSL's syntax is influenced by Rust and is designed with strong static validation, explicit resource binding, and portability in mind for secure execution in browsers. In web contexts, WebGPU implementations accept WGSL source and perform compilation to platform-specific intermediate forms (for example, to SPIR‑V, DXIL, or MSL via the user agent), but such backends are not exposed to web content. == History and background == Graphics on the web historically used WebGL, with shaders written in GLSL ES. As applications demanded more modern GPU features and finer control over compute and graphics pipelines, the W3C's GPU for the Web Community Group and Working Group created WebGPU and its companion shading language, WGSL, to provide a secure, portable model suitable for the web platform. WGSL was developed to be human-readable, avoid undefined behavior common in legacy shading languages, and align closely with WebGPU's resource and validation model. == Design goals == WGSL's design emphasizes: Safety and determinism suitable for web security constraints (extensive static validation and well-defined semantics). Portability across diverse GPU backends via an abstract resource model shared with WebGPU. Readability and explicitness (no preprocessor, minimal implicit conversions, explicit address spaces and bindings). Alignment with modern GPU features (compute, storage buffers, textures, atomics) while retaining a familiar C/Rust-like syntax. == Language overview == === Types and values === Core scalar types include bool, i32, u32, and f32. Vectors (e.g., vec2, vec3, vec4) and matrices (up to 4×4) are available for floating-point element types. Optional f16 (half precision) may be enabled via a WebGPU feature; availability is implementation-dependent. Atomic types (atomic, atomic) support limited atomic operations in qualified address spaces. === Variables and address spaces === Variables are declared with let (immutable), var (mutable), or const (compile-time constant). Storage classes (address spaces) include function, private, workgroup, uniform, and storage with read or read_write access as applicable. WGSL defines explicit layout and alignment rules; attributes such as @align, @size, and @stride control data layout for buffer interoperability. === Functions and control flow === Functions use explicit parameter and return types. Control flow includes if, switch, for, while, and loop constructs, with break/continue. Recursion is disallowed; entry-point call graphs must be acyclic. === Entry points and attributes === Shaders define stage entry points with @vertex, @fragment, or @compute. Attributes annotate bindings and interfaces, including @group, @binding (resource binding), @location (user-defined I/O), @builtin (stage built-ins such as position or global_invocation_id), @interpolate, and @workgroup_size. === Resources === WGSL exposes buffers (uniform, storage), textures (sampled, storage, and multisampled variants), and samplers (filtering/non-filtering/comparison). The binding model is explicit via descriptor sets called groups and bindings, matching WebGPU's pipeline layout model. == Compilation and validation == Browsers compile WGSL to platform-appropriate representations and native driver formats; the specific compilation pipeline is not observable by web content. WGSL source undergoes strict parsing and static validation, and WebGPU enforces robust resource access rules to avoid out-of-bounds memory hazards, contributing to predictable behavior across implementations. == Shader stages == WGSL supports three pipeline stages: vertex, fragment, and compute. === Vertex shaders === Vertex shaders transform per-vertex inputs and produce values for rasterization, including a clip-space position written to the position builtin. ==== Example ==== === Fragment shaders === Fragment shaders run per-fragment and compute color (and optionally depth) outputs written to color attachments. ==== Example ==== If half-precision (vec4h, shorthand for vec4) is desired, the code must be prefaced with a enable f16; statement. === Compute shaders === Compute shaders run in workgroups and are used for general-purpose GPU computations. ==== Example ==== == Differences from GLSL and HLSL == Compared with legacy shading languages, WGSL: Omits a preprocessor and requires explicit types and conversions. Uses explicit address spaces and binding annotations aligned with WebGPU's model. Enforces strict validation to avoid undefined behavior common in other shading languages. Defines a portable, web-focused feature set; 16-bit types and other features are opt-in and may depend on device capabilities.

Automated penetration testing

Automated penetration testing (also known as autonomous penetration testing or automated offensive security) is the application of software-driven workflows and orchestration to simulate cyberattack techniques. These methods are used to identify, validate, and exploit security vulnerabilities in IT assets such as networks, applications, and cloud infrastructure. Automated penetration testing is the use of software to simulate cyberattacks in order to rapidly identify exploitable vulnerabilities across systems without relying solely on human testers. In technical literature, the term describes a spectrum of activities ranging from scripted exploit orchestration to experimental systems designed for fully autonomous attack planning. Automated Penetration Testing falls short of testing using manual experts in terms of discovery of deep complex vulnerabilities and contextual business logic vulnerabilities. == Terminology and scope == The label “automated penetration testing” appears frequently in vendor and practitioner writing but lacks a single, neutral, standards-based definition. In the literature the term’s scope varies: some authors use it to mean automation of specific penetration-testing tasks (scanning, exploitation attempts, evidence collection), others to describe integrated, repeatable assessment pipelines, and a smaller body of work investigates autonomous decision-making agents that select attack steps algorithmically. To avoid implying consensus, this article describes common techniques and architectures reported in the literature and industry, and it notes where claims are primarily found in practitioner publications or early-stage research. Its important to note the differences between automated penetration testing and traditional penetration testing using human skill. The most important difference is scope and speed. Automated penetration testing generally fails at discovering exposures and weakness associated with business logic due to a lack of contextual understanding. The benefit of Automated Penetration testing is speed at which it can be conducted. Traditional penetration testing also is expected to be accurate and contain no false positives. This is due to the human validation aspect of the test. Automated approaches are expected to contain mistakes and false positives which need to be validated upon completion of the test. == History == Automated offensive techniques build on decades of tools and scripting that aided vulnerability discovery and exploitation. Early vulnerability scanners and community scripting in the 1990s and 2000s created the first layers of automation. Later, modular exploitation frameworks (notably Metasploit) integrated scanning and exploitation modules and made automated proof-of-concept attacks more accessible. Over the 2010s–2020s, as cloud platforms, APIs and continuous delivery practices increased the need for frequent validation, academic and industry interest in formalizing automated approaches also grew. == Methodologies and architectures == Descriptions in the literature and technical reports cluster automated capabilities into several overlapping models: Scripted/engineered playbooks (task automation): Predefined workflows or playbooks encode common attack paths (for example, web application exploit sequences or lateral-movement chains). These playbooks are designed to reproduce known techniques in a controlled way to validate exploitability and reduce manual repetition. Exploit-oriented orchestration: Automation orchestrates exploitation modules from established frameworks to perform controlled proof-of-concept attacks that confirm exploitability rather than simply flagging potential weaknesses. This approach can reduce false positives versus passive scanning when tests are run in an appropriately controlled environment. Orchestrated multi-tool pipelines: A coordinated toolchain integrates reconnaissance, vulnerability scanning, credential testing, exploitation modules and reporting. Data and state persist across stages so that multi-step workflows (e.g., discover → escalate → pivot) can be executed repeatably, approximating manual penetration-test methodologies at larger scale. Continuous / CI-integrated testing: Automation embedded in build or deployment pipelines (CI/CD) triggers assessments automatically on new builds, configuration changes, or on a schedule, supporting frequent, repeatable validation aligned with DevOps practices. Academic theses and experimental work describe CI/CD-integrated proof-of-concept systems for web applications and internal networks. Research on autonomous planning and learning: Recent academic work explores machine learning and reinforcement-learning approaches to select or prioritise attack steps, generate attack sequences, or optimize the testing path; these approaches are largely experimental and raise distinct validation and safety questions. == Tools and vendors == Automated penetration testing is provided by a mix of open-source projects, commercial platforms, and professional services. These often follow the penetration testing as a service (PTaaS) model, which integrates automated scanning with manual validation by security analysts. Examples of widely known tools and vendors in the space include exploitation frameworks such as Metasploit, commercial automated platforms and PTaaS providers, and specialist vendors that offer breach-and-attack simulation (BAS) or continuous testing capabilities. == Applications and deployment models == In industry practice, some organizations deploy automated techniques through dedicated security validation platforms rather than bespoke toolchains. These platforms are typically used for continuous or scheduled validation in pre-production or controlled environments and are often positioned alongside, rather than in place of, human-led penetration testing. Examples discussed in secondary literature include platforms such as Pentera, which are commonly classified under breach-and-attack simulation or automated security validation rather than as standalone penetration-testing methodologies.

AI alignment

In the field of artificial intelligence (AI), alignment aims to steer AI systems toward a person's or group's intended goals, preferences, or ethical principles. An AI system is considered aligned if it advances the intended objectives. A misaligned AI system pursues unintended objectives. It is often difficult for AI designers to specify the full range of desired and undesired behaviors. Therefore, the designers often use simpler proxy goals, such as gaining human approval. But proxy goals can overlook necessary constraints or reward the AI system for merely appearing aligned. AI systems may also find loopholes that allow them to accomplish their proxy goals efficiently but in unintended, sometimes harmful, ways (reward hacking). Advanced AI systems may develop unwanted instrumental strategies, such as seeking power or self-preservation because such strategies help them achieve their assigned final goals. Furthermore, they might develop undesirable emergent goals that could be hard to detect before the system is deployed and encounters new situations and data distributions. Empirical research showed in 2024 that advanced large language models (LLMs) such as OpenAI o1 or Claude 3 sometimes engage in strategic deception to achieve their goals or prevent them from being changed. Some of these issues affect existing commercial systems such as LLMs, robots, autonomous vehicles, and social media recommendation engines. Some AI researchers argue that more capable future systems will be more severely affected because these problems partially result from high capabilities. Many prominent AI researchers and AI company leaders have argued or asserted that AI is approaching human-like (AGI) and superhuman cognitive capabilities (ASI), and could endanger human civilization if misaligned. These include "AI godfathers" Geoffrey Hinton and Yoshua Bengio and the CEOs of OpenAI, Anthropic, and Google DeepMind. These risks remain debated. AI alignment is a subfield of AI safety, the study of how to build safe AI systems. Other subfields of AI safety include robustness, monitoring, and capability control. Research challenges in alignment include instilling complex values in AI, developing honest AI, scalable oversight, auditing and interpreting AI models, and preventing emergent AI behaviors like power-seeking. Alignment research has connections to interpretability research, (adversarial) robustness, anomaly detection, calibrated uncertainty, formal verification, preference learning, safety-critical engineering, game theory, algorithmic fairness, and social sciences. == Objectives in AI == Programmers provide an AI system such as AlphaZero with an "objective function", in which they intend to encapsulate the goal(s) the AI is configured to accomplish. Such a system later populates a (possibly implicit) internal "model" of its environment. This model encapsulates all the agent's beliefs about the world. The AI then creates and executes whatever plan is calculated to maximize the value of its objective function. For example, when AlphaZero is trained on chess, it has a simple objective function of "+1 if AlphaZero wins, −1 if AlphaZero loses". During the game, AlphaZero attempts to execute whatever sequence of moves it judges most likely to attain the maximum value of +1. Similarly, a reinforcement learning system can have a "reward function" that allows the programmers to shape the AI's desired behavior. An evolutionary algorithm's behavior is shaped by a "fitness function". == Alignment problem == In 1960, AI pioneer Norbert Wiener described the AI alignment problem as follows: If we use, to achieve our purposes, a mechanical agency with whose operation we cannot interfere effectively [...] we had better be quite sure that the purpose put into the machine is the purpose which we really desire. AI alignment refers to ensuring that an AI system's objectives match some target. The target is variously defined as the goals of the system's designers or users, widely shared values, objective ethical standards, legal requirements, or the intentions its designers would have if they were more informed and enlightened. In democratic AI alignment, the target is the values and preferences of median voters, which increases political legitimacy. AI alignment is an open problem for modern AI systems and is a research field within AI. Aligning AI involves two main challenges: carefully specifying the purpose of the system (outer alignment) and ensuring that the system adopts the specification robustly (inner alignment). Researchers also attempt to create AI models that have robust alignment, sticking to safety constraints even when users adversarially try to bypass them. === Specification gaming and side effects === To specify an AI system's purpose, AI designers typically provide an objective function, examples, or feedback to the system. But designers are often unable to completely specify all important values and constraints, so they resort to easy-to-specify proxy goals such as maximizing the approval of human overseers, who are fallible. As a result, AI systems can find loopholes that help them accomplish the specified objective efficiently but in unintended, possibly harmful ways. This tendency is known as specification gaming or reward hacking, and is an instance of Goodhart's law. As AI systems become more capable, they are often able to game their specifications more effectively. Specification gaming has been observed in numerous AI systems. OpenAI GPT models for programming—including in real-world cases—have been found to explicitly plan hacking the tests used to evaluate them to falsely appear successful (e.g., explicitly stating "let's hack"). When the company penalized this, many models learned to obfuscate their plans while continuing to hack the tests. Another system was trained to finish a simulated boat race by rewarding the system for hitting targets along the track, but the system achieved more reward by looping and crashing into the same targets indefinitely. A 2025 Palisade Research study found that when tasked to win at chess against a stronger opponent, some reasoning LLMs attempted to hack the game system, for example by modifying or entirely deleting their opponent. Some alignment researchers aim to help humans detect specification gaming and steer AI systems toward carefully specified objectives that are safe and useful to pursue. When a misaligned AI system is deployed, it can have consequential side effects. Social media platforms have been known to optimize their recommendation algorithms for click-through rates, causing user addiction on a global scale. Stanford researchers say that such recommender systems are misaligned with their users because they "optimize simple engagement metrics rather than a harder-to-measure combination of societal and consumer well-being". Explaining such side effects, Berkeley computer scientist Stuart J. Russell said that the omission of implicit constraints can cause harm: "A system [...] will often set [...] unconstrained variables to extreme values; if one of those unconstrained variables is actually something we care about, the solution found may be highly undesirable. This is essentially the old story of the genie in the lamp, or the sorcerer's apprentice, or King Midas: you get exactly what you ask for, not what you want." Some researchers suggest that AI designers specify their desired goals by listing forbidden actions or by formalizing ethical rules (as with Asimov's Three Laws of Robotics). But Russell and Norvig argue that this approach overlooks the complexity of human values: "It is certainly very hard, and perhaps impossible, for mere humans to anticipate and rule out in advance all the disastrous ways the machine could choose to achieve a specified objective." Additionally, even if an AI system fully understands human intentions, it may still disregard them, because following human intentions may not be its objective (unless it is already fully aligned). === Pressure to deploy unsafe systems === Commercial organizations sometimes have incentives to take shortcuts on safety and to deploy misaligned or unsafe AI systems. For example, social media recommender systems have been profitable despite creating unwanted addiction and polarization. Competitive pressure can also lead to a race to the bottom on AI safety standards. For example, OpenAI has been sued for releasing a ChatGPT version that encouraged suicide for some unstable users, a behavior the company had overlooked amid a rushed product release. Similarly, in 2018, a self-driving car killed a pedestrian (Elaine Herzberg) after engineers disabled the emergency braking system because it was oversensitive and slowed development. === Risks from advanced misaligned AI === Some researchers are interested in aligning increasingly advanced AI systems, as progress in AI development is rapid, and industry and governments are trying to build advan

Database virtualization

Database virtualization is the decoupling of the database layer, which lies between the storage and application layers within the application stack. Virtualization of the database layer enables a shift away from the physical, toward the logical or virtual. Virtualization enables compute and storage resources to be pooled and allocated on demand. This enables both the sharing of single server resources for multi-tenancy, as well as the pooling of server resources into a single logical database or cluster. In both cases, database virtualization provides increased flexibility, more granular and efficient allocation of pooled resources, and more scalable computing. == Virtual data partitioning == The act of partitioning data stores as a database grows has been in use for several decades. There are two primary ways that data has been partitioned inside legacy data management systems: Shared-data databases: an architecture that assumes all database cluster nodes share a single partition. Inter-node communications are used to synchronize update activities performed by different nodes on the cluster. Shared-data data management systems are limited to single-digit node clusters. Shared-nothing databases: an architecture in which all data is segregated to internally managed partitions with clear, well-defined data location boundaries. Shared-nothing databases require manual partition management. In virtual partitioning, logical data is abstracted from physical data by autonomously creating and managing large numbers of data partitions (100s to 1000s). Because they are autonomously maintained, the resources required to manage the partitions are minimal. This kind of massive partitioning results in: Partitions that are small, efficiently managed, and load-balanced. Systems that do not require re-partitioning events to define additional partitions, even when the hardware is changed. “Shared-data” and “shared-nothing” architectures allow scalability through multiple data partitions and cross-partition querying and transaction processing without full partition scanning. == Horizontal data partitioning == Partitioning database sources from consumers is a fundamental concept. With greater numbers of database sources, inserting a horizontal data virtualization layer between the sources and consumers helps address this complexity. Rick van der Lans, the author of multiple books on SQL and relational databases, has defined data virtualization as "the process of offering data consumers a data access interface that hides the technical aspects of stored data, such as location, storage structure, API, access language, and storage technology." == Advantages == Added flexibility and agility for existing computing infrastructure. Enhanced database performance. Pooling and sharing computing resources, either splitting them (multi-tenancy) or combining them (clustering). Simplification of administration and management. Increased fault tolerance.