AI Coding Assistant

AI Coding Assistant — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

Anti-Grain Geometry

Anti-Grain Geometry (AGG) is a 2D rendering graphics library written in C++. It features anti-aliasing and sub-pixel resolution. It is not a graphics library, per se, but rather a framework to build a graphics library upon. The library is operating system independent and renders to an abstract memory object. It comes with examples interfaced to the X Window System, Microsoft Windows, Mac OS X, AmigaOS, BeOS, SDL. The examples also include an SVG viewer. The design of AGG uses C++ templates only at a very high level, rather than extensively, to achieve the flexibility to plug custom classes into the rendering pipeline, without requiring a rigid class hierarchy, and allows the compiler to inline many of the method calls for high performance. For a library of its complexity, it is remarkably lightweight: it has no dependencies above the standard C++ libraries and it avoids the C++ STL in the implementation of the basic algorithms. The implicit interfaces are not well documented, however, and this can make the learning process quite cumbersome. While AGG version 2.5 is licensed under the GNU General Public License, version 2 or greater, AGG version 2.4 is still available under the 3-clause BSD license and is virtually the same as version 2.5. == History == Active development of the AGG codebase stalled in 2006, around the time of the v2.5 release, due to shifting priorities of its main developer and maintainer Maxim Shemanarev. M. Shemanarev remained active in the community until his sudden death in 2013. Development has continued on a fork of the more liberally licensed v2.4 on SourceForge.net. == Usage == The Haiku operating system uses AGG in its windowing system. It is one of the renderers available for use in GNU's Gnash Flash player. Graphical version of Rebol language interpreter is using AGG for scalable vector graphics DRAW dialect. Hilti uses it in some of their rebar detection tools, like the PS 1000. Matplotlib uses AGG as its canonical renderer for interactive user interfaces. fpGUI Toolkit has an optional AggPas back-end rendering engine. Work is being done to make AggPas the default or sole rendering engine for fpGUI. Mapnik, the toolkit that renders the maps on the OpenStreetMap website, uses AGG for all its bitmap map rendering by default. HTTPhotos uses AGG to scale photos. Pdfium, the PDF rendering engine used by Google Chrome makes use of AGG, although work is progressing to replace this with Skia Graphics Engine. Graphics Mill, the .NET imaging SDK uses AGG as its drawing engine. Image-Line FL Studio, a digital audio workstation, since version 10.8 released on September 30, 2012, uses AGG for drawing. Native Instruments's Supercharger and Supercharger GT compressors use AGG for its user interface. == Author == The main author of the library was Maxim Shemanarev (Russian: Максим Шеманарёв). On November 26, 2013 Shemanarev (born June 15, 1966, Nizhny Novgorod, Russia) was reported dead at the age of 47 at his home in Columbia, Maryland (US). He died suddenly, allegedly from an epileptic seizure that he had suffered for a while. He was a graduate from Nizhny Novgorod State Technical University. Little is known about his personal life. It's known though that he was divorced and his mother was alive at the time of his death. He used to love skiing, snowboarding (in Colorado), and inline skating. He was praised by his friends for his intelligent programming skills.
Read more →
General-Purpose AI Code of Practice

