T-vertices is a term used in computer graphics to describe a problem that can occur during mesh refinement or mesh simplification. The most common case occurs in naive implementations of continuous level of detail, where a finer-level mesh is "sewn" together with a coarser-level mesh by simply aligning the finer vertices on the edges of the coarse polygons. The result is a continuous mesh, however due to the nature of the z-buffer and certain lighting algorithms such as Gouraud shading, visual artifacts can often be detected. Some modeling algorithms such as subdivision surfaces will fail when a model contains T-vertices.
GNU social
GNU social (and its predecessor StatusNet) is a largely defunct free and open-source microblogging social networking service that implements the OStatus and ActivityPub standards for interoperability between installations. While offering similar functionality to social networks such as Twitter, GNU social seeks to provide the ability for open and federated communication between different microblogging communities, known as 'instances'. Both enterprises and individuals can install and control their own instances and user data. At its peak in popularity, GNU social had been deployed on hundreds of interconnected instances, however has since fallen into disuse as competing software like Mastodon and Pleroma have taken its position as the dominant federated microblogging services. Later on in its lifespan, the project split into two separate branches, with "v2" being a continuation of the original codebase for maintenance of existing instances, with "v3" being a complete redesign of the project meant to integrate further ActivityPub support and modernization of the user experience and its technological back-end. As of August 15, 2022, there had been no new commits to the v2 branch, with the v3 branch also no longer being actively developed not long after by November 25, 2022, with the project essentially abandoned. Despite its modern obsolescence and dated design compared to modern platforms, GNU social and StatusNet is regarded to be the origin of the Fediverse network and has had a major influence on the design of more modern decentralized social networks that succeeded it. == History == While being the main project within its lineage, GNU social originally began as a fork of StatusNet. The software was first developed for a service called identi.ca from Evan Prodromou, which offered free microblogging accounts to the public. The software quickly became one of the first popular examples of a decentralized social network, as identi.ca allowed any other server that was running the software to communicate with it, something which had not previously been attempted before in social media at such a large scale. === StatusNet === Originally, StatusNet (named Laconica at the time) was launched with a communication protocol designed specifically for the project called OpenMicroBlogging (OMB). With version 0.8.1, the name of the software was changed to StatusNet. Version 0.9.0 was released soon after in March 3, 2010, with the developers implementing a newly designed protocol dubbed OStatus, with support for OMB being dropped not long after. Compared to OpenMicroBlogging, OStatus could handle and federate more events and actions than the basic plaintext communication that OMB provided and was based on a variety of other web technologies, allowing for easier adoption of new implementations of the protocol for servers and clients compared to the fully custom architecture of OMB. With the StatusNet name change, the company developing both the software and OStatus as well as managing identi.ca rebranded from Control Yourself to StatusNet Inc. In August 2010, the company raised a new round of venture capital funds to establish a hosting service under the status.net domain from sources such as First Mark Capital, BOLDstart Ventures, iNovia Capital and Montreal Start Up, raising over $2.3 million in funding up to that point. The hosting service allowed anyone to establish their own StatusNet instance without maintaining a server, similar to WordPress.com and other blogging platforms. New registrations on identi.ca along with the ability to create new status.net instances was disabled in December 2012, in preparation for a migration to pump.io that has since been named by users of StatusNet and OStatus as "the Pumpocalypse". pump.io was a brand new software package like StatusNet, but with a new protocol designed for general purpose activity streams outside of microblogging and ease-of-use for developers building on the technology, much like the transition from OMB to OStatus. The announcement was seen as unexpected among identi.ca users, who were concerned about the possibility of their statuses being deleted with the transition. At the same time, server administrators running third-party instances and their users who were left behind on StatusNet were also worried, as it was unclear at the time whether future development of the software would be picked up by a new maintainer. The transition for identi.ca users to pump.io was completed on 12 July 2013. ==== Previous names ==== The original name of StatusNet was Laconica, a reference to the Laconic phrase; a particularly brief statement commonly attributed to the leaders of Sparta (Laconia being the Greek region containing Sparta). In microblogging, all messages are designed to be very short due to the traditional 140-character limit on message size, a limitation imported from SMS. Beginning with version 0.8.1, the name was changed to StatusNet. The developers said that the new name "simply reflects what our software does: send status updates into your social network." === GNU social === GNU social originally began as a side project of GNU FM (Libre.fm) maintainer Matt Lee, with the goal of being able to federate messages between Last.fm and other instances of GNU FM using StatusNet plugins. Around the same time, a developer named Mikael Nordfeldth forked StatusNet with the intention of maintaining it as a personal project, dubbing it "Free Social". However, following identi.ca's transition to pump.io and its developers' sudden abandonment of StatusNet, the projects received more attention from server administrators and other users looking for an actively updated alternative. Shortly after LibrePlanet 2012, a plan was formed to merge all three projects into a single service. On June 8, 2013, it was announced that along with Free Social, StatusNet would be merged into the GNU social project and stewarded by the Free Software Foundation, with the project since becoming the dominant variant of StatusNet. During GNU social's lifespan, a popular theme for the user interface named Quitter was used, which was similar to an earlier Twitter interface. Many instances were made specifically using the name Quitter such as Quitter.se, an instance created by the developer of the theme. Before the establishment of Mastodon's popularity and dominance within the network, Quitter was noted as a frequent location for users of Twitter to migrate to when users disagreed with moderation policies or feature updates, such as when an algorithmic feed was added to Twitter. A fork of GNU social was made called postActiv, which planned to rewrite the backend and user interface of GNU social, as well as to add compatibility for Diaspora's protocol. == Features == A basic GNU social instance takes the form of a microblogging service with a reverse chronological timeline that features status updates and small messages from followed accounts, similar to other services such as Twitter or Weibo. While users could see their own customized timeline, they could access another timeline that showcased every message that the instance knows of, including from other instances that were connected to each other if someone on the instance followed an account from it. Users could also create and join groups, which allows for discussion and collaboration on specific topics. Administrators can also customize their server via the plugin system, which allows developers to create new features or modify existing plugins to suit the needs of the instance via PHP. A notable plugin built for GNU social was Quitter, a revamp of the user interface that resembles an earlier version of Twitter's user interface.
AIVA
AIVA (Artificial Intelligence Virtual Artist) is an electronic composer recognized by the SACEM. == Description == Created in February 2016, AIVA specializes in classical and symphonic music composition. It became the world's first virtual composer to be recognized by a music society (SACEM). By reading a large collection of existing works of classical music (written by human composers such as Bach, Beethoven, Mozart) AIVA is capable of detecting regularities in music and on this base composing on its own. The algorithm AIVA is based on deep learning and reinforcement learning architectures. Since January 2019, the company offers a commercial product, Music Engine, capable of generating short (up to 3 minutes) compositions in various styles (rock, pop, jazz, fantasy, shanty, tango, 20th century cinematic, modern cinematic, and Chinese). AIVA was presented at TED by Pierre Barreau. == Discography == AIVA is a published composer; its first studio album "Genesis" was released in November 2016. Second album "Among the Stars" in 2018. 2016 CD album « Genesis » Hv-Com – LEPM 048427. Track listing "Genesis": 2018 CD album « Among the Stars » Hv-Com – LEPM 048708 Avignon Symphonic Orchestra [ORAP] also performed Aiva's compositions [2] in April 2017.
Archival bond
The archival bond is a concept in archival theory referring to the relationship that each archival record has with the other records produced as part of the same transaction or activity and located within the same grouping. These bonds are a core component of each individual record and are necessary for transforming a document into a record, as a document will only acquire meaning (and become a record) through its interrelationships with other records. == Description == The concept of the archival bond is primarily associated with the work of Luciana Duranti along with Heather MacNeil, as part of research into the integrity of electronic records. Duranti resumed and extended the concept of vincolo archivistico (archival bond), first expressed in 1937 by archivist Giorgio Cencetti of the Italian archival school. This bond emerges from the fact that electronic records are not physically arranged like traditional records. For traditional, analog records, their bond is implicit in their arrangement. But for electronic records, this bond must be made explicit due to the lack of a single sequential order of records in a digital environment. The archival bond was one of the core concepts of the subsequent International Research on Permanent Authentic Records in Electronic Systems (InterPARES) project and can be found in the InterPARES glossary. As Duranti notes, the archival bond is not to be confused with the broader term "context" as context exists independently of a record, while "the archival bond is an essential part of the record, which would not exist without it."
Behavior selection algorithm
In artificial intelligence, a behavior selection algorithm, or action selection algorithm, is an algorithm that selects appropriate behaviors or actions for one or more intelligent agents. In game artificial intelligence, it selects behaviors or actions for one or more non-player characters. Common behavior selection algorithms include: Finite-state machines Hierarchical finite-state machines Decision trees Behavior trees Hierarchical task networks Hierarchical control systems Utility systems Dialogue tree (for selecting what to say) == Related concepts == In application programming, run-time selection of the behavior of a specific method is referred to as the strategy design pattern.
Automotive security
Automotive security refers to the branch of computer security focused on the cyber risks related to the automotive context. The increasingly high number of ECUs in vehicles and, alongside, the implementation of multiple different means of communication from and towards the vehicle in a remote and wireless manner led to the necessity of a branch of cybersecurity dedicated to the threats associated with vehicles. Not to be confused with automotive safety. == Causes == The implementation of multiple ECUs (Electronic Control Units) inside vehicles began in the early '70s thanks to the development of integrated circuits and microprocessors that made it economically feasible to produce the ECUs on a large scale. Since then the number of ECUs has increased to up to 100 per vehicle. These units nowadays control almost everything in the vehicle, from simple tasks such as activating the wipers to more safety-related ones like brake-by-wire or ABS (Anti-lock Braking System). Autonomous driving is also strongly reliant on the implementation of new, complex ECUs such as the ADAS, alongside sensors (lidars and radars) and their control units. Inside the vehicle, the ECUs are connected with each other through cabled or wireless communication networks, such as CAN bus (controller area network), MOST bus (Media Oriented System Transport), FlexRay (Automotive Network Communications Protocol) or RF (radio frequency) as in many implementations of TPMSs (tire-pressure monitoring systems). Many of these ECUs require data received through these networks that arrive from various sensors to operate and use such data to modify the behavior of the vehicle (e.g., the cruise control modifies the vehicle's speed depending on signals arriving from a button usually located on the steering wheel). Since the development of cheap wireless communication technologies such as Bluetooth, LTE, Wi-Fi, RFID and similar, automotive producers and OEMs have designed ECUs that implement such technologies with the goal of improving the experience of the driver and passengers. Safety-related systems such as the OnStar from General Motors, telematic units, communication between smartphones and the vehicle's speakers through Bluetooth, Android Auto and Apple CarPlay. == Threat model == Threat models of the automotive world are based on both real-world and theoretically possible attacks. Most real-world attacks aim at the safety of the people in and around the car, by modifying the cyber-physical capabilities of the vehicle (e.g., steering, braking, accelerating without requiring actions from the driver), while theoretical attacks have been supposed to focus also on privacy-related goals, such as obtaining GPS data on the vehicle, or capturing microphone signals and similar. Regarding the attack surfaces of the vehicle, they are usually divided in long-range, short-range, and local attack surfaces: LTE and DSRC can be considered long-range ones, while Bluetooth and Wi-Fi are usually considered short-range although still wireless. Finally, USB, OBD-II and all the attack surfaces that require physical access to the car are defined as local. An attacker that is able to implement the attack through a long-range surface is considered stronger and more dangerous than the one that requires physical access to the vehicle. In 2015 the possibility of attacks on vehicles already on the market has been proven possible by Miller and Valasek, that managed to disrupt the driving of a Jeep Cherokee while remotely connecting to it through remote wireless communication. === Controller area network attacks === The most common network used in vehicles and the one that is mainly used for safety-related communication is CAN, due to its real-time properties, simplicity, and cheapness. For this reason the majority of real-world attacks have been implemented against ECUs connected through this type of network. The majority of attacks demonstrated either against actual vehicles or in testbeds fall in one or more of the following categories: ==== Sniffing ==== Sniffing in the computer security field generally refers to the possibility of intercepting and logging packets or more generally data from a network. In the case of CAN, since it is a bus network, every node listens to all communication on the network. It is useful for the attacker to read data to learn the behavior of the other nodes of the network before implementing the actual attack. Usually, the final goal of the attacker is not to simply sniff the data on CAN, since the packets passing on this type of network are not usually valuable just to read. ==== Denial of service ==== Denial of service (DoS) in information security is usually described as an attack that has the objective of making a machine or a network unavailable. DoS attacks against ECUs connected to CAN buses can be done both against the network, by abusing the arbitration protocol used by CAN to always win the arbitration, and targeting the single ECU, by abusing the error handling protocol of CAN. In this second case the attacker flags the messages of the victim as faulty to convince the victim of being broken and therefore shut itself off the network. ==== Spoofing ==== Spoofing attacks comprise all cases in which an attacker, by falsifying data, sends messages pretending to be another node of the network. In automotive security usually spoofing attacks are divided into masquerade and replay attacks. Replay attacks are defined as all those where the attacker pretends to be the victim and sends sniffed data that the victim sent in a previous iteration of authentication. Masquerade attacks are, on the contrary, spoofing attacks where the data payload has been created by the attacker. == Real life automotive threat example == Security researchers Charlie Miller and Chris Valasek have successfully demonstrated remote access to a wide variety of vehicle controls using a Jeep Cherokee as the target. They were able to control the radio, environmental controls, windshield wipers, and certain engine and brake functions. The method used to hack the system was implementation of pre-programmed chip into the controller area network (CAN) bus. By inserting this chip into the CAN bus, he was able to send arbitrary message to CAN bus. One other thing that Miller has pointed out is the danger of the CAN bus, as it broadcasts the signal which the message can be caught by the hackers throughout the network. The control of the vehicle was all done remotely, manipulating the system without any physical interaction. Miller states that he could control any of some 1.4 million vehicles in the United States regardless of the location or distance, the only thing needed is for someone to turn on the vehicle to gain access. The work by Miller and Valasek replicated earlier work completed and published by academics in 2010 and 2011 on a different vehicle. The earlier work demonstrated the ability to compromise a vehicle remotely, over multiple wireless channels (including cellular), and the ability to remotely control critical components on the vehicle post-compromise, including the telematics unit and the car's brakes. While the earlier academic work was publicly visible, both in peer-reviewed scholarly publications and in the press, the Miller and Valesek work received even greater public visibility. == Security measures == The increasing complexity of devices and networks in the automotive context requires the application of security measures to limit the capabilities of a potential attacker. Since the early 2000 many different countermeasures have been proposed and, in some cases, applied. Following, a list of the most common security measures: Sub-networks: to limit the attacker capabilities even if he/she manages to access the vehicle from remote through a remotely connected ECU, the networks of the vehicle are divided in multiple sub-networks, and the most critical ECUs are not placed in the same sub-networks of the ECUs that can be accessed from remote. Gateways: the sub-networks are divided by secure gateways or firewalls that block messages from crossing from a sub-network to the other if they were not intended to. Intrusion Detection Systems (IDS): on each critical sub-network, one of the nodes (ECUs) connected to it has the goal of reading all data passing on the sub-network and detect messages that, given some rules, are considered malicious (made by an attacker). The arbitrary messages can be caught by the passenger by using IDS which will notify the owner regarding with unexpected message. Authentication protocols: in order to implement authentication on networks where it is not already implemented (such as CAN), it is possible to design an authentication protocol that works on the higher layers of the ISO OSI model, by using part of the data payload of a message to authenticate the message itself. Hardware Security Modules: since many ECUs are not powerful enough to keep real-time delays whi
Two-phase commit protocol
In transaction processing, databases, and computer networking, the two-phase commit protocol (2PC, tupac) is a type of atomic commitment protocol (ACP). It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction. This protocol (a specialised type of consensus protocol) achieves its goal even in many cases of temporary system failure (involving either process, network node, communication, etc. failures), and is thus widely used. However, it is not resilient to all possible failure configurations, and in rare cases, manual intervention is needed to remedy an outcome. To accommodate recovery from failure (automatic in most cases) the protocol's participants use logging of the protocol's states. Log records, which are typically slow to generate but survive failures, are used by the protocol's recovery procedures. Many protocol variants exist that primarily differ in logging strategies and recovery mechanisms. Though usually intended to be used infrequently, recovery procedures compose a substantial portion of the protocol, due to many possible failure scenarios to be considered and supported by the protocol. In a "normal execution" of any single distributed transaction (i.e., when no failure occurs, which is typically the most frequent situation), the protocol consists of two phases: The commit-request phase (or voting phase), in which a coordinator process attempts to prepare all the transaction's participating processes (named participants, cohorts, or workers) to take the necessary steps for either committing or aborting the transaction and to vote, either "Yes": commit (if the transaction participant's local portion execution has ended properly), or "No": abort (if a problem has been detected with the local portion), and The commit phase, in which, based on voting of the participants, the coordinator decides whether to commit (only if all have voted "Yes") or abort the transaction (otherwise), and notifies the result to all the participants. The participants then follow with the needed actions (commit or abort) with their local transactional resources (also called recoverable resources; e.g., database data) and their respective portions in the transaction's other output (if applicable). The two-phase commit (2PC) protocol should not be confused with the two-phase locking (2PL) protocol, a concurrency control protocol. == Assumptions == The protocol works in the following manner: one node is a designated coordinator, which is the master site, and the rest of the nodes in the network are designated the participants. The protocol assumes that: there is stable storage at each node with a write-ahead log, no node crashes forever, the data in the write-ahead log is never lost or corrupted in a crash, and any two nodes can communicate with each other. The last assumption is not too restrictive, as network communication can typically be rerouted. The first two assumptions are much stronger; if a node is totally destroyed then data can be lost. The protocol is initiated by the coordinator after the last step of the transaction has been reached. The participants then respond with an agreement message or an abort message depending on whether the transaction has been processed successfully at the participant. == Basic algorithm == === Commit request (or voting) phase === The coordinator sends a query to commit message to all participants and waits until it has received a reply from all participants. The participants execute the transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their redo log. Each participant replies with: either an agreement message (participant votes Yes to commit), if the participant's actions succeeded; or an abort message (participant votes No to commit), if the participant experiences a failure that will make it impossible to commit. === Commit (or completion) phase === ==== Success ==== If the coordinator received an agreement message from all participants during the commit-request phase: The coordinator sends a commit message to all the participants. Each participant completes the operation, and releases all the locks and resources held during the transaction. Each participant sends an acknowledgement to the coordinator. The coordinator completes the transaction when all acknowledgements have been received. ==== Failure ==== If any participant votes No during the commit-request phase (or the coordinator's timeout expires): The coordinator sends a rollback message to all the participants. Each participant undoes the transaction using the undo log, and releases the resources and locks held during the transaction. Each participant sends an acknowledgement to the coordinator. The coordinator undoes the transaction when all acknowledgements have been received. ==== Message flow ==== Coordinator Participant QUERY TO COMMIT --------------------------------> VOTE YES/NO prepare/abort <------------------------------- commit/abort COMMIT/ROLLBACK --------------------------------> ACKNOWLEDGEMENT commit/abort <-------------------------------- end An next to the record type means that the record is forced to stable storage. == Disadvantages == The greatest disadvantage of the two-phase commit protocol is that it is a blocking protocol. If the coordinator fails permanently, some participants will never resolve their transactions: After a participant has sent an agreement message as a response to the commit-request message from the coordinator, it will block until a commit or rollback is received. A two-phase commit protocol cannot dependably recover from a failure of both the coordinator and a cohort member during the commit phase. If only the coordinator had failed, and no cohort members had received a commit message, it could safely be inferred that no commit had happened. If, however, both the coordinator and a cohort member failed, it is possible that the failed cohort member was the first to be notified, and had actually done the commit. Even if a new coordinator is selected, it cannot confidently proceed with the operation until it has received an agreement from all cohort members, and hence must block until all cohort members respond. == Implementing the two-phase commit protocol == === Common architecture === In many cases the 2PC protocol is distributed in a computer network. It is easily distributed by implementing multiple dedicated 2PC components similar to each other, typically named transaction managers (TMs; also referred to as 2PC agents or Transaction Processing Monitors), that carry out the protocol's execution for each transaction (e.g., The Open Group's X/Open XA). The databases involved with a distributed transaction, the participants, both the coordinator and participants, register to close TMs (typically residing on respective same network nodes as the participants) for terminating that transaction using 2PC. Each distributed transaction has an ad hoc set of TMs, the TMs to which the transaction participants register. A leader, the coordinator TM, exists for each transaction to coordinate 2PC for it, typically the TM of the coordinator database. However, the coordinator role can be transferred to another TM for performance or reliability reasons. Rather than exchanging 2PC messages among themselves, the participants exchange the messages with their respective TMs. The relevant TMs communicate among themselves to execute the 2PC protocol schema above, "representing" the respective participants, for terminating that transaction. With this architecture the protocol is fully distributed (does not need any central processing component or data structure), and scales up with number of network nodes (network size) effectively. This common architecture is also effective for the distribution of other atomic commitment protocols besides 2PC, since all such protocols use the same voting mechanism and outcome propagation to protocol participants. === Protocol optimizations === Database research has been done on ways to get most of the benefits of the two-phase commit protocol while reducing costs by protocol optimizations and protocol operations saving under certain system's behavior assumptions. ==== Presumed abort and presumed commit ==== Presumed abort or Presumed commit are common such optimizations. An assumption about the outcome of transactions, either commit, or abort, can save both messages and logging operations by the participants during the 2PC protocol's execution. For example, when presumed abort, if during system recovery from failure no logged evidence for commit of some transaction is found by the recovery procedure, then it assumes that the transaction has been aborted, and acts accordingly. This means that it does not matter if aborts are logged at all, and such logging can be saved under this assumption. Typical