Serverless computing is "a cloud service category where the customer can use different cloud capability types without the customer having to provision, deploy and manage either hardware or software resources, other than providing customer application code or providing customer data. Serverless computing represents a form of virtualized computing", according to ISO/IEC 22123-2. Serverless computing is a broad ecosystem that includes the cloud provider, function as a service (FaaS), managed services, tools, frameworks, engineers, stakeholders, and other interconnected elements. == Overview == Serverless is a misnomer in the sense that servers are still used by cloud service providers to execute code for developers. The definition of serverless computing has evolved over time, leading to varied interpretations. According to Ben Kehoe, serverless represents a spectrum rather than a rigid definition. Emphasis should shift from strict definitions and specific technologies to adopting a serverless mindset, focusing on leveraging serverless solutions to address business challenges. Serverless computing does not eliminate complexity but shifts much of it from the operations team to the development team. However, this shift is not absolute, as operations teams continue to manage aspects such as identity and access management (IAM), networking, security policies, and cost optimization. Additionally, while breaking down applications into finer-grained components can increase management complexity, the relationship between granularity and management difficulty is not strictly linear. There is often an optimal level of modularization where the benefits outweigh the added management overhead. According to Yan Cui, serverless techniques should be adopted only when they help to deliver customer value faster. And while adopting, organizations should take small steps and de-risk along the way. == Challenges == Serverless applications are prone to fallacies of distributed computing. In addition, they are prone to the following fallacies: Versioning is simple Compensating transactions always work Observability is optional === Monitoring and debugging === Monitoring and debugging serverless applications can present unique challenges due to their distributed, event-driven nature and proprietary environments. Traditional tools may fall short, making it difficult to track execution flows across services. However, modern solutions such as distributed tracing tools (e.g., AWS X-Ray, Datadog), centralized logging, and cloud-agnostic observability platforms are mitigating these challenges. Emerging technologies like OpenTelemetry, AI-powered anomaly detection, and serverless-specific frameworks are further improving visibility and root cause analysis. While challenges persist, advancements in monitoring and debugging tools are steadily addressing these limitations. === Security === According to OWASP, serverless applications are vulnerable to variations of traditional attacks, insecure code, and some serverless-specific attacks (like denial of wallet). So, the risks have changed and attack prevention requires a shift in mindset. === Vendor lock-in === Serverless computing is provided as a third-party service. Applications and software that run in the serverless environment are by default locked to a specific cloud vendor. This issue is exacerbated in serverless computing, as with its increased level of abstraction, public vendors only allow customers to upload code to a FaaS platform without the authority to configure underlying environments. More importantly, when considering a more complex workflow that includes backend-as-a-service (BaaS), a BaaS offering can typically only natively trigger a FaaS offering from the same provider. This makes the workload migration in serverless computing virtually impossible. Therefore, considering how to design and deploy serverless workflows from a multi-cloud perspective could mitigate this. == High-performance computing == Serverless computing may not be ideal for certain high-performance computing (HPC) workloads due to resource limits often imposed by cloud providers, including maximum memory, CPU, and runtime restrictions. For workloads requiring sustained or predictable resource usage, bulk-provisioned servers can sometimes be more cost-effective than the pay-per-use model typical of serverless platforms. However, serverless computing is increasingly capable of supporting specific HPC workloads, particularly those that are highly parallelizable and event-driven, by leveraging its scalability and elasticity. The suitability of serverless computing for HPC continues to evolve with advancements in cloud technologies. == Anti-patterns == The grain of sand anti-pattern refers to the creation of excessively small components (e.g., functions) within a system, often resulting in increased complexity, operational overhead, and performance inefficiencies. Lambda pinball is a related anti-pattern that can occur in serverless architectures when functions (e.g., AWS Lambda, Azure functions) excessively invoke each other in fragmented chains, leading to latency, debugging and testing challenges, and reduced observability. These anti-patterns are associated with the formation of a distributed monolith. These anti-patterns are often addressed through the application of clear domain boundaries, which distinguish between public and published interfaces. Public interfaces are technically accessible interfaces, such as methods, classes, API endpoints, or triggers, but they do not come with formal stability guarantees. In contrast, published interfaces involve an explicit stability contract, including formal versioning, thorough documentation, a defined deprecation policy, and often support for backward compatibility. Published interfaces may also require maintaining multiple versions simultaneously and adhering to formal deprecation processes when breaking changes are introduced. Fragmented chains of function calls are often observed in systems where serverless components (functions) interact with other resources in complex patterns, sometimes described as spaghetti architecture or a distributed monolith. In contrast, systems exhibiting clearer boundaries typically organize serverless components into cohesive groups, where internal public interfaces manage inter-component communication, and published interfaces define communication across group boundaries. This distinction highlights differences in stability guarantees and maintenance commitments, contributing to reduced dependency complexity. Additionally, patterns associated with excessive serverless function chaining are sometimes addressed through architectural strategies that emphasize native service integrations instead of individual functions, a concept referred to as the functionless mindset. However, this approach is noted to involve a steeper learning curve, and integration limitations may vary even within the same cloud vendor ecosystem. Reporting on serverless databases presents challenges, as retrieving data for a reporting service can either break the bounded contexts, reduce the timeliness of the data, or do both. This applies regardless of whether data is pulled directly from databases, retrieved via HTTP, or collected in batches. Mark Richards refers to this as the reach-in reporting anti-pattern. A possible alternative to this approach is for databases to asynchronously push the necessary data to the reporting service instead of the reporting service pulling it. While this method requires a separate contract between services and the reporting service and can be complex to implement, it helps preserve bounded contexts while maintaining a high level of data timeliness. == Principles == Adopting DevSecOps practices can help improve the use and security of serverless technologies. In serverless applications, the distinction between infrastructure and business logic is often blurred, with applications typically distributed across multiple services. To maximize the effectiveness of testing, integration testing is emphasized for serverless applications. Additionally, to facilitate debugging and implementation, orchestration is used within the bounded context, while choreography is employed between different bounded contexts. Ephemeral resources are typically kept together to maintain high cohesion. However, shared resources with long spin-up times, such as AWS RDS clusters and landing zones, are often managed in separate repositories, deployment pipeline, and stacks.
Weight initialization
In deep learning, weight initialization or parameter initialization describes the initial step in creating a neural network. A neural network contains trainable parameters that are modified during training: weight initialization is the pre-training step of assigning initial values to these parameters. The choice of weight initialization method affects the speed of convergence, the scale of neural activation within the network, the scale of gradient signals during backpropagation, and the quality of the final model. Proper initialization is necessary for avoiding issues such as vanishing and exploding gradients and activation function saturation. Note that even though this article is titled "weight initialization", both weights and biases are used in a neural network as trainable parameters, so this article describes how both of these are initialized. Similarly, trainable parameters in convolutional neural networks (CNNs) are called kernels and biases, and this article also describes these. == Constant initialization == We discuss the main methods of initialization in the context of a multilayer perceptron (MLP). Specific strategies for initializing other network architectures are discussed in later sections. For an MLP, there are only two kinds of trainable parameters, called weights and biases. Each layer l {\displaystyle l} contains a weight matrix W ( l ) ∈ R n l − 1 × n l {\displaystyle W^{(l)}\in \mathbb {R} ^{n_{l-1}\times n_{l}}} and a bias vector b ( l ) ∈ R n l {\displaystyle b^{(l)}\in \mathbb {R} ^{n_{l}}} , where n l {\displaystyle n_{l}} is the number of neurons in that layer. A weight initialization method is an algorithm for setting the initial values for W ( l ) , b ( l ) {\displaystyle W^{(l)},b^{(l)}} for each layer l {\displaystyle l} . The simplest form is zero initialization: W ( l ) = 0 , b ( l ) = 0 {\displaystyle W^{(l)}=0,b^{(l)}=0} Zero initialization is usually used for initializing biases, but it is not used for initializing weights, as it leads to symmetry in the network, causing all neurons to learn the same features. In this page, we assume b = 0 {\displaystyle b=0} unless otherwise stated. Recurrent neural networks typically use activation functions with bounded range, such as sigmoid and tanh, since unbounded activation may cause exploding values. (Le, Jaitly, Hinton, 2015) suggested initializing weights in the recurrent parts of the network to identity and zero bias, similar to the idea of residual connections and LSTM with no forget gate. In most cases, the biases are initialized to zero, though some situations can use a nonzero initialization. For example, in multiplicative units, such as the forget gate of LSTM, the bias can be initialized to 1 to allow good gradient signal through the gate. For neurons with ReLU activation, one can initialize the bias to a small positive value like 0.1, so that the gradient is likely nonzero at initialization, avoiding the dying ReLU problem. == Random initialization == Random initialization means sampling the weights from a normal distribution or a uniform distribution, usually independently. === LeCun initialization === LeCun initialization, popularized in (LeCun et al., 1998), is designed to preserve the variance of neural activations during the forward pass. It samples each entry in W ( l ) {\displaystyle W^{(l)}} independently from a distribution with mean 0 and variance 1 / n l − 1 {\displaystyle 1/n_{l-1}} . For example, if the distribution is a continuous uniform distribution, then the distribution is U ( ± 3 / n l − 1 ) {\displaystyle {\mathcal {U}}(\pm {\sqrt {3/n_{l-1}}})} . === Glorot initialization === Glorot initialization (or Xavier initialization) was proposed by Xavier Glorot and Yoshua Bengio. It was designed as a compromise between two goals: to preserve activation variance during the forward pass and to preserve gradient variance during the backward pass. For uniform initialization, it samples each entry in W ( l ) {\displaystyle W^{(l)}} independently and identically from U ( ± 6 / ( n l + 1 + n l − 1 ) ) {\displaystyle {\mathcal {U}}(\pm {\sqrt {6/(n_{l+1}+n_{l-1})}})} . In the context, n l − 1 {\displaystyle n_{l-1}} is also called the "fan-in", and n l + 1 {\displaystyle n_{l+1}} the "fan-out". When the fan-in and fan-out are equal, then Glorot initialization is the same as LeCun initialization. === He initialization === As Glorot initialization performs poorly for ReLU activation, He initialization (or Kaiming initialization) was proposed by Kaiming He et al. for networks with ReLU activation. It samples each entry in W ( l ) {\displaystyle W^{(l)}} from N ( 0 , 2 / n l − 1 ) {\displaystyle {\mathcal {N}}(0,2/n_{l-1})} . === Orthogonal initialization === (Saxe et al. 2013) proposed orthogonal initialization: initializing weight matrices as uniformly random (according to the Haar measure) semi-orthogonal matrices, multiplied by a factor that depends on the activation function of the layer. It was designed so that if one initializes a deep linear network this way, then its training time until convergence is independent of depth. Sampling a uniformly random semi-orthogonal matrix can be done by initializing X {\displaystyle X} by IID sampling its entries from a standard normal distribution, then calculate ( X X ⊤ ) − 1 / 2 X {\displaystyle \left(XX^{\top }\right)^{-1/2}X} or its transpose, depending on whether X {\displaystyle X} is tall or wide. For CNN kernels with odd widths and heights, orthogonal initialization is done this way: initialize the central point by a semi-orthogonal matrix, and fill the other entries with zero. As an illustration, a kernel K {\displaystyle K} of shape 3 × 3 × c × c ′ {\displaystyle 3\times 3\times c\times c'} is initialized by filling K [ 2 , 2 , : , : ] {\displaystyle K[2,2,:,:]} with the entries of a random semi-orthogonal matrix of shape c × c ′ {\displaystyle c\times c'} , and the other entries with zero. (Balduzzi et al., 2017) used it with stride 1 and zero-padding. This is sometimes called the Orthogonal Delta initialization. Related to this approach, unitary initialization proposes to parameterize the weight matrices to be unitary matrices, with the result that at initialization they are random unitary matrices (and throughout training, they remain unitary). This is found to improve long-sequence modelling in LSTM. Orthogonal initialization has been generalized to layer-sequential unit-variance (LSUV) initialization. It is a data-dependent initialization method, and can be used in convolutional neural networks. It first initializes weights of each convolution or fully connected layer with orthonormal matrices. Then, proceeding from the first to the last layer, it runs a forward pass on a random minibatch, and divides the layer's weights by the standard deviation of its output, so that its output has variance approximately 1. === Fixup initialization === In 2015, the introduction of residual connections allowed very deep neural networks to be trained, much deeper than the ~20 layers of the previous state of the art (such as the VGG-19). Residual connections gave rise to their own weight initialization problems and strategies. These are sometimes called "normalization-free" methods, since using residual connection could stabilize the training of a deep neural network so much that normalizations become unnecessary. Fixup initialization is designed specifically for networks with residual connections and without batch normalization, as follows: Initialize the classification layer and the last layer of each residual branch to 0. Initialize every other layer using a standard method (such as He initialization), and scale only the weight layers inside residual branches by L − 1 2 m − 2 {\displaystyle L^{-{\frac {1}{2m-2}}}} . Add a scalar multiplier (initialized at 1) in every branch and a scalar bias (initialized at 0) before each convolution, linear, and element-wise activation layer. Similarly, T-Fixup initialization is designed for Transformers without layer normalization. === Others === Instead of initializing all weights with random values on the order of O ( 1 / n ) {\displaystyle O(1/{\sqrt {n}})} , sparse initialization initialized only a small subset of the weights with larger random values, and the other weights zero, so that the total variance is still on the order of O ( 1 ) {\displaystyle O(1)} . Random walk initialization was designed for MLP so that during backpropagation, the L2 norm of gradient at each layer performs an unbiased random walk as one moves from the last layer to the first. Looks linear initialization was designed to allow the neural network to behave like a deep linear network at initialization, since W R e L U ( x ) − W R e L U ( − x ) = W x {\displaystyle W\;\mathrm {ReLU} (x)-W\;\mathrm {ReLU} (-x)=Wx} . It initializes a matrix W {\displaystyle W} of shape R n 2 × m {\displaystyle \mathbb {R} ^{{\frac {n}{2}}\times m}} by any method, such as orthogonal initialization, t
Cloud management
Cloud management refers to the administration and oversight of cloud computing products and services. Public clouds are managed by cloud service providers, which operate the underlying infrastructure such as servers, storage, networking, and data center facilities. Users may also opt to manage their public cloud services with a third-party cloud management tool. Users of public cloud services can generally select from three basic cloud provisioning categories: User self-provisioning: Customers purchase cloud services directly from the provider, typically through a web form or console interface. The customer pays on a per-transaction basis. Advanced provisioning: Customers contract in advance a predetermined amount of resources, which are prepared in advance of service. The customer pays a flat fee or a monthly fee. Dynamic provisioning: The provider allocates resources when the customer needs them, then decommissions them when they are no longer needed. The customer is charged on a pay-per-use basis. Managing a private cloud requires software tools to help create a virtualized pool of compute resources, provide a self-service portal for end users and handle security, resource allocation, tracking and billing. Management tools for private clouds tend to be service driven, as opposed to resource driven, because cloud environments are typically highly virtualized and organized in terms of portable workloads. In hybrid cloud environments, compute, network and storage resources must be managed across multiple domains, so a good management strategy should start by defining what needs to be managed, and where and how to do it. Policies to help govern these domains should include configuration and installation of images, access control, and budgeting and reporting. Access control often includes the use of Single sign-on (SSO), in which a user logs in once and gains access to all systems without being prompted to log in again at each of them. == Characteristics of Cloud Management == Cloud management combines software and technologies in a design for managing cloud environments. Software developers have responded to the management challenges of cloud computing with a variety of cloud management platforms and tools. These tools include native tools offered by public cloud providers as well as third-party tools designed to provide consistent functionality across multiple cloud providers. Administrators must balance the competing requirements of efficient consistency across different cloud platforms with access to different native functionality within individual cloud platforms. The growing acceptance of public cloud and increased multicloud usage is driving the need for consistent cross-platform management. Rapid adoption of cloud services is introducing a new set of management challenges for those technical professionals responsible for managing IT systems and services. Cloud-management platforms and tools should have the ability to provide minimum functionality in the following categories. Functionality can be both natively provided or orchestrated via third-party integration. Provisioning and orchestration: create, modify, and delete resources as well as orchestrate workflows and management of workloads Automation: Enable cloud consumption and deployment of app services via infrastructure-as-code and other DevOps concepts Security and compliance: manage role-based access of cloud services and enforce security configurations Service request: collect and fulfill requests from users to access and deploy cloud resources. Monitoring and logging: collect performance and availability metrics as well as automate incident management and log aggregation Inventory and classification: discover and maintain pre-existing brownfield cloud resources plus monitor and manage changes Cost management and optimization: track and rightsize cloud spend and align capacity and performance to actual demand Migration, backup, and DR: enable data protection, disaster recovery, and data mobility via snapshots and/or data replication Organizations may group these criteria into key use cases including Cloud Brokerage, DevOps Automation, Governance, and Day-2 Life Cycle Operations. Enterprises with large-scale cloud implementations may require more robust cloud management tools which include specific characteristics, such as the ability to manage multiple platforms from a single point of reference, or intelligent analytics to automate processes like application lifecycle management. High-end cloud management tools should also have the ability to handle system failures automatically with capabilities such as self-monitoring, an explicit notification mechanism, and include failover and self-healing capabilities. == Multi-Cloud and Hybrid Cloud Management Challenges == Legacy management infrastructures, which are based on the concept of dedicated system relationships and architecture constructs, are not well suited to cloud environments where instances are continually launched and decommissioned. Instead, the dynamic nature of cloud computing requires monitoring and management tools that are adaptable, extensible and customizable. Cloud computing presents a number of management challenges. Companies using public clouds do not have ownership of the equipment hosting the cloud environment, and because the environment is not contained within their own networks, public cloud customers do not have full visibility or control. Users of public cloud services must also integrate with an architecture defined by the cloud provider, using its specific parameters for working with cloud components. Integration includes tying into the cloud APIs for configuring IP addresses, subnets, firewalls and data service functions for storage. Because control of these functions is based on the cloud provider’s infrastructure and services, public cloud users must integrate with the cloud infrastructure management. Capacity management is a challenge for both public and private cloud environments because end users have the ability to deploy applications using self-service portals. Applications of all sizes may appear in the environment, consume an unpredictable amount of resources, then disappear at any time. A possible solution is profiling the applications impact on computational resources. As result, the performance models allow the prediction of how resource utilization changes according to application patterns. Thus, resources can be dynamically scaled to meet the expected demand. This is critical to cloud providers that need to provision resources quickly to meet a growing demand by their applications. Charge-back—or, pricing resource use on a granular basis—is a challenge for both public and private cloud environments. Charge-back is a challenge for public cloud service providers because they must price their services competitively while still creating profit. Users of public cloud services may find charge-back challenging because it is difficult for IT groups to assess actual resource costs on a granular basis due to overlapping resources within an organization that may be paid for by an individual business unit, such as electrical power. For private cloud operators, charge-back is fairly straightforward, but the challenge lies in guessing how to allocate resources as closely as possible to actual resource usage to achieve the greatest operational efficiency. Exceeding budgets can be a risk. Hybrid cloud environments, which combine public and private cloud services, sometimes with traditional infrastructure elements, present their own set of management challenges. These include security concerns if sensitive data lands on public cloud servers, budget concerns around overuse of storage or bandwidth and proliferation of mismanaged images. Managing the information flow in a hybrid cloud environment is also a significant challenge. On-premises clouds must share information with applications hosted off-premises by public cloud providers, and this information may change constantly. Hybrid cloud environments also typically include a complex mix of policies, permissions and limits that must be managed consistently across both public and private clouds. == Cloud Management Platforms (CMP) == CMPs provide a means for a cloud service customer to manage the deployment and operation of applications and associated datasets across multiple cloud service infrastructures, including both on-premises cloud infrastructure and public cloud service provider infrastructure. In other words, CMPs provide management capabilities for hybrid cloud and multi-cloud environments. A cloud management platform (CMP) provides broad cloud management functionality atop both public cloud provider platforms and private cloud platforms. CMPs manage cloud services and resources that are distributed across multiple cloud platforms. The value of CMPs stands in delivering the maximum level of consistency between platforms without comp
CloudHealth Technologies
CloudHealth Technologies, now CloudHealth by VMware, is a software company based in Boston, Massachusetts. The company provides cloud computing services related to cost management, governance, automation, security, and performance. == History == CloudHealth Technologies was founded by Joe Kinsella in 2012. Dan Phillips joined as CEO and co-founder in late 2012, and Dave Eicher joined as co-Founder in January 2013. In May 2016, the company announced plans to expand from its Boston headquarters with branch offices in San Francisco, London, Washington, D.C., Sydney, Amsterdam, Tel Aviv, and Singapore. Headquarters moved in Boston from Fort Point to 100 Summer Street in the Spring of 2018, tripling in square footage. In September 2017, Tom Axbey—who was previously at Rave Mobile Safety—joined as the new CEO and President. VMware announced its intention to acquire CloudHealth Technologies on August 27, 2018. The acquisition is "part of the information technology company's continued push into cloud-based software services" according to Reuters. The deal closed on October 4, 2018, and was reported to be in excess of $500 million. == Technology == Delivered through a software as a service (SaaS) model, CloudHealth Technologies's platform collects and analyzes data from cloud computing services and other IT environments so clients can report on costs, inform their business models, and project future trends. CloudHealth Technologies is compatible with Amazon Web Services, Microsoft Azure, Google Cloud Platform, multicloud, and hybrid cloud environments. CloudHealth Technologies has received Amazon Web Services(AWS) Education Competency status, AWS Migration Competency status and achieved SOC 2 Type 2 Compliance. == Funding == As of June 2017, CloudHealth Technologies has raised a total of $85.7 million through four rounds of funding. In March 2013, CloudHealth Technologies announced that it had secured $4.5 million in Series A funding. This round was led by .406 Ventures and Sigma Prime Ventures. In January 2015, CloudHealth Technologies secured $12 million in Series B funding. This round was led by Scale Venture Partners, .406 Ventures, and Sigma Prime Ventures, and was followed by a $3.2 million extension round. In May 2016, CloudHealth Technologies announced $20 million in Series C funding, led by Sapphire Ventures, .406 Ventures, Scale Venture Partners and Sigma Prime Ventures. In June 2017, CloudHealth Technologies secured $46 million in Series D funding led by Kleiner Perkins Caufield & Byers with participation from Meritech Capital Partners, Sapphire Ventures, 406 Ventures, and Scale Venture Partners. == Competition == As of March 2023, CloudHealth Technologies competes with Cloudability by Apptio and CloudCheckr by NetApp.
Ampere Computing
Ampere Computing LLC is an American fabless semiconductor company that designs ARM-based central processing units (CPUs) with high core counts for use in cloud computing and data center environments. Founded in 2017 by former Intel president Renée James, the company is headquartered in Santa Clara, California, and operates as an independent subsidiary of SoftBank Group since November 2025. == History == Ampere Computing was founded in fall 2017 by Renée James, ex-President of Intel, with funding from The Carlyle Group. James acquired a team from MACOM Technology Solutions (formerly AppliedMicro) in addition to several industry hires to start the company. Ampere Computing is an ARM architecture licensee and develops its own server microprocessors. Ampere fabricates its products at TSMC. In April 2019, Ampere announced its second major investment round, including investment from Arm Holdings and Oracle Corporation. In June 2019, Nvidia announced a partnership with Ampere to bring support for Compute Unified Device Architecture (CUDA). In November 2019, Nvidia announced a reference design platform for graphics processing unit (GPU)-accelerated ARM-based servers including Ampere. In the first half of 2020, Ampere announced Ampere Altra, an 80-core processor, and Ampere Altra Max, a 128-core processor, without the use of simultaneous multithreading. In March 2020, the company announced a partnership with Oracle. In September 2020, Oracle said it would launch bare-metal and virtual machine instances in early 2021 based on Ampere Altra. In November 2020, Ampere was named one of the top 10 hottest semiconductor startups by CRN. In May 2021, the company announced a partnership with Microsoft. In April 2022, Ampere said that it had filed a confidential prospectus with the U.S. Securities and Exchange Commission, signaling its intent to go public. In June 2022, HPE announced their Gen11 ProLiant system would use Ampere Altra and Ampere Altra Max Cloud Native Processors. In July 2022, Google announced T2A instances using Ampere Altra in the Google cloud and in August 2022 Microsoft announced their instances of Ampere running in Azure. On March 19, 2025, investment holding company SoftBank Group announced it will acquire Ampere Computing for $6.5 billion. The deal finalized in November 2025, with Ampere remaining as an independent subsidiary with its headquarters in Santa Clara, California. == Products == Ampere develops ARM-based computer processors and CPU cores under their Altra brands. These are used in databases, media encoding, web services, network acceleration, mobile gaming, AI inference processing, and other applications and programs that need to scale. On February 5, 2018, Ampere announced the eMAG 8180 featuring 32x Skylark cores fabricated on TSMC's 16FF+ process. It supports a turbo of up to 3.3 GHz with a TDP of 125 W, 8ch 64-bit DDR4, up to 1 TB DDR4 per socket, and 42x PCIe 3.0 Lanes. The Skylark cores were based on AppliedMicro's X-Gene 3. Packet offers servers with the eMAG 8180 and 128 GB DRAM, 480 GB SSD, and 2x 10 Gbit/s networking. On September 19, 2018, Ampere announced the availability of a version featuring 16x Skylark cores. === 2020 === On March 3, 2020, Ampere announced the Ampere Altra featuring 80 cores fabricated on TSMC's N7 process for hyperscale computing. It was the first server-grade processor to include 80 cores and the Q80-30 conserves power by running at 161 W in use. The cores are semi-custom Arm Neoverse N1 cores with Ampere modifications. It supports a frequency of up to 3.3 GHz with TDP of 250 W, 8ch 72-bit DDR4, up to 4 TB DDR4-3200 per socket, 128x PCIe 4.0 Lanes, 1 MB L2 per core and 32 MB SLC. Ampere also announced their roadmap with Ampere Altra Max (2021) in development and AmpereOne (2022) defined. === 2021 === The 128-core Altra Max was released in 2021 and targeted hyperscale cloud providers. It uses the same server socket and platforms as Ampere Altra, and both products have one thread per core. The Altra Max CPUs provide 128 Arm v8.2+ cores per chip and run up to 3.0 GHz. They also support eight channels of DDR4-3200 memory and 128 lanes of PCIe Gen4. Also in 2021, Oracle launched its Oracle Cloud Infrastructure (OCI) using Ampere Altra processors. === 2022 === In February 2022, Ampere and Rigetti Computing announced a strategic partnership to create hybrid quantum-classical computers. The companies will combine Ampere's Altra Max CPUs with Rigetti's Quantum Processing Units (QPU) in cloud-based High-Performance Computing (HPC) environments. In April, Microsoft previewed its Azure Virtual Machines running on the Ampere Altra. The VMs run scale-out workloads, web servers, application servers, open source databases, cloud native .NET applications, Java applications, gaming servers, media servers, and other processes. In May, Ampere announced the sampling of AmpereOne CPUs, 5 nanometer chips based on its in-house Ampere-developed core. AmpereOne will add support for DDR5 main memory and PCIe Gen5 peripherals. On June 28, 2022, HPE became first tier-one server provider to offer compute with optimized cloud-native silicon for service providers and enterprises embracing cloud-native development with new line of HPE ProLiant RL Gen11 servers, using Ampere® Altra® and Ampere® Altra® Max processors, delivering high performance and power efficiency. === 2023 === During April 2023, Ampere released the Altra developer's kit, an IoT Prototype Kit based on Ampere Altra, aimed at cloud developers, available in 32-core, 64-core, and 80-core formats. === 2024 === In May 2024, Ampere updated its AmpereOne roadmap to 256 cores and announced a joint effort with Qualcomm on CPUs and accelerators. == Customers == Ampere's customers include Microsoft Azure, Tencent Cloud, Oracle, ByteDance, Hewlett Packard Enterprise (HPE), Cloudflare, Equinix, Kingsoft Cloud, Meituan, Scaleway, UCloud, Foxconn Industrial Internet, Gigabyte, Inspur, Cruise, Hetzner, Project Ronin, Wiwynn and Google Cloud Platform Cruise uses an Ampere Altra variant for its autonomous driving unit. The CPU was selected because of its throughput and low power consumption. In 2021, Oracle, Microsoft, Tencent, and ByteDance committed to using Ampere's customized chips, first announced in May. In April 2022, Microsoft previewed Ampere Altra processors in its new Azure D-and E- series virtual machines. The Dpsv5 series is built for Linux enterprise application types, and the Epsv5 series is for memory-intensive Linux workloads. They provide up to 64 vCPUs, include VM sizes with 2GiB, 4GiB, and 8GiB per vCPU memory configurations, up to 40 Gbit/s networking, and high-performance local SSD storage. In 2022, Microsoft's Ampere Altra-based Azure servers became the first cloud solution provider server to be Arm SystemReady SR certified. The Azure VMs, powered by Altra processors, were also the first to be SystemReady Virtual Environment standard certified. SystemReady defines a set of firmware and hardware standards as a baseline for system development for software developers, original equipment vendors, and chipmakers.
Joint constraints
Joint constraints are rotational constraints on the joints of an artificial system. They are used in an inverse kinematics chain, in fields including 3D animation or robotics. Joint constraints can be implemented in a number of ways, but the most common method is to limit rotation about the X, Y and Z axis independently. An elbow, for instance, could be represented by limiting rotation on X and Z axis to 0 degrees, and constraining the Y-axis rotation to 130 degrees. To simulate joint constraints more accurately, dot-products can be used with an independent axis to repulse the child bones orientation from the unreachable axis. Limiting the orientation of the child bone to a border of vectors tangent to the surface of the joint, repulsing the child bone away from the border, can also be useful in the precise restriction of shoulder movement.
Yorba (software)
Yorba is a web-based personal information management platform for finding, monitoring, or deleting online accounts and subscriptions. Yorba is a participating member of Consumer Reports’ Data Rights Protocol (DRP) consortium that develops open technical standards for exercising consumer data rights under laws including the California Consumer Privacy Act. == History == Yorba began as a research project around 2021. It was founded by Chris Zeunstrom (CEO), Nolan Cabeje (CDO) and David Schmudde (CTO). Zeunstrom says he began developing Yorba after growing frustrated with managing numerous email accounts, noting overloaded inboxes create distraction and potential security vulnerabilities. Yorba’s early development was also influenced by security issues he encountered at a previous company, which had been affected by data breaches at a time when such incidents were becoming increasingly common. In 2023, Yorba launched a private beta as a public benefit corporation funded through a give-back model operated by Zeunstrom's New York-based design firm, Ruca. In January 2024, Yorba entered public beta and reported over 1,000 users, including 160 premium subscribers. At the time of the public beta launch, Yorba integrated with Gmail and announced plans to expand compatibility to other online services and cloud storage providers. In September 2024, Yorba completed conformance testing under the Data Rights Protocol, an initiative developed by Consumer Reports, to establish a standard and open-source framework for securely transmitting consumer data rights requests under laws like the California Consumer Privacy Act. Yorba was named among twelve participating companies that implemented the protocol alongside OneTrust and Consumer Reports’ own Permission Slip app. Yorba was one of nine startups selected as 2025 finalist in the Santander X Global Awards international entrepreneurship competition. == Features == Yorba scans user inbox history data to identify online accounts, mailing lists, and possible data breaches. It uses natural language processing and machine learning to identify a user's accounts, services, and subscriptions. The platform prompts password resets for compromised accounts and locates unused accounts. The platform also supports mailing list management by identifying and helping users unsubscribe from newsletters. Paid subscribers can locate and cancel recurring charges. Yorba links with financial institutions in the U.S., Canada, and EU via Plaid Inc. to detect recurring charges and delete unwanted subscriptions. == Privacy and Ethics == Yorba's founder has openly criticized dark patterns that make canceling services difficult, citing personal frustration with inbox clutter as part of his inspiration for Yorba. Yorba offers privacy policy analysis in partnership with Amsterdam-based nonprofit Terms of Service; Didn’t Read, assigning grades based on invasiveness or ethical concerns. As of 2024, the company described its pricing as designed to cover operational costs and sustain the platform without outside investment.