The General-Purpose AI Code of Practice (GPAI CoP) is a compliance tool released by the European Commission on 10 July 2025 to support compliance with the European Union Artificial Intelligence Act (AI Act). It provides operational guidance for providers of general-purpose AI models, particularly in relation to Articles 53 and 55 of the AI Act, which entered into application on 2 August 2025. The Code is organised into three chapters (Transparency, Copyright, and Safety and Security) and outlines how providers can meet the Act's relevant obligations. Although non-binding, providers can rely on adherence to the Code, meaning that EU regulators will assume that providers following the Code meet the corresponding legal requirements of the AI Act. As such, signatories to the Code will benefit from reduced administrative burdens and increased legal certainty compared to providers that prove compliance in other ways. While adherence to the Code is voluntary, compliance with the AI Act is not. == Background == The EU AI Act, adopted in 2024, established a risk-based regulatory regime for artificial intelligence in the European Union. The rationale for the GPAI CoP stems from Article 56 of the AI Act, which empowers the EU AI Office to develop a voluntary rulebook to guide how AI model providers can meet their legal obligations – specifically those found in Articles 53 and 55. Under Articles 53 and 55, developers of general-purpose AI models whose training compute exceeds 1023 floating-point operations (FLOPs) and that are placed on the EU market must meet transparency obligations and put in place a policy for EU copyright law. Models trained with more than 1025 FLOPs are classified as presenting systemic risk and are subject to enhanced safety requirements. The Commission may also designate a model as presenting systemic risk if it has equivalent impact or capabilities (Annex XIII criteria), even below that compute figure. Because the AI Act is relatively vague on how model providers should implement these requirements, the Code is meant to help by detailing processes and practices for compliance. == Drafting process == The development of the GPAI CoP was drawn up by 13 independent experts and involved four thematic working groups: Transparency & Copyright, Risk assessment for systemic risk, Technical risk mitigation for systemic risk, and Governance risk mitigation for systemic risk. Each group was coordinated by the European Union Artificial Intelligence Office (EU AI Office), drawing on contributions from nearly 1,000 stakeholders, including AI developers, academics, civil society organisations, national authorities, and international observers. The Code underwent three earlier iterations in November 2024, December 2024, and March 2025, before the final version was published on 10 July 2025, more than two months later than initially planned. The GPAI CoP will likely be updated continuously by the EU AI Office, alongside other tools such as the training data summary template. == Signatories == Among U.S.-based technology companies, Amazon, Anthropic, Google, IBM, Microsoft, and OpenAI have signed the GPAI CoP. xAI, founded by Elon Musk, has signed only one of the three chapters, namely the safety and security chapter. Prominent European AI companies that have signed include Aleph Alpha and Mistral AI. The European Commission maintains an updated list of signatories. As of January 2026, Meta is the most notable company that has declined to sign the Code. Major Chinese AI companies, such as Alibaba, Baidu or Deepseek, have also not signed. Providers that do not sign the GPAI CoP will still have to adhere to the binding requirements of the EU AI Act. The European Commission has indicated that it may take tougher action against companies that didn't sign the Code. == Transparency and Copyright chapters == The first two chapters of the GPAI CoP address transparency and copyright compliance and apply to all GPAI providers. They offer a way to demonstrate compliance with their obligations under Article 53 AI Act. The Transparency chapter addresses the documentation of a model's capabilities, limitations, and points of contact, and expects providers to make key documentation available to downstream providers. Signatories must also publish summaries of the content used to train their models. In the Copyright chapter, Signatories commit to follow a policy that aligns with EU copyright law. For example, they commit to mitigating the risk of copyright-infringing output. == Safety and Security chapter == The Safety and Security chapter is the most extensive chapter of the Code, and it applies to GPAI models with systemic risk, meaning it's only relevant to the small number of providers of the most advanced models. It specifies how Signatories commit to meeting Article 55(1) obligations to: Conduct model evaluations to identify systemic risks Assess and mitigate those risks Track and report serious incidents Ensure the cyber and physical security of their models The chapter outlines a comprehensive risk management process that must be applied before major deployment decisions, such as releasing a new systemic-risk GPAI model in the EU market, or substantially updating an existing one. Signatories commit to identifying systemic risks of their model, analysing and evaluating them, determining whether risk levels are acceptable, and implementing mitigation measures if necessary. This process should be repeated until models achieve an acceptable level of risk across all identified risks. === Risk identification === Signatories commit to analysing and evaluating at least four “specified” categories of systemic risk: CBRN (chemical, biological, radiological, and nuclear) Loss of control Cyber offence Harmful manipulation They are also expected to identify other systemic risks to public health, safety, and fundamental rights. The Code instructs providers to consider model capabilities, propensities, and affordances in this identification. Signatories commit to developing risk scenarios illustrating how identified risks could materialise in real-world conditions. === Risk analysis and risk evaluation === After identifying potential systemic risks, Signatories commit to analysing and evaluating the risks in order to determine whether they are acceptable or not, drawing on scientific literature, training data analysis, incident databases, expert consultation, and other sources. They also commit to conducting state-of-the-art model evaluations such as benchmarking, red teaming, and human uplift studies, targeting each risk. The risk analysis process is interconnected: insights from risk modelling should inform model evaluation design, while post-market monitoring should feed back into ongoing analysis. Signatories commit to ultimately estimating the likelihood and severity of each systemic risk. ==== Independent external model evaluations ==== Appendix 3.5 of the Safety and Security chapter requires signatories to ensure that independent external evaluators conduct model evaluations. Signatories may claim an exemption from this requirement only if they can demonstrate that their model is “similarly safe” to another model that has already been shown to comply with the Code, or if they are unable to appoint an appropriately qualified evaluator. The determination of “similarly safe” is based on comparable performance on benchmarks and the similarity of other model characteristics, such as their architecture. The CoP acknowledges that this kind of information is typically available only for models by the same provider, or potentially for open-weights or open-source models. === Risk acceptance criteria === The Code requires providers to compare estimated risks against predefined acceptance criteria, which must be measurable, based on model capabilities, and defined preemptively. While providers get to determine the level of risk they deem acceptable themselves, the pre-defined criteria and acceptance thresholds ensure providers cannot adjust their level of tolerance flexibly ahead of deployment decisions. Only if all risks are below acceptable levels should a model be deployed. === Continuous risk management and governance === The Code mandates ongoing risk management throughout the model lifecycle, including light-touch evaluations, continuous mitigation, post-market monitoring, and incident tracking and reporting. It further requires organisational governance structures assigning responsibility for risk management and expects providers to promote a “healthy risk culture,” including informing employees about the whistleblower protection policy, allowing internal challenges of decisions concerning systemic risk management, and committing to not retaliating against employees who disclose concerns about systemic risks to oversight authorities. === Documentation and transparency === Signatories commit to creating two types of documentation: Safety and Security Frame
Read more →
Linagora

