The AlphaChip controversy refers to a series of public, scholarly, and legal disputes surrounding a 2021 Nature paper by Google-affiliated researchers. The paper describes an approach to macro placement, a stage of chip floorplanning, based on reinforcement learning (RL), a machine learning method in which a system iteratively improves its decisions by optimizing performance-based reward signals. The primary technical question is whether the new techniques are better than existing (non-AI) techniques. Both internal Google studies and external attempts to replicate the algorithm have failed to show the claimed benefits. No head-to-head comparison is available because the data used in the paper is proprietary, and Google has not released any results from running its algorithm on public benchmarks. This has resulted in considerable skepticism over the paper's claims. In addition, the inability of others (both inside and outside of Google) to replicate the claimed results have sparked concerns about the paper’s methodology, reproducibility, and scientific integrity. The lead researchers of the Nature paper were affiliated with Google Brain, which became part of Google DeepMind, and later spun off into the company Ricursive. == Motivation for research: Macro placement in chip layout == Chip design for modern integrated circuits is a complex, expert-driven process that relies on electronic design automation. It determines the performance of the final chip, and takes weeks or months to complete. Advances that produce better designs, or complete the process faster, are commercially and academically significant. Macro placement is a step during chip design that determines the locations of large circuit components (macros) within a chip. It is followed by detailed placement, which places the far more numerous but much smaller standard cells. Alternatively, mixed-size placement simultaneously places both large macros and millions of small cells, requiring algorithms to handle objects that differ by several orders of magnitude in area and mobility. The number of macros per circuit typically ranges from several to thousands. Wiring must be performed after placement, and the details of this wiring strongly influence the power, performance, and area (PPA) of the completed chip. The full wiring calculation is very resource intensive, so placement tools typically use a proxy cost, a simplified objective function used to guide the placement algorithm during training and evaluation. The faithfulness of the chosen proxy cost to the final objective cost is a critical aspect of placer performance. === State of the art as of 2021 === Chips have been designed since the 1960s, so there were many existing methods as of 2021. Available options included manual design, academic tools, and commercial offerings. Academic methods include combinatorial optimization techniques such as simulated annealing, analytical placement, hierarchical heuristics, and as of 2019 reinforcement learning and broader machine learning techniques.. Existing (non-AI) academic tools for solving the same problem include APlace, NTUplace3, ePlace, RePlace, and DREAMPlace. Commercial EDA vendors also offered automated software tools for floorplanning and mixed-size placement. For instance, as of 2019 Cadence’s Innovus implementation software offered a Concurrent Macro Placer (CMP) feature to automatically place large blocks and standard cells. == The 2021 Nature paper and its claims == In 2021, Nature published a paper under the title “A graph‑placement methodology for fast chip design” co‑authored by 21 Google-affiliated researchers. The paper reported that an RL agent could generate macro placements for integrated circuits "in under six hours" and achieve improvements over human-designed layouts in power, timing performance, and area (PPA), standard chip-quality metrics referring respectively to energy consumption, chip operating speed, and silicon footprint (evaluated after wire routing). It introduced a sequential macro placement algorithm in which macros are placed one at a time instead of optimizing their locations concurrently. At each step, the algorithm selects a location for a single macro on a discretized chip canvas, conditioning its decision on the placements of previously placed macros. This sequential formulation converts macro placement into a long-horizon decision process in which early placement choices constrain later ones. After macro placement, force-directed placement is applied to place standard cells connected to the macros. Deep reinforcement learning is used to train a policy network to place macros by maximizing a reward that reflects final placement quality (for example, wirelength and congestion). Policy learning occurs during self‑play for one or multiple circuit designs. Further placement optimizations refine the overall layout by balancing wirelength, density, and overlap constraints, while treating the macro locations produced by the RL policy as fixed obstacles. The approach relies on pre-training, in which the RL model is first trained on a corpus of prior designs (twenty in the Nature paper) to learn general placement patterns before being fine-tuned on a specific chip. Circuit examples used in the study were parts of proprietary Google TPU designs, called blocks (or floorplan partitions). The paper reported results on five blocks and described the approach as generalizable across chip designs. == Controversy == Soon after the paper's publication, controversy arose over whether the claims were true, whether they were sufficiently proven, and whether academic standards were followed. These controversies arose both within Google and among external academic experts. === Internal dispute at Google and legal proceedings === In 2022, Satrajit Chatterjee, a Google engineer involved in reviewing the AlphaChip work, raised concerns internally and drafted an alternative analysis, (Stronger Baselines) arguing that established methods outperformed the RL approach under fair comparison. In March 2022, Google declined to publish this analysis and terminated Chatterjee's employment. Chatterjee filed a wrongful dismissal lawsuit, alleging that representations related to the AlphaChip research involved fraud and scientific misconduct. According to court documents, Chatterjee's study was conducted "in the context of a large potential Google Cloud deal". He noted that it "would have been unethical to imply that we had revolutionary technology when our tests showed otherwise" and claimed Google was deliberately withholding material information. Furthermore, the committee that reviewed his paper and disapproved its publication was allegedly chaired by subordinates of Jeff Dean, a senior co-author of the Nature paper. Google’s subsequent motion to dismiss was denied, holding that Chatterjee had plausibly alleged retaliation for refusing to engage in conduct he believed would violate state or federal law. === External controversy === The external questions can be summarized in four main points: (a) Are the claims supported by the evidence provided? (b) Did the paper provide enough information to allow the results to be independently reproduced and verified? If so, are the results an improvement over existing academic and commercial tools? (c) Were the comparisons in the paper done fairly and with full disclosure? (d) Were academic standards followed? Each of these is discussed below. ==== Are the claims supported by the evidence provided? ==== The Nature paper described the reduction in design-process time as going from "days or weeks" to "hours", but did not provide per-design time breakdowns or specify the number of engineers, their level of expertise, or the baseline tools and workflow against which this comparison was made. It was also unclear whether the "days or weeks" baseline included time spent on other tasks such as functional design changes. The paper also evaluated the method on fewer benchmarks (five) than is common in the field, and showed mixed results across different evaluation goals While the approach was described as improving circuit area, this claim seems unsupported, as the RL optimization did not alter the overall circuit area, as it adjusted only the locations of fixed-shape non-overlapping circuit components within a fixed rectangular layout boundary. ==== Comparison with existing methods, and replicating the algorithm ==== Because macro placement is largely geometric and its fundamental algorithms are not tied to a specific process node, competing approaches can be evaluated on public benchmarks (tests) across technologies, rather than primarily on proprietary internal designs. This is standard procedure when comparing academic placers, see . In contrast, Google has only reported results only on internal proprietary designs, and as of 2026 has not offered comparisons with prior methods on common benchmarks. Researchers at the University of Califor
Quantum natural language processing
Quantum natural language processing (QNLP) is the application of quantum computing to natural language processing (NLP). It computes word embeddings as parameterised quantum circuits that can solve NLP tasks faster than any classical computer. It is inspired by categorical quantum mechanics and the DisCoCat framework, making use of string diagrams to translate from grammatical structure to quantum processes. == Theory == The first quantum algorithm for natural language processing used the DisCoCat framework and Grover's algorithm to show a quadratic quantum speedup for a text classification task. It was later shown that quantum language processing is BQP-Complete, i.e. quantum language models are more expressive than their classical counterpart, unless quantum mechanics can be efficiently simulated by classical computers. These two theoretical results assume fault-tolerant quantum computation and a QRAM, i.e. an efficient way to load classical data on a quantum computer. Thus, they are not applicable to the noisy intermediate-scale quantum (NISQ) computers available today. == Experiments == The algorithm of Zeng and Coecke was adapted to the constraints of NISQ computers and implemented on IBM quantum computers to solve binary classification tasks. Instead of loading classical word vectors onto a quantum memory, the word vectors are computed directly as the parameters of quantum circuits. These parameters are optimised using methods from quantum machine learning to solve data-driven tasks such as question answering, machine translation and even algorithmic music composition.
Microsoft Support Diagnostic Tool
The Microsoft Support Diagnostic Tool (MSDT) is a legacy service in Microsoft Windows that allows Microsoft technical support agents to analyze diagnostic data remotely for troubleshooting purposes. In April 2022 it was observed to have a security vulnerability that allowed remote code execution which was being exploited to attack computers in Russia and Belarus, and later against the Tibetan government in exile. Microsoft advised a temporary workaround of disabling the MSDT by editing the Windows registry. == Use == When contacting support the user is told to run MSDT and given a unique "passkey" which they enter. They are also given an "incident number" to uniquely identify their case. The MSDT can also be run offline which will generate a .CAB file which can be uploaded from a computer with an internet connection. == Security vulnerabilities == === Follina === Follina is the name given to a remote code execution (RCE) vulnerability, a type of arbitrary code execution (ACE) exploit, in the Microsoft Support Diagnostic Tool (MSDT) which was first widely publicized on May 27, 2022, by a security research group called Nao Sec. This exploit allows a remote attacker to use a Microsoft Office document template to execute code via MSDT. This works by exploiting the ability of Microsoft Office document templates to download additional content from a remote server. If the size of the downloaded content is large enough it causes a buffer overflow allowing a payload of Powershell code to be executed without explicit notification to the user. On May 30 Microsoft issued CVE-2022-30190 with guidance that users should disable MSDT. Malicious actors have been observed exploiting the bug to attack computers in Russia and Belarus since April, and it is believed Chinese state actors had been exploiting it to attack the Tibetan government in exile based in India. Microsoft patched this vulnerability in its June 2022 patches. === DogWalk === The DogWalk vulnerability is a remote code execution (RCE) vulnerability in the Microsoft Support Diagnostic Tool (MSDT). It was first reported in January 2020, but Microsoft initially did not consider it to be a security issue. However, the vulnerability was later exploited in the wild, and Microsoft released a patch for it in August 2022. The vulnerability is caused by a path traversal vulnerability in the sdiageng.dll library. This vulnerability allows an attacker to trick a victim into opening a malicious diagcab file, which is a type of Windows cabinet file that is used to store support files. When the diagcab file is opened, it triggers the MSDT tool, which then executes the malicious code. Originally discovered by Mitja Kolsek, the DogWalk vulnerability is caused by a path traversal vulnerability in the sdiageng.dll library. This vulnerability allows an attacker to trick a victim into opening a malicious diagcab file, which is a type of Windows cabinet file that is used to store support files. When the diagcab file is opened, it triggers the MSDT tool, which then executes the malicious code. The vulnerability is exploited by creating a malicious diagcab file that contains a specially crafted path. This path contains a sequence of characters that is designed to exploit the path traversal vulnerability in the sdiageng.dll library. When the diagcab file is opened, the MSDT tool will attempt to follow the path. However, the path will contain characters that are not valid for a Windows path. This will cause the MSDT tool to crash. When the MSDT tool crashes, it will generate a memory dump. This memory dump will contain the malicious code that was executed by the MSDT tool. The attacker can then use this memory dump to extract the malicious code and execute it on their own computer. == Retirement == Microsoft will no longer be supporting the Windows legacy inbox Troubleshooters. In 2025, Microsoft will remove the MSDT platform entirely. Get Help is the replacement tool. == Windows versions == Windows 7 Windows 8.1 Windows 10 Windows 11 (up to 22H2) Future versions and feature upgrades will deprecate the MSDT after May 23, 2023.
Human Race Machine
The Human Race Machine (HRM) is a computerized console composed of four different programs. The Human Race Machine program allows participants to see themselves with the facial characteristics of six different races: Asian, White, African, Middle Eastern, and Indian, mapped onto their own face. The Age Machine allows viewers see an aged version of his or her face. A version of this methodology has been used for over twenty years by the FBI and the National Center for Missing and Exploited Children to help locate kidnap victims and missing children. The Couples Machine combines photographs of two people in different percentages to show the appearance of their child. The Anomaly Machine lets viewers see themselves with facial anomalies. The HRM was created by artist Nancy Burson and David Kramlich; it uses morphing technology. It was shown on Oprah on 2006-02-16.
Two-phase locking
In databases and transaction processing, two-phase locking (2PL) is a pessimistic concurrency control method that guarantees conflict-serializability. It is also the name of the resulting set of database transaction schedules (histories). The protocol uses locks, applied by a transaction to data, which may block (interpreted as signals to stop) other transactions from accessing the same data during the transaction's life. By the 2PL protocol, locks are applied and removed in two phases: Expanding phase: locks are acquired and no locks are released. Shrinking phase: locks are released and no locks are acquired. Two types of locks are used by the basic protocol: Shared and Exclusive locks. Refinements of the basic protocol may use more lock types. Using locks that block processes, 2PL, S2PL, and SS2PL may be subject to deadlocks that result from the mutual blocking of two or more transactions. == Read and write locks == Locks are used to guarantee serializability. A transaction is holding a lock on an object if that transaction has acquired a lock on that object which has not yet been released. For 2PL, the only used data-access locks are read-locks (shared locks) and write-locks (exclusive locks). Below are the rules for read-locks and write-locks: A transaction is allowed to read an object if and only if it is holding a read-lock or write-lock on that object. A transaction is allowed to write an object if and only if it is holding a write-lock on that object. A schedule (i.e., a set of transactions) is allowed to hold multiple locks on the same object simultaneously if and only if none of those locks are write-locks. If a disallowed lock attempts on being held simultaneously, it will be blocked. == Variants == Note that all conflict serializable schedules are also view serializable (but not vice-versa). === Two-phase locking === According to the two-phase locking protocol, each transaction handles its locks in two distinct, consecutive phases during the transaction's execution: Expanding phase (aka Growing phase): locks are acquired and no locks are released (the number of locks can only increase). Shrinking phase (aka Contracting phase): locks are released and no locks are acquired. The two phase locking rules can be summarized as: each transaction must never acquire a lock after it has released a lock. The serializability property is guaranteed for a schedule with transactions that obey this rule. Typically, without explicit knowledge in a transaction on end of phase 1, the rule is safely determined only when a transaction has completed processing and requested commit. In this case, all the locks can be released at once (phase 2). === Conservative two-phase locking === Conservative two-phase locking (C2PL) differs from 2PL in that transactions obtain all the locks they need before the actual execution begins. This is to ensure that a transaction that already holds some locks will not block waiting for other locks. C2PL prevents deadlocks. In cases of heavy lock contention, C2PL reduces the time locks are held on average, relative to 2PL and Strict 2PL, because transactions that hold locks are never blocked. In light lock contention, C2PL holds more locks than is necessary, because it is difficult to predict which locks will be needed in the future, thus leading to higher overhead. A C2PL transaction will not obtain any locks if it cannot obtain all the locks it needs in its initial request. Furthermore, each transaction needs to declare its read and write set (the data items that will be read/written), which is not always possible. Because of these limitations, C2PL is not used very frequently. === Strict two-phase locking === To comply with the strict two-phase locking (S2PL) protocol, a transaction needs to comply with 2PL, and release its write (exclusive) locks only after the transaction has ended (i.e., either committed or aborted). On the other hand, read (shared) locks are released regularly during the shrinking phase. Unlike 2PL, S2PL provides strictness (a special case of cascade-less recoverability). This protocol is not appropriate in B-trees because it causes Bottleneck (while B-trees always starts searching from the parent root). === Strong strict two-phase locking === or Rigorousness, or Rigorous scheduling, or Rigorous two-phase locking To comply with strong strict two-phase locking (SS2PL), a transaction's read and write locks are released only after that transaction has ended (i.e., either committed or aborted). A transaction obeying SS2PL has only a phase 1 and lacks a phase 2 until the transaction has completed. Every SS2PL schedule is also an S2PL schedule, but not vice versa.
List of Ruby software and tools
This is a list of software and programming tools for the Ruby programming language, which includes libraries, web frameworks, implementations, tools, and related projects. == Web tools == Capistrano (software) – remote server automation tool Mongrel – Ruby web server Rack – interface between web servers and web applications Ruby on Rails – full-stack web application framework Sinatra – lightweight Ruby web application framework Spree Commerce – e-commerce platform WEBrick – Ruby HTTP server toolkit == Libraries == BioRuby – bioinformatics and computational biology library for Ruby Bogus – Ruby library for creating reliable test doubles with contract verification ERuby – embedded Ruby templating EventMachine – event-driven I/O library Factory Bot – test fixtures library Fat comma – Ruby library for JSON-like hash syntax Geocoder – Ruby library for geocoding and reverse geocoding addresses Haml – HTML templating engine Markaby – HTML generation via Ruby Nokogiri – XML/HTML parsing library RSpec – behavior-driven testing framework for Ruby RubyGems – package manager for Ruby libraries and applications Sass – CSS preprocessor Sidekiq – background job framework for Ruby, used to handle asynchronous tasks. Uconv – Unicode text conversion library Watir – web application testing framework == Ruby implementations == HotRuby – Ruby interpreter implemented in JavaScript, enabling Ruby code to run in web browsers. IronRuby – Ruby for .NET platform JRuby – Ruby on the Java Virtual Machine MacRuby – Ruby implementation for macOS Mod ruby – Apache module that embeds the Ruby interpreter to improve performance of Ruby web applications Mruby – lightweight Ruby interpreter Rubinius – alternative Ruby implementation, based loosely on the Smalltalk-80 Blue Book design. Ruby MRI – the standard Ruby interpreter YARV – "Yet Another Ruby VM," the bytecode interpreter used in modern Ruby implementations == Tools == Homebrew – package manager for macOS and Linux written in Ruby Pry – interactive Ruby shell Rake – build and task management Ruby Version Manager – environment manager RubyCocoa – bridge between Ruby and Cocoa RubyForge – project hosting site RubyMotion – for iOS/macOS development RubySpec – language specification tests == Integrated Development Environments == Aptana Studio — integrated RadRails plugin for Ruby on Rails development Eclipse DLTK Ruby Plugin — Ruby development plugin for Eclipse Eric — open-source Python-based IDE with Ruby support Komodo IDE — commercial cross-platform IDE with Ruby support RubyMine — commercial IDE for Ruby and Rails by JetBrains SlickEdit — commercial cross-platform IDE with Ruby support == List of websites using Ruby on Rails == Airbnb Basecamp Diaspora – decentralized social network application built with Ruby on Rails Discourse – open-source discussion platform built with Ruby on Rails Fiverr GitHub Hulu Shopify SoundCloud Twitch Zendesk
Play Integrity API
Play Integrity API (formerly known as SafetyNet) consists of several application programming interfaces (APIs) offered by the Google Play Services to support security sensitive applications and enforce DRM. Currently, these APIs include device integrity verification, app verification, recaptcha and web address verification. It uses an environment called DroidGuard to perform the attestation. == Attestation == The SafetyNet Attestation API, one of the APIs under the SafetyNet umbrella, provides verification that the integrity of the device is not compromised. In practice, non-official ROMs such as LineageOS fail the hardware attestation and thus prevent the user from using a non-compliant ROM with third-party apps (mainly banking) that require the API. Due to this, some consider this a monopolistic practice deterring the entrance of competing mobile operating systems in the market. It requires a network connection to Google servers and validates the hardware signatures. Amongst the checks, the API looks for bootloader unlock status, ROM signatures, kernel strings, it also uses AVB2.0 and dm-verity attestations. Upon successful checks, Google Play will mark the device as Certified. The attestation runs in an environment called DroidGuard (com.google.android.gms.unstable). The SafetyNet Attestation API (one of the four APIs under the SafetyNet umbrella) has been deprecated. As of 6 October 2023, Google planned to replace it with the Play Integrity API by the end of January 2025. The transition ended on 20 May 2025, breaking applications which hadn't been updated. These attestations are offered by Google Play Services and thus are not available on free Android environments, like AOSP. Therefore, developers can require the API to be available and may refuse to execute on AOSP builds. == Google Play Protect == Under the same umbrella, Play Protect is a mechanism to find and remove "vulnerable" apps from one's Android device as well as store apps. Although it's meant to scan for malware-containing apps, it also looks for non-DRM compliant apps. == Criticism == Multiple groups have criticised SafetyNet and the Play Integrity API. Criticisms include that it offers weaker protection compared to alternatives such as Android's hardware attestation API, which provides a stronger form of verification while having the ability to remain compatible with more secure Android operating systems like GrapheneOS. Critics argued it undermines competition by effectively requiring developers to rely on Google's proprietary services, strengthening its monopoly over the Android ecosystem and disadvantaging alternative, privacy-focused operating systems. Users have also developed tools, such as the Play Integrity Fix module for Magisk/KernelSU/APatch, which tricks the attestation using leaked fingerprints of vulnerable devices. Furthermore, some have questioned the effectiveness of the attestation, claiming it does not deliver the level of security promised by Google and instead serves more as a form of vendor lock-in than a meaningful security measure. Activists have also raised concerns that it may violate antitrust and competition laws, like the Digital Markets Act.