Linagora is a French open source software editor, founded in June 2000 by Alexandre Zapolsky and Michel-Marie Maudet. Located in France, as well as in Belgium, Canada, Vietnam, the United States and Tunisia, the company employs around 200 people. In 2023, Linagora created the OpenLLM France community, alongside other French Artificial Intelligence companies and organizations. In 2025, the company launched Lucie, an opensource Large Language Model. == History == Linagora was founded on June 28, 2000. Its name is a contraction of the words "Linux" and "Agora". The company was founded by Alexandre Zapolsky and Michel-Marie Maudet. Soon after, the two entrepreneurs were joined by Alexandre Zapolsky's wife and brother, who took on the roles of commercial director and administrative and financial director of the SME. In 2007, the company was selected by the French National Assembly to provide the software for Linux computers, replacing Microsoft Windows. Linagora then claimed the position of the leading French open source software company by revenue. In 2015, French Prime Minister Manuel Valls allocated €10.7 million from the "Investments for the Future" fund for a research program aimed at developing a new generation of open source software platforms based on Linagora's offerings. In September 2016, Linagora launched the social network "La Cerise" for the newspaper L'Humanité. This app offered a service and tool for readers and citizens mobilizing for causes. It aimed to share engagement through petitions, discussions, agendas, and contacts. In October 2016, the company won two public contracts for supporting open source software in forty-two French ministries and other administrative entities. In May 2019, Linagora organized a fundraising event in the presence of the French Secretary of State for Digital Affairs, Cédric O, to celebrate its 19th anniversary. The funds were intended for: Supporting parents of hospitalized Polynesian children in France. Equipping primary school students with digital devices (tablets or PCs). Establishing a digital academy "OpenHackademy" in French Polynesia to train unemployed youth in digital skills and help them find jobs. In December 2022, Linagora acquired a property known as "Maison Rocher" and later "Maison Chocolat," located on the Île Saint-Germain in Issy-les-Moulineaux. Renamed "Villa Good Tech" by Linagora, this award-winning architectural work by Éric Daniel-Lacombe became the company's new headquarters, aiming to provide a space for associative actors and companies to develop technologies that contribute to a better world. In July 2023, Linagora launched OpenLLM France, a community initially comprising around twenty actors focused on generative AI. The goal was to develop a sovereign and open source large language model. This initiative, led by co-founder and CEO Michel-Marie Maudet, had more than four hundred French members by early 2024. and announced its expansion to the European sphere during Fosdem 2024. In February 2024, the CNRS and Linagora signed a framework agreement to strengthen their research collaboration. In January 2025, Linagora released Lucie, an open source and sovereign AI that faced ridicule due to tests on an unfinished, uncensored version designed for scientific and experimental use. The platform divided opinions between those who saw it as a technological achievement and those who criticized it as "French bashing" compared to American and Chinese AIs. == Acquisitions == The company acquired: In July 2007, the SME AliaSource, based in Ramonville-Saint-Agne and led by its founder, Pierre Baudracco. In 2008, the open source web hosting company Netaktiv, a member of the GIE Gitoyen, announced during the 2008 Solutions Linux trade show. In 2012, the Toulouse-based company EBM Websourcing, the publisher of the open-source software Petals Link, and took over its development. In 2016, the digital agency Neoma Interactive, specializing in UX design and digital communication strategy. == Locations == In 2017, the company's headquarters was located in Issy-les-Moulineaux, with branches in Lyon, Toulouse, Marseille, and internationally in Brussels, San Francisco, Montreal, Vietnam, and Tunisia. In 2005, the company attempted to establish a presence in Nantes. In 2024, the headquarters was moved to Issy-les-Moulineaux. == Activity == === Software === Twake Workplace One of Linagora's flagship products is Twake Workplace, which stands out as a 100% open-source solution compared with those of the GAFAMs. Twake Workplace is available as a complete platform or module by module. It includes : Twake Mail, a powerful modern messaging solution based on the JMAP protocol and the James email server from the Apache Foundation, for which Linagora provides technical management; Twake Chat, an instant communications solution for businesses developed using the Matrix protocol and compatible with the French government's chat solution, Tchap; Twake Drive, an easy-to-use collaborative platform for group work using OnlyOffice. ==== OpenPaaS ==== In 2018, the search engine Qwant announced that its email service Qwantmail would be based on the OpenPaaS product. In 2022, Qwant announced the abandonment of its Qwantmail project due to Linagora's collection of personal email addresses and serious security breaches. The site Next (formerly PC INpact) published an article in January 2020 criticizing the "failures and delays" of the Qwantmail project led by Linagora, which led to the CNIL's intervention regarding Qwant and Linagora. ==== LinTO ==== In 2017, Linagora launched its open source voice assistant project named LinTO. This enterprise voice assistant, described as "GAFAM Free," was presented at CES 2018 in Las Vegas. The LinTO voice framework was developed as part of the eponymous research project funded by Bpifrance (Grands Défis du Numérique instrument). === Services === ==== OSSA (Open Source Software Assurance) ==== One of the company's main activities is OSSA. Through OSSA, Linagora provided support for open source software for 42 ministries and other administrative entities in 2012. == Legal issues == === Dispute with BlueMind === In 2012, a legal dispute arose between BlueMind and Linagora. Linagora accused BlueMind of copyright infringement, unfair competition, and breach of a non-compete clause, leading to several legal actions. Linagora sued BlueMind for copyright infringement and unfair competition in the Bordeaux court, which ruled in Linagora's favor for unfair competition and parasitism but rejected the copyright claim. BlueMind was ordered to pay nearly €170,000 to Linagora. Linagora sued former associates Pierre Baudracco and Pierre Carlier in the Paris Commercial Court for breach of a non-compete clause and violation of a warranty of eviction. The court dismissed Linagora's claims and ordered it to pay €20,000 each to Baudracco and Carlier. Linagora appealed, and the Paris Court of Appeal partially overturned the decision, awarding Linagora €480,000. BlueMind sued Linagora for defamation and public insult in the Toulouse Criminal Court. The court ruled against Linagora, but the decision was overturned by the Court of Cassation in January 2024, and the case was remanded for retrial. === Conviction for wrongful termination and harassment === On June 14, 2017, France 3 reported on a decision by the Versailles Court of Appeal, which ruled that Linagora had wrongfully terminated an employee and subjected them to moral harassment. The court ordered Linagora to pay the employee €22,000 for wrongful termination, €11,000 for notice pay, €6,600 for legal severance pay, €3,200 for conservative suspension, and €3,000 for moral harassment.
Read more →
Drools

Drools is a business rule management system (BRMS) with a forward and backward chaining inference-based rules engine, more correctly known as a production rule system, using an enhanced implementation of the Rete algorithm. Drools supports the Java Rules Engine API (Java Specification Request 94) standard for its business rule engine and enterprise framework for the construction, maintenance, and enforcement of business policies in an organization, application, or service. == Drools in Apache Kie == Drools, as part of the Kie Community has entered Apache Incubator in January, 2023. == Red Hat Decision Manager == Red Hat Decision Manager (formerly Red Hat JBoss BRMS) is a business rule management system and reasoning engine for business policy and rules development, access, and change management. JBoss Enterprise BRMS is a productized version of Drools with enterprise-level support available. JBoss Rules is also a productized version of Drools, but JBoss Enterprise BRMS is the flagship product. Components of the enterprise version: JBoss Enterprise Web Platform – the software infrastructure, supported to run the BRMS components only JBoss Enterprise Application Platform or JBoss Enterprise SOA Platform – the software infrastructure, supported to run the BRMS components only Business Rules Engine – Drools Expert using the Rete algorithm and the Drools Rule Language (DRL) Business Rules Manager – Drools Guvnor - Guvnor is a centralized repository for Drools Knowledge Bases, with rich web-based GUIs, editors, and tools to aid in the management of large numbers of rules. Business Rules Repository – Drools Guvnor Drools and Guvnor are JBoss Community open source projects. As they are mature, they are brought into the enterprise-ready product JBoss Enterprise BRMS. Components of the JBoss Community version: Drools Guvnor (Business Rules Manager) – a centralized repository for Drools Knowledge Bases Drools Expert (rule engine) – uses the rules to perform reasoning Drools Flow (process/workflow), or jBPM 5 – provides for workflow and business processes Drools Fusion (event processing/temporal reasoning) – provides for complex event processing Drools Planner/OptaPlanner (automated planning) – optimizes automated planning, including NP-hard planning problems == Example == This example illustrates a simple rule to print out information about a holiday in July. It checks a condition on an instance of the Holiday class, and executes Java code if that condition is true. The purpose of dialect "mvel" is to point the getter and setters of the variables of your Plain Old Java Object (POJO) classes. Consider the above example, in which a Holiday class is used and inside the circular brackets (parentheses) "month" is used. So with the help of dialect "mvel" the getter and setters of the variable "month" can be accessed. Dialect "java" is used to help us write our Java code in our rules. There is one restriction or characteristic on this. We cannot use Java code inside the "when" part of the rule but we can use Java code in the "then" part. We can also declare a Reference variable $h1 without the $ symbol. There is no restriction on this. The main purpose of putting the $ symbol before the variable is to mark the difference between variables of POJO classes and Rules.
Read more →
Astrostatistics

Astrostatistics is a discipline which spans astrophysics, statistical analysis and data mining. It is used to process the vast amount of data produced by automated scanning of the cosmos, to characterize complex datasets, and to link astronomical data to astrophysical theory. Many branches of statistics are involved in astronomical analysis including nonparametrics, multivariate regression and multivariate classification, time series analysis, and especially Bayesian inference. The field is closely related to astroinformatics.
Read more →
Learning Applied to Ground Vehicles

The Learning Applied to Ground Vehicles (LAGR) program, which ran from 2004 until 2008, had the goal of accelerating progress in autonomous, perception-based, off-road navigation in robotic unmanned ground vehicles (UGVs). LAGR was funded by DARPA, a research agency of the United States Department of Defense. == History and background == While mobile robots had been in existence since the 1960s, (e.g. Shakey), progress in creating robots that could navigate on their own, outdoors, off-road, on irregular, obstacle-rich terrain had been slow. In fact, no clear metrics were in place to measure progress. A baseline understanding of off-road capabilities began to emerge with the DARPA PerceptOR program in which independent research teams fielded robotic vehicles in unrehearsed Government tests that measured average speed and number of required operator interventions over a fixed course over widely spaced waypoints. These tests exposed the extreme challenges of off-road navigation. While the PerceptOR vehicles were equipped with sensors and algorithms that were state-of-the-art for the beginning of the 21st century, the limited range of their perception technology caused them to become trapped in natural cul-de-sacs. Furthermore, their reliance on pre-scripted behaviors did not allow them to adapt to unexpected circumstances. The overall result was that except for essentially open terrain with minimal obstacles, or along dirt roads, the PerceptOR vehicles were unable navigate without numerous, repeated operator intervention. The LAGR program was designed to build on the methodology started in PerceptOR while seeking to overcome the technical challenges exposed by the PerceptOR tests. == LAGR goals == The principal goal of LAGR was to accelerate progress in off navigation of UGVs. Additional, synergistic goals included (1) establishing benchmarking methodology for measuring progress for autonomous robots operating in unstructured environments, (2) advancing machine vision and thus enabling long-range perception, and (3) increasing the number of institutions and individuals who were able to contribute to forefront UGV research. == Structure and rationale of the LAGR program == The LAGR program was designed to focus on developing new science for robot perception and control rather than on new hardware. Thus, it was decided to create a fleet of identical, relatively simple robots that would be supplied to the LAGR researchers, who were members of competitive teams, freeing them to concentrate on algorithm development. The teams were each given two robots of the standard design. They developed new software on these robots, and then sent the code to a government test team that then tested that code on Government robots at various test courses. These courses were located throughout the US and were not previously known to the teams. In this way, the code from all teams could be tested in essentially identical circumstances. After an initial startup period, the code development/test cycle was repeated about once every month. The standard robot was designed and built by the Carnegie Mellon University National Robotics Engineering Center (CMU NREC). The vehicles’ computers were preloaded with a modular “Baseline” perception and navigation system that was essentially the same system that CMU NREC had created for the PerceptOR program and was considered to represent the state-of-the-art at the inception of LAGR. The modular nature of the Baseline system allowed the researchers to replace parts of the Baseline code with their own modules and still have a complete working system without having to create an entire navigation system from scratch. Thus, for example, they were able to compare the performance of their own obstacle detection module with that of the Baseline code, while holding everything else fixed. The Baseline code also served as a fixed reference – in any environment and at any time in the program, teams’ code could be compared to the Baseline code. This rapid cycle gave the Government team and the performer teams quick feedback and allowed the Government team to design test courses that challenged the performers in specific perception tasks and whose difficulty was likely to challenge, but not overwhelm, the performers’ current capabilities. Teams were not required to submit new code for every test, but usually did. Despite this leeway, some teams found the rapid test cycle distracting to their long term progress and would have preferred a longer interval between tests. === Phase II === To advance to Phase II, each team had to modify the Baseline code so that on the final 3 tests of Phase I of the government tests, robots running the team's code averaged at least 10% faster than a vehicle running the original Baseline code. This rather modest “Go/ No Go” metric was chosen to allow teams to choose risky, but promising approaches that might not be fully developed in the first 18 months of the program. All 8 teams achieved this metric, with some scoring more twice the speed of the Baseline on the later tests which was the objective for Phase II. Note that the Phase I Go / No Go metric was such that teams were not in completion with each other for a limited number of slots on Phase II: any number of teams, from eight to zero could make the grade. This strategy by DARPA was to designed to encourage cooperation and even code sharing among the teams. == The LAGR teams == Eight teams were selected as performers in Phase I, the first 18 months of LAGR. The teams were from Applied Perception (Principal Investigator [PI] Mark Ollis), Georgia Tech (PI Tucker Balch), Jet Propulsion Laboratory (PI Larry Matthies), Net-Scale Technologies (PI Urs Muller), NIST (PI James Albus), Stanford University (PI Sebastian Thrun), SRI International (PI Robert Bolles), and University of Pennsylvania (PI Daniel Lee). The Stanford team resigned at the end of Phase I to focus its efforts on the DARPA Grand Challenge; it was replaced by a team from the University of Colorado, Boulder (PI Greg Grudic). Also in Phase II, the NIST team suspended its participation in the competition and instead concentrated on assembling the best software elements from each team into a single system. Roger Bostelman became PI of that effort. == The LAGR vehicle == The LAGR vehicle, which was about the size of a supermarket shopping cart, was designed to be simple to control. (A companion DARPA program, Learning Locomotion, addressed complex motor control.) It was battery powered and had two independently driven wheelchair motors in the front, and two caster wheels in the rear. When the front wheels were rotated in the same direction the robot was driven either forward or reverse. When these wheels were driven in opposite directions, the robot turned. The ~ $30,000 cost of the LAGR vehicle meant that a fleet could be built and distributed to a number of teams expanding on the field of researchers who had traditionally participated in DARPA robotics programs. The vehicle's top speed of about 3 miles/ hour and relatively modest weight of ~100 kg meant that it posed a much reduced safety hazard compared to vehicles used in previous programs in unmanned ground vehicles and thus further reduced the budget required for each team to manage its robot. Nevertheless, the LAGR vehicles were sophisticated machines. Their sensor suite included 2 pairs of stereo cameras, an accelerometer, a bumper sensor, wheel encoders, and a GPS. The vehicle also had three computers that were user-programmable. == Scientific results == A cornerstone of the program was incorporation of learned behaviors in the robots. In addition, the program used passive optical systems to accomplish long-range scene analysis. The difficulty of testing UGV navigation in unstructured, off-road environments made accurate, objective measurement of progress a challenging task. While no absolute measure of performance had been defined in LAGR, the relative comparison of a team's code to that of the Baseline code on a given course demonstrated whether progress was being made in that environment. By the conclusion of the program, testing showed that many of the performers had attained leaps in performance. In particular, average autonomous speeds were increased by factor of 3 and useful visual perception was extended to ranges as far as 100 meters. While LAGR did succeed in extending the useful range of visual perception, this was primarily done by either pixel or patch-based color or texture analysis. Object recognition was not directly addressed. Even though the LAGR vehicle had a WAAS GPS, its position was never determined down to the width of the vehicle, so it was hard for the systems to re-use obstacle maps of areas the robots had previously traversed since the GPS continually drifted. The drift was especially severe if there was a forest canopy. A few teams developed visual odometry algorithms that essentially eliminated this drift.
Read more →
WYSIWYM (interaction technique)

What you see is what you meant (WYSIWYM) is a text editing interaction technique that emerged from two projects at University of Brighton. It allows users to create abstract knowledge representations such as those required by the Semantic Web using a natural language interface. Natural language understanding (NLU) technology is not employed. Instead, natural language generation (NLG) is used in a highly interactive manner. The text editor accepts repeated refinement of a selected span of text as it becomes progressively less vacuous of authored semantics. Using a mouse, a text property held in the evolving text can be further refined by a set of options derived by NLG from a built-in ontology. An invisible representation of the semantic knowledge is created which can be used for multilingual document generation, formal knowledge formation, or any other task that requires formally specified information. The two projects at Brighton worked in the field of Conceptual Authoring to lay a foundation for further research and development of a Semantic Web Authoring Tool (SWAT). This tool has been further explored as a means for developing a knowledge base by those without prior experience with Controlled Natural Language tools.
Read more →
Strategic Computing Initiative

The United States government's Strategic Computing Initiative funded research into advanced computer hardware and artificial intelligence from 1983 to 1993. The initiative was designed to support various projects that were required to develop machine intelligence in a prescribed ten-year time frame, from chip design and manufacture, computer architecture to artificial intelligence software. The Department of Defense spent a total of $1 billion on the project. The inspiration for the program was Japan's fifth generation computer project, an enormous initiative that set aside billions for research into computing and artificial intelligence. As with Sputnik in 1957, the American government saw the Japanese project as a challenge to its technological dominance. The British government also funded a program of their own around the same time, known as Alvey, and a consortium of U.S. companies funded another similar project, the Microelectronics and Computer Technology Corporation. The goal of SCI, and other contemporary projects, was nothing less than full machine intelligence. "The machine envisioned by SC", according to Alex Roland and Philip Shiman, "would run ten billion instructions per second to see, hear, speak, and think like a human. The degree of integration required would rival that achieved by the human brain, the most complex instrument known to man." The initiative was conceived as an integrated program, similar to the Apollo moon program, where different subsystems would be created by various companies and academic projects and eventually brought together into a single integrated system. Roland and Shiman wrote that "While most research programs entail tactics or strategy, SC boasted grand strategy, a master plan for an entire campaign." The project was funded by the Defense Advanced Research Projects Agency and directed by the Information Processing Technology Office (IPTO). By 1985 it had spent $100 million, and 92 projects were underway at 60 institutions: half in industry, half in universities and government labs. Robert Kahn, who directed IPTO in those years, provided the project with its early leadership and inspiration. Clint Kelly managed the SC Initiative for three years and developed many of the specific application programs for DARPA, such as the Autonomous Land Vehicle. By the late 1980s, it was clear that the project would fall short of realizing the hoped-for levels of machine intelligence. Program insiders pointed to issues with integration, organization, and communication. When Jack Schwarz ascended to the leadership of IPTO in 1987, he cut funding to artificial intelligence research (the software component) "deeply and brutally", "eviscerating" the program (wrote Pamela McCorduck). Schwarz felt that DARPA should focus its funding only on those technologies which showed the most promise. In his words, DARPA should "surf", rather than "dog paddle", and he felt strongly AI was not "the next wave". The project was superseded in the 1990s by the Accelerated Strategic Computing Initiative and then by the Advanced Simulation and Computing Program. These later programs did not include artificial general intelligence as a goal, but instead focused on supercomputing for large scale simulation, such as atomic bomb simulations. The Strategic Computing Initiative of the 1980s is distinct from the 2015 National Strategic Computing Initiative—the two are unrelated. == Results == Although the program failed to meet its goal of high-level machine intelligence, it did meet some of its specific technical objectives, for example those of autonomous land navigation. The Autonomous Land Vehicle program and its sister Navlab project at Carnegie Mellon University, in particular, laid the scientific and technical foundation for many of the driverless vehicle programs that came after it, such as the Demo II and III programs (ALV being Demo I), Perceptor, and the DARPA Grand Challenge. The use of video cameras plus laser scanners and inertial navigation units pioneered by the SCI ALV program form the basis of almost all commercial driverless car developments today. It also helped to advance the state of the art of computer hardware to a considerable degree. On the software side, the initiative funded development of the Dynamic Analysis and Replanning Tool (DART), a program that handled logistics using artificial intelligence techniques. This was a huge success, saving the Department of Defense billions during Desert Storm. Introduced in 1991, DART had by 1995 offset the monetary equivalent of all funds DARPA had channeled into AI research for the previous 30 years combined.
Read more →
Poop Map

Poop Map is a social app where users can track on a map where and when they defecate. In addition to logging location and time of each bowel movement, users can also add a photo, "like" other users' logs, and rate each account. The social elements of the app allow for groups of users to create a competitive league. Certain behaviors unlock achievements in-app. == Development == The app was created by app developer Nino Uzelac. It was launched in July 2013. == Popularity == The app charted at number one on the Apple App Store charts in 2021 after going viral on TikTok. As of September 2024, the app has a 4.8 rating on the App Store and more than 58,000 ratings. It also has more than one million downloads on the Google Play Store. Poop Map is notably popular among hikers, and has been written about in the outdoors magazine Outside.
Read more →
Safe Superintelligence Inc.

Safe Superintelligence Inc. (SSI Inc.) is an Israeli-American artificial intelligence company founded by Ilya Sutskever, the former chief scientist of OpenAI; Daniel Gross, former head of Apple’s AI efforts; and Daniel Levy, an investor and AI researcher. The company's mission is to focus on safely developing a superintelligence, a computer-based agent capable of surpassing human intelligence. == History == On May 15, 2024, OpenAI co-founder Ilya Sutskever left OpenAI after a board dispute where he voted to fire Sam Altman amid concerns about communication and trust. Sutskever and others additionally believed that OpenAI was neglecting its original focus on safety in favor of pursuing opportunities for commercialization. On June 19, 2024, Sutskever posted on X that he was starting SSI Inc, with the goal to safely develop superintelligent AI, alongside Daniel Levy, and Daniel Gross. The company, composed of a small team, is split between Palo Alto, California and Tel Aviv, Israel. In September 2024, SSI revealed it had raised $1 billion from venture capital firms including SV Angel, DST Global, Sequoia Capital, and Andreessen Horowitz. The money will be used to build up more computing power and hire top individuals in the field. In March 2025, SSI reached a $30 billion valuation in a funding round led by Greenoaks Capital. This is six times its previous $5 billion valuation from September 2024. Despite not yet generating revenue and having approximately 20 employees, the company has attracted significant investor interest, largely due to co-founder Ilya Sutskever's reputation and its focus on developing safe superintelligence. In April 2025, Google Cloud announced a partnership to provide TPUs for SSI's research. In the first half of 2025, Meta attempted to acquire SSI but was rebuffed by Sutskever. In July 2025, co-founder Gross left the company to join Meta Superintelligence Labs, and Sutskever became the CEO of SSI.
Read more →
The Emperor's New Mind

The Emperor's New Mind: Concerning Computers, Minds and The Laws of Physics is a 1989 book by the mathematical physicist Roger Penrose that posits a quantum mind theory. Penrose argues that human consciousness is non-algorithmic, and thus is not capable of being modeled by a conventional Turing machine, which includes a digital computer. Penrose hypothesizes that quantum mechanics plays an essential role in the understanding of human consciousness. The collapse of the quantum wavefunction is seen as playing an important role in brain function. Most of the book is spent reviewing, for the scientifically-minded lay-reader, a plethora of interrelated subjects such as Newtonian physics, special and general relativity, the philosophy and limitations of mathematics, quantum physics, cosmology, and the nature of time. Penrose intermittently describes how each of these bears on his developing theme: that consciousness is not "algorithmic". Only the later portions of the book address the thesis directly. == Overview == Penrose states that his ideas on the nature of consciousness are speculative, and his thesis is considered erroneous by some experts in the fields of philosophy, computer science, and robotics. The Emperor's New Mind attacks the claims of artificial intelligence using the physics of computing: Penrose notes that the present home of computing lies more in the tangible world of classical mechanics than in the imponderable realm of quantum mechanics. The modern computer is a deterministic system that for the most part simply executes algorithms. Penrose shows that, by reconfiguring the boundaries of a billiard table, one might make a computer in which the billiard balls act as message carriers and their interactions act as logical decisions. The billiard-ball computer was first designed some years ago by Edward Fredkin and Tommaso Toffoli of the Massachusetts Institute of Technology. == Reception == Following the publication of the book, Penrose began to collaborate with Stuart Hameroff on a biological analog to quantum computation involving microtubules, which became the foundation for his subsequent book, Shadows of the Mind: A Search for the Missing Science of Consciousness. Penrose won the Science Book Prize in 1990 for The Emperor's New Mind. According to an article in the American Journal of Physics, Penrose incorrectly claims a barrier far away from a localized particle can affect the particle.
Read more →
AgMES

The AgMES (Agricultural Metadata Element set) initiative was developed by the Food and Agriculture Organization (FAO) of the United Nations and aims to encompass issues of semantic standards in the domain of agriculture with respect to description, resource discovery, interoperability, and data exchange for different types of information resources. There are numerous other metadata schemas for different types of information resources. The following list contains a list of a few examples: Document-like Information Objects (DLIOs): Dublin Core, Agricultural Metadata Element Set (AgMES) Events: VCalendar Geographic and Regional Information: Geographic information—Metadata ISO/IEC 11179 Standards Persons: Friend-of-a-friend (FOAF), vCard Plant Production and Protection: Darwin Core (1.0 and 2.0) (DwC) AgMES as a namespace is designed to include agriculture specific extensions for terms and refinements from established standard metadata namespaces like Dublin Core, AGLS etc. Thus, to be used for Document-like Information Objects, for example like publications, articles, books, web sites, papers, etc., it will have to be used in conjunction with the standard namespaces mentioned before. The AgMES initiative strives to achieve improved interoperability between information resources in agricultural domain by enabling means for exchange of information. Describing a DLIO with AgMES means exposing its major characteristics and contents in a standard way that can be reused easily in any information system. The more institutions and organizations in the agricultural domain that use AgMES to describe their DLIOs, the easier it will be to interchange data in between information systems like digital libraries and other repositories of agricultural information. == Use of AgMES == Metadata on agricultural Document-like Information Objects (DLIOs) can be created and stored in various formats: embedded in a web site (in the manner as with the HTML meta tag) in a separate metadata database in an XML file in an RDF file AgMES defines elements that can be used to describe a DLIO that can be used together with other metadata standards such as the Dublin Core, the Australian Government Locator Service. A complete list of all elements, refinements and schemes endorsed by AgMES is available from the AgMES website. === Creating application profiles === Application profiles are defined as schemas which consist of data elements drawn from one or more namespaces, combined by implementers, and optimized for a particular local application. Application profiles share the following four characteristics: They draw upon existing pool of metadata definition standards to extract suitable application- or requirement oriented elements. An application profile cannot create new elements. Application profiles specify the application specific details such as the schemes or controlled vocabularies. An application profile also contains information such as the format for the element value, cardinality or data type. Lastly, an application profile can refine standardized definitions as long as it is "semantically narrower or more specific". This capability of application profiles caters to situations where a domain specific terminology is needed to replace a more general one. === Sample application profiles using AgMES === The AGRIS Application Profile is a standard created specifically to enhance the description, exchange and subsequent retrieval of agricultural Document-like Information Objects (DLIOs). It is a format that allows sharing of information across dispersed bibliographic systems and is based on well-known and accepted metadata standards. The Event Application Profile is a standard created to allow members of the Agricultural community to 'know' about an upcoming event and guide them to the event Web site where they can find further information. The information communicated is thus minimum yet interoperable across domains and organizations. == AgMES and the semantic web == One of the advantages of the AgMES metadata schema is the ability to link between the metadata element and controlled vocabularies. The use of controlled vocabulary provides a "known" set of options to the indexer (and the search programmer) as to how the field can be filled out. Often the values may come from a specific thesaurus (e.g. AGROVOC) or classification schemes (e.g. the AGRIS/CARIS classification scheme) etc. Thanks to the possibility to use controlled vocabularies for metadata elements, the user is provided with the most precise information. In this context, work is also being carried out on exploiting the power of controlled vocabularies expressed as using URIs and machine-understandable semantics. In this context, FAO is promoting the Agricultural Ontology Service (AOS) initiative with the objective of expressing more semantics within the traditional thesaurus AGROVOC and build a Concept Server as a repository from which it will be always possible to extract traditional KOS.
Read more →
Cloud-native computing

Cloud native computing is an approach in software development that utilizes cloud computing to "build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds". These technologies, such as containers, microservices, serverless functions, cloud native processors and immutable infrastructure, deployed via declarative code are common elements of this architectural style. Cloud native technologies focus on minimizing users' operational burden. Cloud native techniques "enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil." This independence contributes to the overall resilience of the system, as issues in one area do not necessarily cripple the entire application. Additionally, such systems are easier to manage, and monitor, given their modular nature, which simplifies tracking performance and identifying issues. Frequently, cloud-native applications are built as a set of microservices that run in Open Container Initiative compliant containers, such as Containerd, and may be orchestrated in Kubernetes and managed and deployed using DevOps and Git CI workflows (although there is a large amount of competing open source that supports cloud-native development). The advantage of using containers is the ability to package all software needed to execute into one executable package. The container runs in a virtualized environment, which isolates the contained application from its environment.
Read more →
Script theory

Script theory is a psychological theory which posits that human behaviour largely falls into patterns called scripts because they function the way a written script does, by providing a program for action. Silvan Tomkins created script theory as a further development of his affect theory, which regards human beings' emotional responses to stimuli as falling into categories called affects: he noticed that the purely biological response of affect may be followed by awareness and by what we cognitively do in terms of acting on that affect, so that more was needed to produce a complete explanation of what he called human being theory. These scripts fall under the larger cognitive concept called schemas, which are organized chunks of information. A schema is a script that has the potential to lack the specificity of the sequence of events. A schema becomes a script is when there is an ordering to it that requires action, such as the process of starting a car (get in, put on the seatbelt, turn the car on, release the emergency brake, etc.). In script theory, the basic unit of analysis is called a scene, defined as a sequence of events linked by the affects triggered during the experience of those events. Tomkins recognized that affective experiences fall into patterns that we may group together according to criteria, such as the types of persons and places involved and the degree of intensity of the effect experienced—the patterns of which constitute scripts that inform behavior in an effort to maximize positive affect and to minimize negative affect. == In artificial intelligence == Roger Schank, Robert P. Abelson and their research group extended Tomkins' scripts and used them in early artificial intelligence work as a method of representing procedural knowledge. In their work, scripts are very much like frames, except the values that fill the slots must be ordered. A script is a structured representation describing a stereotyped sequence of events in a particular context. Scripts are used in natural-language understanding systems to organize a knowledge base in terms of the situations that the system should understand. The classic example of a script involves the typical sequence of events that occur when a person drinks in a restaurant: finding a seat, reading the menu, ordering drinks from the waitstaff, etc. In the script form, these would be decomposed into conceptual transitions, such as MTRANS and PTRANS, which refer to mental transitions [of information] and physical transitions [of things]. Schank, Abelson and their colleagues tackled some of the most difficult problems in artificial intelligence (i.e., story understanding), but ultimately their line of work ended without tangible success. This type of work received little attention after the 1980s, but became very influential in later knowledge representation techniques, such as case-based reasoning. Scripts can be inflexible. To deal with inflexibility, smaller modules called memory organization packets (MOP) can be combined in a way that is appropriate for the situation.
Read more →
Composite Capability/Preference Profiles

Composite Capability/Preference Profiles (CC/PP) is a specification for defining capabilities and preferences of user agents (also known as "delivery context"). The delivery context can be used to guide the process of tailoring content for a user agent. CC/PP is a vocabulary extension of the Resource Description Framework (RDF). The CC/PP specification is maintained by the W3C's Ubiquitous Web Applications Working Group (UWAWG) Working Group. == History == Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0 became a W3C recommendation on 15 January 2004. A "Last-Call Working-Draft" of CC/PP 2.0 was issued in April 2007
Read more →