AI Chatbot Q

AI Chatbot Q — independent reviews, comparisons, pricing and step-by-step guides on Aizhi.

  • SAP StreamWork

    SAP StreamWork

    SAP StreamWork is an enterprise collaboration tool from SAP SE released in March 2010, and discontinued in December 2015. StreamWork allowed real-time collaboration like Google Wave, but focused on business activities such as analyzing data, planning meetings, and making decisions. It incorporated technology from Box.net and Evernote to allow users to connect to online files and documents, and document-reader technology from Scribd allowed users to view documents directly within its environment. StreamWork supported the OpenSocial set of application programming interfaces (APIs), allowing it to connect to tools built by third-party developers, such as Google Docs. A version of StreamWork intended for large enterprises used a virtual appliance based on Novell's SUSE Linux Enterprise to connect it to business systems, including those from SAP.

    Read more →
  • System Service Descriptor Table

    System Service Descriptor Table

    The System Service Descriptor Table (SSDT) is an internal dispatch table within Microsoft Windows. == Function == The SSDT maps syscalls to kernel function addresses. When a syscall is issued by a user space application, it contains the service index as parameter to indicate which syscall is called. The SSDT is then used to resolve the address of the corresponding function within ntoskrnl.exe. In modern Windows kernels, two SSDTs are used: One for generic routines (KeServiceDescriptorTable) and a second (KeServiceDescriptorTableShadow) for graphical routines. A parameter passed by the calling userspace application determines which SSDT shall be used. == Hooking == Modification of the SSDT allows to redirect syscalls to routines outside the kernel. These routines can be either used to hide the presence of software or to act as a backdoor to allow attackers permanent code execution with kernel privileges. For both reasons, hooking SSDT calls is often used as a technique in both Windows kernel mode rootkits and antivirus software. In 2010, many computer security products which relied on hooking SSDT calls were shown to be vulnerable to exploits using race conditions to attack the products' security checks.

    Read more →
  • Hooked (app)

    Hooked (app)

    Hooked is a mobile application where users can write or read chat fiction, short pieces of fiction told in the format of text messages between fictional characters. The app was released in September 2015 and was developed by Telepathic Inc. == Features == Hooked is a freemium smartphone app that allows users to write or read short stories made up of text messages between characters. CEO Prerna Gupta described the app as "books for the Snapchat generation" or "Twitter for fiction." As of March 2019, the app had more than 40 million active users. The stories are written by a mix of professional authors and crowd-sourced participants. The most popular genres are suspense and horror. The stories usually lack literary elements like character arcs, are simply written and are intended to be suspenseful or addicting. Each piece of fiction on the app is approximately 1,000 to 1,300 words long and can be read in about five minutes. Some longer stories are told in "chapters" and a 32,000-word thriller called Dark Matter was released in 2018. The app provides a certain number of text messages for free, then delays the next text message by 15 minutes unless the user pays for a subscription. Prior to 2020, the app offered a three-day free trial and then required users to pay. According to Gupta, the app was intended to get the younger generation to read more without getting distracted. Most users of the app are between 13 and 24 years-old. == History == The Hooked app was first released in September 2015. Initially, Hooked featured about 200 stories that were written by professional authors selected by the app developers. The following year, Telepathic Inc. released Hooked 2.0, which allowed users of the app to create and share their own short stories. By mid-2016, the app had 700 stories written by professional authors and 9,000 stories written by users. Hooked had 1.8 million downloads by 2016 and 20 million download as of 2017, which generated $6.5 million in revenue. The response to Hooked prompted others to create similar text-message based short story apps, like Yarn and Tap. Sensor Tower reported that the Hooked app received 2.22 million downloads during the period from October 2016 to March 2017. Starting in 2020, longer stories divided into chapters debuted on the app. In March, the company launched Hooked TV, an app to showcase video pilots based on a number of scripts themed around the app's content. Out of 50 pilots, those that were most popular among users of the app and social media were expanded into original series as Hooked TV evolved into a streaming platform in the second half of 2021. == Background == The idea for Hooked was conceived when Gupta was working on writing a book of her own. Prerna Gupta and her husband Parag Chordia tested short stories with 15,000 people and found that readers were five times more likely to read a story to its end if the story was presented in a text message format. They created Telepathic Inc., which developed Hooked. According to Celebrity Secret when they first started out, the stories were basically as if two people were texting each other and some sort of drama unfolds. Some of their most popular initial stories were actually horror stories, where a mom gets a text from her daughter and something creepy is happening to her. Over time, they started to turn those into podcasts, which then led to making their own movies and TV shows. As of 2017, the Telepathic has raised $6 million in funding to develop and support the Hooked app. From the main website itself the Hooked investors include Sound Ventures, The Chernin Group, WME/Endeavor, MACRO, Greg Silverman, Steph Curry, Kevin Durant, LeBron James, Mariah Carey, Jamie Foxx, Joe Montana, Aasif Mandvi, Max Martin, Anjula Acharia, Savan Kotecha, Cyan Banister, Eric Ries, A Capital, SV Angel, Cowboy Ventures, Founders Fund and Greylock, among many others.

    Read more →
  • Sarpa (snakebite app)

    Sarpa (snakebite app)

    Sarpa or SARPA (Snake Awareness, Rescue and Protection app) is a snakebite app, an application for mobile devices developed in India to provide rapid, life-saving help for victims of snakebite, which kill an estimated 58,000 people a year in India. The app provides information about snakes, gets fast aid for people bitten, and helps in the development of antivenoms. Similar systems developed in India include SnakeHub, Snake Lens, Snakepedia, Serpent and the Big Four Mapping Project. The apps provide rapid response to snakebite incidents, often in remote areas, using a network of volunteers managed by local wildlife departments; their use can save human lives by providing rapid medical care, and also snakes, by helping to avoid interaction between the species. In 2026, it was announced that the app had plans to offer real-time contact from doctors directly from the app to provide users with decision-making advice.

    Read more →
  • Teechart

    Teechart

    TeeChart is a charting library for programmers, developed and managed by Steema Software of Girona, Catalonia, Spain. It is available as commercial and non-commercial software. TeeChart has been included in most Delphi and C++Builder products since 1997, and TeeChart Standard currently is part of Embarcadero RAD Studio 13 Florence. TeeChart Pro version is a commercial product that offers shareware releases for all of its formats. The TeeChart Charting Library offers charts, maps and gauges in versions for Delphi VCL/FMX, ActiveX, C# for Microsoft Visual Studio .NET. Full source code has always been available for all versions except the ActiveX version. TeeChart's user interface is translated into 38 languages. == History == The first version of TeeChart was authored in 1995 by David Berneda, co-founder of Steema, using the Borland Delphi Visual Component Library programming environment and TeeChart was first released as a shareware version and made available via Compuserve in the same year. It was written in the first version of Delphi VCL, as a 16-bit Charting Library named TeeChart version 1. The next version of TeeChart was released as a 32-bit library (Delphi 2 supported 32-bit compilation) but was badged as TeeChart VCL v3 to coincide with Borland's naming convention for inclusion on the toolbox palette of Borland Delphi v3 in 1997 and with C++ Builder v3 in 1998. It has been on the Delphi/C++ Builder toolbox palette ever since. The current version is Embarcadero RAD Studio 13 Florence. TeeChart's first ActiveX version named "version 3" too, to match the VCL version's nomenclature, was released in 1998. The version was optimised to work with Microsoft's Visual Studio v97 and v6.0 developer suites that include Visual Basic and Microsoft Visual C++ programming languages. Support for new programming environments followed with TeeChart's first native C# version for Microsoft Visual Studio .NET released in 2002 and TeeChart.Lite for .NET, a free charting component, released for Visual Studio.NET in 2003 and supporting too, Mono (programming). Steema Software released the first native TeeChart Java (programming language) version in 2006 and TeeChart's first native PHP version was released in 2009 and published as open-source in June 2010. Mobile versions of TeeChart, for Android (operating system) devices and Windows Phone 7 devices were released during the first half of 2011. In 2012 TeeChart extended functionality to iPhone/iPad and BlackBerry OS devices and a new JavaScript version was released in the same year to support HTML5 Canvas. In 2013 Steema launched TeeChart for .NET Chart for Windows Store applications and included support for Microsoft's Windows Phone 8 mobile platform. TeeChart for Xamarin.Forms written with 100% C# code and cross-platform support for .NET desktops, Windows Phone, iOS and Android was released in 2014. Also since 2014 Webforms charts now offers HTML5 interactivity. Steema launched TeeChart for Avalonia (software framework) in 2022 and in 2023 .NET_MAUI support was added to the TeeChart for .NET. == Usage == TeeChart is a general purpose charting component designed for use in differing ambits, offering a wide range of aesthetics to chart data. Generally TeeCharts published in the field, in areas where large amounts of data must be interpreted regularly, remain by designer choice in their simplest form to maximize the "data-ink ratio". Sloan Digital Sky Survey, SDSS Web Services' use for charting "Scientific .. plotting of online data" at The Virtual Observatory Spectrum Services reflects that approach. The SDSS chart authors choose to represent data using TeeChart's standard 2D line display. Speed is also a factor when choosing how to most effectively plot data. Realtime data, at frequencies of up to tens or hundreds of data points or more per second, require the most processor economic approach to charting. Computer processing time dedicated to the plotting of data needs to be as lightweight as possible, freeing-up computer tasks "to achieve real-time data acquisition, display and analysis". A critical and stated aspect of many data visualisation applications is the ability to offer interactivity to the user; NASA's document, the Orbital Debris Engineering Model Model ORDEM 3.0 - User's Guide, 2014, states that "The user may manipulate the graphs to zoom, pan, and copy to the clipboard and export to various file types" and Computer and Computing Technologies in Agriculture II, Volume 1, Daoliang, Li; Chunjiang, Zhao (2009), also using TeeChart, states "the properties at any point in the chart can be viewed moving the mouse over it". Writing about control education, Juha Lindfors states "The desired charting functionality (such as zooming and scaling) is achieved..". Charting applications have become increasingly 'onlined', made available either to a wider public or to a territorially remote userbase via networked applications. The World Wide Web (the Web) has become "by far, the most popular Internet protocol" to disseminate online applications. Most major IDEs now offer environments for web application developede aimed at browser hosted applications. Charting components, TeeChart among them, have adapted to provide models that work within a browser environment, often using static images and scripted layering techniques such as Ajax (programming) to offer a level of interactivity, improve response times and hide apparent delay from the user. Options to enrich client, browser-side processing flexibility are exploited by TeeChart libraries via modules that offer 'micro-environments' within the browser, such as the long established ActiveX technology, Adobe Flash, Microsoft Silverlight or Java Applets. Serverside environments offer too, a means to interact with browser based script to dynamically respond to charting requests. Joomla and CodeIgniter are host environments for TeeChart PHP and an example of an Embarcadero IntraWeb VCL designed application using TeeChart, is documented here. == Programmer reference == The Code Project includes a demo that uses TeeChart.Lite, called 'Self-Organizing Feature Maps (Kohonen maps)' written by Bashir Magomedovl and SourceForge includes a Database Stress and Monitor that also uses TeeChart.Lite. Books and information sources that include substantial sections about working with the Delphi version of TeeChart include "Mastering Delphi 6" by Marco Cantù, "C++ Builder 5 developer's guide", a video Delphi Tutorial on charting JPEG compression and support forums and reference pages at TeeChart Support Forums. Non-English language document sources include, in Czech "Myslíme v jazyku Delphi 7: knihovna zkušeného programátora" by Marco Cantù, and Chinese, Delphi 6, Delphi, and Delphi 5.

    Read more →
  • Commitment ordering

    Commitment ordering

    Commitment ordering (CO) is a class of interoperable serializability techniques in concurrency control of databases, transaction processing, and related applications. It allows optimistic (non-blocking) implementations. With the proliferation of multi-core processors, CO has also been increasingly utilized in concurrent programming, transactional memory, and software transactional memory (STM) to achieve serializability optimistically. CO is also the name of the resulting transaction schedule (history) property, defined in 1988 with the name dynamic atomicity. In a CO compliant schedule, the chronological order of commitment events of transactions is compatible with the precedence order of the respective transactions. CO is a broad special case of conflict serializability and effective means (reliable, high-performance, distributed, and scalable) to achieve global serializability (modular serializability) across any collection of database systems that possibly use different concurrency control mechanisms (CO also makes each system serializability compliant, if not already). Each not-CO-compliant database system is augmented with a CO component (the commitment order coordinator—COCO) which orders the commitment events for CO compliance, with neither data-access nor any other transaction operation interference. As such, CO provides a low overhead, general solution for global serializability (and distributed serializability), instrumental for global concurrency control (and distributed concurrency control) of multi-database systems and other transactional objects, possibly highly distributed (e.g., within cloud computing, grid computing, and networks of smartphones). An atomic commitment protocol (ACP; of any type) is a fundamental part of the solution, utilized to break global cycles in the conflict (precedence, serializability) graph. CO is the most general property (a necessary condition) that guarantees global serializability, if the database systems involved do not share concurrency control information beyond atomic commitment protocol (unmodified) messages and have no knowledge of whether transactions are global or local (the database systems are autonomous). Thus CO (with its variants) is the only general technique that does not require the typically costly distribution of local concurrency control information (e.g., local precedence relations, locks, timestamps, or tickets). It generalizes the popular strong strict two-phase locking (SS2PL) property, which in conjunction with the two-phase commit protocol (2PC), is the de facto standard to achieve global serializability across (SS2PL based) database systems. As a result, CO compliant database systems (with any different concurrency control types) can transparently join such SS2PL based solutions for global serializability. In addition, locking based global deadlocks are resolved automatically in a CO based multi-database environment, a vital side-benefit (including the special case of a completely SS2PL based environment; a previously unnoticed fact for SS2PL). Furthermore, strict commitment ordering (SCO; Raz 1991c), the intersection of Strictness and CO, provides better performance (shorter average transaction completion time and resulting in better transaction throughput) than SS2PL whenever read-write conflicts are present (identical blocking behavior for write-read and write-write conflicts; comparable locking overhead). The advantage of SCO is especially during lock contention. Strictness allows both SS2PL and SCO to use the same effective database recovery mechanisms. Two major generalizing variants of CO exist, extended CO (ECO; Raz 1993a) and multi-version CO (MVCO; Raz 1993b). They also provide global serializability without local concurrency control information distribution, can be combined with any relevant concurrency control, and allow optimistic (non-blocking) implementations. Both use additional information for relaxing CO constraints and achieving better concurrency and performance. Vote ordering (VO or Generalized CO (GCO); Raz 2009) is a container schedule set (property) and technique for CO and all its variants. Local VO is necessary for guaranteeing global serializability if the atomic commitment protocol (ACP) participants do not share concurrency control information (have the generalized autonomy property). CO and its variants inter-operate transparently, guaranteeing global serializability and automatic global deadlock resolution together in a mixed, heterogeneous environment with different variants. == Overview == The Commitment ordering (CO; Raz 1990, 1992, 1994, 2009) schedule property has been referred to also as Dynamic atomicity (since 1988), commit ordering, commit order serializability, and strong recoverability (since 1991). The latter is a misleading name since CO is incomparable with recoverability, and the term "strong" implies a special case. This means that a substantial recoverability property does not necessarily have the CO property and vice versa. In 2009 CO has been characterized as a major concurrency control method, together with the previously known (since the 1980s) three major methods: Locking, Time-stamp ordering, and Serialization graph testing, and as an enabler for the interoperability of systems using different concurrency control mechanisms. In a federated database system or any other more loosely defined multidatabase system, which are typically distributed in a communication network, transactions span multiple and possibly Distributed databases. Enforcing global serializability in such system is problematic. Even if every local schedule of a single database is still serializable, the global schedule of a whole system is not necessarily serializable. The massive communication exchanges of conflict information needed between databases to reach conflict serializability would lead to unacceptable performance, primarily due to computer and communication latency. The problem of achieving global serializability effectively had been characterized as open until the public disclosure of CO in 1991 by its inventor Yoav Raz (Raz 1991a; see also Global serializability). Enforcing CO is an effective way to enforce conflict serializability globally in a distributed system since enforcing CO locally in each database (or other transactional objects) also enforces it globally. Each database may use any, possibly different, type of concurrency control mechanism. With a local mechanism that already provides conflict serializability, enforcing CO locally does not cause any other aborts, since enforcing CO locally does not affect the data access scheduling strategy of the mechanism (this scheduling determines the serializability related aborts; such a mechanism typically does not consider the commitment events or their order). The CO solution requires no communication overhead since it uses (unmodified) atomic commitment protocol messages only, already needed by each distributed transaction to reach atomicity. An atomic commitment protocol plays a central role in the distributed CO algorithm, which enforces CO globally by breaking global cycles (cycles that span two or more databases) in the global conflict graph. CO, its special cases, and its generalizations are interoperable and achieve global serializability while transparently being utilized together in a single heterogeneous distributed environment comprising objects with possibly different concurrency control mechanisms. As such, Commitment ordering, including its special cases, and together with its generalizations (see CO variants below), provides a general, high performance, fully distributed solution (no central processing component or central data structure are needed) for guaranteeing global serializability in heterogeneous environments of multidatabase systems and other multiple transactional objects (objects with states accessed and modified only by transactions; e.g., in the framework of transactional processes, and within Cloud computing and Grid computing). The CO solution scales up with network size and the number of databases without any negative impact on performance (assuming the statistics of a single distributed transaction, e.g., the average number of databases involved with a single transaction, are unchanged). With the proliferation of Multi-core processors, Optimistic CO (OCO) has also been increasingly utilized to achieve serializability in software transactional memory, and numerous STM articles and patents utilizing "commit order" have already been published (e.g., Zhang et al. 2006). == The commitment ordering solution for global serializability == === General characterization of CO === Commitment ordering (CO) is a special case of conflict serializability. CO can be enforced with non-blocking mechanisms (each transaction can complete its task without having its data-access blocked, which allows optimistic concurrency control; however, commitment could be blo

    Read more →
  • Shape table

    Shape table

    Shape tables are a feature of the Apple II ROMs which allows for manipulation of small images encoded as a series of vectors. An image (or shape) can be drawn in the high-resolution graphics mode—with scaling and rotation—via software routines in the ROM. Shape tables are supported via Applesoft BASIC and from machine code in the "Programmer's Aid" package that was bundled with the original Integer BASIC ROMs for that computer. Applesoft's high-resolution graphics routines were not optimized for speed, so shape tables were not typically used for performance-critical software such as games, which were typically written in assembly language and used pre-shifted bitmap shapes. Shape tables were used primarily for static shapes and sometimes for fancy text; Beagle Bros offered a number of fonts in Font Mechanic as Applesoft shape tables. == Technical details == The vectors of a two-dimensional graphic, each encoding a direction from the previous pixel along with a flag indicating whether the new pixel should be illuminated or not, were encoded up to three in a byte. These were stored in a table via the Monitor or the POKE command. From there, the graphic could be referenced by number (a table could contain up to 255 shapes), and built-in Applesoft routines permitted scaling, rotating, and drawing or erasing the shape. An XOR mode was also available to allow the shape to be visible on any color background; this had the advantage, also, of allowing the shape to be easily erased by redrawing it. Apple did not provide any utilities for creating shape tables; they had to be created by hand, usually by plotting on graph paper, then calculating the hexadecimal values and entering them into the computer. Beagle Bros created a shape table editing program, which eliminated the "number crunching", called Apple Mechanic, and a related program, Font Mechanic.

    Read more →
  • Document-oriented database

    Document-oriented database

    A document-oriented database, or document store, is a computer program and data storage system designed for storing, retrieving, and managing document-oriented information, also known as semi-structured data. Document-oriented databases are one of the main categories of NoSQL databases, and the popularity of the term "document-oriented database" has grown alongside the adoption of NoSQL itself. XML databases are a subclass of document-oriented databases optimized for XML documents. Graph databases are similar, but add another layer, the relationship, which allows them to link documents for rapid traversal. Document-oriented databases are conceptually an extension of the key–value store, another type of NoSQL database. In key-value stores, data is treated as opaque by the database, whereas document-oriented systems exploit the internal structure of documents to extract metadata and optimize storage and queries. Although in practice the distinction can be minimal due to modern tooling, document stores are designed to provide a richer programming experience with modern programming techniques. Document databases differ significantly from traditional relational databases (RDBs). Relational databases store data in predefined tables, often requiring an object to be split across multiple tables. In contrast, document databases store all information for a given object in a single document, with each document potentially having a unique structure. This design eliminates the need for object-relational mapping when loading data into the database. == Documents == The central concept of a document-oriented database is the notion of a document. Although implementations vary in their specific definitions, document-oriented databases generally treat documents as self-contained units that encapsulate and encode data in a standardized format. Common encoding formats include XML, YAML, JSON, as well as binary representations such as BSON. Documents in a document store are equivalent to the programming concept of an object. They are not required to adhere to a fixed schema, and documents within the same collection may contain different fields or structures. Fields may be optional, and documents of the same logical type may differ in composition. For example, the following illustrates a document encoded in JSON: A second document might be encoded in XML as: The two example documents share some structural elements but also contain unique fields. The structure, text, and other data within each document are collectively referred to as the document's content and can be accessed or modified using retrieval or editing operations. Unlike relational databases, in which each record contains the same fields and unused fields are left empty, document-oriented databases do not require uniform fields across documents. This design allows new information to be added to some documents without affecting the structure of others. Document databases often support the storage of additional metadata alongside the document content. Such metadata may relate to organizational features, security, indexing, or other implementation-specific features. === CRUD operations === The core operations supported by a document-oriented database for manipulating documents are similar to those in other databases. Although terminology is not perfectly standardized, these operations are generally recognized as Create, Read, Update, and Delete (CRUD). Creation (C): Adds a new document to the database. Retrieval (R): Retrieves documents or fields based on queries. Update (U): Modifies the contents of existing documents. Deletion (D): Removes documents from the database. === Keys === Documents in a document-oriented database are addressed via a unique identifier. This identifier, often a string, URI, or path, can be used to retrieve the document from the database. Most document stores maintain an index on the key to optimize retrieval, and in some implementations the key is required when creating or inserting a new document. === Retrieval === In addition to key-based access, document-oriented databases typically provide an API or query language that enables retrieval based on document content or associated metadata. For example, a query may return all documents with a specific field matching a given value. The available query features, indexing options, and performance characteristics vary across implementations. Document stores differ from key-value stores in that they exploit the internal structure and metadata of stored documents. In many key-value stores, values are treated as opaque or "black-box" data, meaning the database system does not interpret their internal structure. By contrast, document-oriented databases can classify and interpret document content. This enables queries that distinguish between types of data––for example, retrieving all phone numbers containing "555" without also matching a postal code such as "55555." === Editing === Document databases typically provide mechanisms for updating or editing the content or metadata of a document. Updates may involve replacing the entire document or modifying individual elements or fields within the document. === Organization === Document database implementations support a variety of methods for organizing documents, including: Collections: Groups of documents. Depending on the implementation, a document may be required to belong to a single collection or may be allowed in multiple collections. Tags and non-visible metadata: Additional data stored outside the main document content. Directory hierarchies: Documents organized in a tree-like structure, often based on path or URI. These organizational structures may differ between logical and physical representations (e.g. on disk or in memory). == Relationship to other databases == === Relationship to key-value stores === A document-oriented database can be viewed as a specialized form of key-value store, which is itself a category of NoSQL database. In a basic key-value store, the stored value is typically treated as opaque by the database system. By contrast, a document-oriented database provides APIs or a query and update language that allows queries and modifications based on the internal structure of the document. For users who do not require advanced query, retrieval, or update capabilities, the distinction between document-oriented databases and key-value stores may be minimal. === Relationship to search engines === Some search engine and information retrieval systems, such as Apache Solr and Elasticsearch, provide document storage and support core document operations. As a result, they may meet certain functional definitions of a document-oriented database, although their primary design goals differ. === Relationship to relational databases === In a relational database, data is organized into predefined types represented as tables. Each table contains rows (records) with a fixed set of columns (fields), so all records in a table share the same structure. Administrators typically define indexes on selected fields to improve query performance. A central principle of relational database design is database normalization, in which data that might otherwise be repeated is stored in separate tables and linked using keys. When records in different tables are related, a foreign key is used to associate them. For example, an address book application may store a contact's name, image, phone numbers, mailing addresses, and email addresses. In a normalized relational design, separate tables might be created for contacts, phone numbers, and email addresses. The phone number table would include a foreign key referencing the associated contact. To reconstruct a complete contact record, the database retrieves related information from each table using the foreign keys and combines it into a single record. In contrast, a document-oriented database stores all data related to an object within a single document, and stored in the database as a single entry. In the address book example,the contact's name, image, and contact information may be stored together in one document. The document is retrieved using a unique key, and all related information is returned together, without needing to look up multiple tables. A key difference between the document-oriented and relational models is that the data formats are not predefined in the document case. In most cases, any sort of document can be stored in a database, and documents can change in type and form over time. For example, a new field such as COUNTRY_FLAG can be added to new documents as they are inserted without affecting existing documents. To aid retrieval, document-oriented systems generally allow the administrator to provide hints to the database for locating certain types of information. These hints work in a similar fashion to indexes in relational databases. Many systems also allow additional metadata outside the content of the document itself

    Read more →
  • INaturalist

    INaturalist

    iNaturalist is an American 501(c)(3) nonprofit social network of naturalists, citizen scientists, and biologists built on the concept of mapping and sharing observations of biodiversity across the globe. iNaturalist may be accessed via its website or from its mobile applications. iNaturalist includes an automated species identification tool, and users further assist each other in identifying organisms from photographs and sound recordings. As of 5 August 2025, iNaturalist users had contributed nearly 300 million observations of plants, animals, fungi, and other organisms worldwide, and 400,000 users were active in the previous 30 days. iNaturalist serves as an important resource of open data for biodiversity research, conservation, and education, describing itself as "an online social network of people sharing biodiversity information to help each other learn about nature." It is the primary application for crowd-sourced biodiversity data in places such as Mexico, southern Africa, and Australia, and the project has been called "a standard-bearer for natural history mobile applications." Most of iNaturalist's software is open source. It has contributed to over 4,000 research papers and is widely used by scientists, land managers, and conservationists worldwide. The platform has also been active in the discovery of new species and rediscovery of species previously assumed to be extinct. == History == iNaturalist began in 2008 as a UC Berkeley School of Information Master's final project of Nate Agrin, Jessica Kline, and Ken-ichi Ueda. Agrin and Ueda continued work on the site with Sean McGregor, a web developer. In 2011, Ueda began collaboration with Scott Loarie, a research fellow at Stanford University and lecturer at UC Berkeley. Ueda and Loarie are the current co-directors of iNaturalist.org. The organization merged with the California Academy of Sciences on 24 April 2014. In 2017, iNaturalist became a joint initiative between the California Academy of Sciences and the National Geographic Society. With these collaborations and growing popularity of the site since 2012, the number of participants and observations has roughly doubled each year. In 2014, iNaturalist reached 1 million observations. Later, as of October 2023, there were 181 million observations (163 million verifiable). On 11 July 2023 iNaturalist announced its status as a newly independent 501(c)(3) nonprofit organization. === Google AI controversy === On 9 June 2025 Google announced that iNaturalist would be part of its "Generative AI Accelerator". This announcement, paired with the initial lack of information on the iNaturalist site, led to outcry from many iNaturalist users in the blog comments and forum, worrying about the consequences for the environment, volunteer engagement, reliability and raised questions about the decision making within iNaturalist, while some saw the backlash as a sign that people want to resist 'corrosive technologies'. PZ Myers, a biology professor who uses iNaturalist in his teaching, published an article on his website Pharyngula stating that "any decision that drives people away and replaces them with a hallucinating bot is a bad decision". == Platforms == Users can interact with iNaturalist in the following ways: through the iNaturalist.org website, through two mobile apps: iNaturalist (iOS/Android) and Seek by iNaturalist (iOS/Android), or through partner organizations such as the Global Biodiversity Information Facility (GBIF) website. On the iNaturalist.org website, visitors can search the public dataset and interact with other people adding observations and identifications. The website provides tools for registered users to add, identify, and discuss observations, write journal posts, explore information about species, create project pages to recruit participation, and coordinate work on their topics of interest. On the iNaturalist mobile app, users can create and share nature observations to the online dataset, explore observations both nearby and around the world, and learn about different species. Seek by iNaturalist, a separate app marketed to families, requires no online account registration and all observations may remain private. Seek incorporates features of gamification, such as providing a list of nearby organisms to find and encouraging the collection of badges and participation in challenges. Seek was initially released in the spring of 2018. == Observations == The iNaturalist platform is based on crowdsourcing of observations and identifications. An iNaturalist observation records a person's encounter with an individual organism at a particular time and place. An iNaturalist observation may also record evidence of an organism, such as animal tracks, nests, or scat. The scope of iNaturalist excludes natural but inert subjects such as geologic or hydrologic features. Users typically upload photos as evidence of their findings, though audio recordings are also accepted, and such evidence is not a strict requirement. Users may share observation locations publicly, "obscure" them to display a less precise location or make the locations completely private. iNaturalist users can add identifications to each other's observations in order to confirm or improve the identification of the observation. Observations are classified as "Casual", "Needs ID" (needs identification), or "Research Grade" based on the quality of the data provided and the community identification process. Any quality of data can be downloaded from iNaturalist and "Research Grade" observations are often incorporated into other online databases such as the Global Biodiversity Information Facility and the Atlas of Living Australia. === Automated species identification === In addition to observations being identified by others in the community, iNaturalist includes an automated species identification tool, first released in 2017. Images can be identified via a computer vision model which has been trained on the large database of the observations on iNaturalist. Multiple species suggestions are typically provided with the suggestion that the software guesses to be most likely is at the top of the list. A broader taxon such as a genus or family is commonly provided if the model is unsure of the species. It is trained once or twice a year, and the threshold for species included in the training set has changed over time. It can be difficult for the model to guess correctly if the species in question is infrequently observed or hard to identify from images alone, or if the image submitted has poor lighting, is blurry, or contains multiple subjects. In February 2023, iNaturalist released v2.1 of its computer vision model, which was trained on a new source model which performed significantly better than the previous models trained using a different source model. In April 2025 iNaturalist released an updated app for iOS, changing the original version to "iNaturalist Classic." == Projects == Users have created and contributed to tens of thousands of different projects on iNaturalist. The platform is commonly used to record observations during bioblitzes, which are biological surveying events that attempt to record all the species that occur within a designated area, and a specific project type on iNaturalist. Other project types include collections of observations by location or taxon or documenting specific types of observations such as animal tracks and signs, the spread of invasive species, roadkill, fishing catches, or discovering new species. In 2011, iNaturalist was used as a platform to power the Global Amphibian and Global Reptile BioBlitzes, in which observations were used to help monitor the occurrence and distribution of the world's reptiles and amphibian species. The US National Park Service partnered with iNaturalist to record observations from the 2016 National Parks BioBlitz. That project exceeded 100,000 observations in August 2016. In 2017, the United Nations Environment Programme teamed up with iNaturalist to celebrate World Environment Day.. In 2022, Reef Ecologic teamed up with iNaturalist to celebrate World Oceans Day. === City Nature Challenge === In 2016, Lila Higgins from the Natural History Museum of Los Angeles County and Alison Young from the California Academy of Sciences co-founded the City Nature Challenge (CNC). In the first City Nature Challenge, naturalists in Los Angeles and the San Francisco Bay Area documented over 20,000 observations with the iNaturalist platform. In 2017, the CNC expanded to 16 cities across the United States and collected over 125,000 observations of wildlife in 5 days. The CNC expanded to a global audience in 2018, with 68 cities participating from 19 countries, with some cities using community science platforms other than iNaturalist to participate. In 4 days, over 17,000 people cataloged over 440,000 nature observations in urban regions around the world. In 2019, the CNC once again expanded, with 35,000 parti

    Read more →
  • Mixed raster content

    Mixed raster content

    Mixed raster content (MRC) is a method for compressing images that contain both binary-compressible text and continuous-tone components, using image segmentation methods to improve the level of compression and the quality of the rendered image. By separating the image into components with different compressibility characteristics, the most efficient and accurate compression algorithm for each component can be applied. MRC-compressed images are typically packaged into a hybrid file format such as DjVu and sometimes PDF. This allows for multiple images, and the instructions to properly render and reassemble them, to be stored within a single file. Some image scanners optionally support MRC when scanning to PDF. A typical manual states that without MRC, the image is generated in a single process, with text and graphics not distinguished. With MRC, separate processes are used for text, graphics, and other elements, producing clearer graphics and sharper text, at the price of slightly slower processing. MRC is recommended to optimise the scanning of documents with harder-to-read text or lower-quality graphics. MRC can also reduce the size of the scanned file, though higher compression using JBIG2 can sometimes lead to character substitution errors in scanned documents. == File format == A form of MRC is defined by international standard bodies as ISO/IEC 16485, or ITU recommendation T.44 (accessible free of charge). It defines a file format with bilevel masks and two data layers in each "stripe" of the image. The mask can be encoded in ITU T.4, JBIG1, or JBIG2, while the images can be JPEG, JBIG1, or run-length encoded color. The format is loosely based on JPEG, with a APP13 segment registered for this purpose. It is not known whether this file format is actually used, as formats like DjVu and PDF have their own ways of defining layers and masks.

    Read more →
  • Secure coding

    Secure coding

    Secure coding is the practice of developing computer software in such a way that guards against the accidental introduction of security vulnerabilities. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities. Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment. Some scholars have suggested that in order to effectively confront threats related to cybersecurity, proper security should be coded or "baked in" to the systems. With security being designed into the software, this ensures that there will be protection against insider attacks and reduces the threat to application security. Implementing secure coding practices is part of the secure by design approach to security engineering. == Buffer-overflow prevention == Buffer overflows, a common software security vulnerability, happen when a process tries to store data beyond a fixed-length buffer. For example, if there are 8 slots to store items in, there will be a problem if there is an attempt to store 9 items. In computer memory the overflowed data may overwrite data in the next location which can result in a security vulnerability (stack smashing) or program termination (segmentation fault). An example of a C program prone to a buffer overflow is If the user input is larger than the destination buffer, a buffer overflow will occur. To fix this unsafe program, use strncpy to prevent a possible buffer overflow. Another secure alternative is to dynamically allocate memory on the heap using malloc. In the above code snippet, the program attempts to copy the contents of src into dst, while also checking the return value of malloc() to ensure that enough memory was able to be allocated for the destination buffer. == Format-string attack prevention == A Format String Attack is when a malicious user supplies specific inputs that will eventually be entered as an argument to a function that performs formatting, such as printf(). The attack involves the adversary reading from or writing to the stack. The C printf function writes output to stdout. If the parameter of the printf function is not properly formatted, several security bugs can be introduced. Below is a program that is vulnerable to a format string attack. A malicious argument passed to the program could be "%s%s%s%s%s%s%s", which can crash the program from improper memory reads. == Integer-overflow prevention == Integer overflow occurs when an arithmetic operation results in an integer too large to be represented within the available space. A program which does not properly check for integer overflow introduces potential software bugs and exploits. Below is a function in C++ which attempts to confirm that the sum of x and y is less than or equal to a defined value MAX: The problem with the code is it does not check for integer overflow on the addition operation. If the sum of x and y is greater than the maximum possible value of an unsigned int, the addition operation will overflow and perhaps result in a value less than or equal to MAX, even though the sum of x and y is greater than MAX. Below is a function which checks for overflow by confirming the sum is greater than or equal to both x and y. If the sum did overflow, the sum would be less than x or less than y. == Path traversal prevention == Path traversal is a vulnerability whereby paths provided from an untrusted source are interpreted in such a way that unauthorised file access is possible. For example, consider a script that fetches an article by taking a filename, which is then read by the script and parsed. Such a script might use the following hypothetical URL to retrieve an article about dog food: https://www.example.net/cgi-bin/article.sh?name=dogfood.html If the script has no input checking, instead trusting that the filename is always valid, a malicious user could forge a URL to retrieve configuration files from the web server: https://www.example.net/cgi-bin/article.sh?name=../../../../../etc/passwd Depending on the script, this may expose the /etc/passwd file, which on Unix-like systems contains (among others) user IDs, their login names, home directory paths and shells. (See SQL injection for a similar attack.) == Regulatory drivers == Secure coding practices are increasingly mandated by regulatory frameworks governing the development and maintenance of software systems that process sensitive data. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule requires covered entities to protect the integrity of protected health information through technical safeguards under 45 CFR 164.312(c)(1) and to implement mechanisms to authenticate electronic protected health information under 45 CFR 164.312(c)(2). The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 Requirement 6.2 mandates that custom software is developed securely, including training developers in secure coding techniques (6.2.2), reviewing custom code for vulnerabilities before release (6.2.3), and addressing common software attacks in development practices (6.2.4).

    Read more →
  • Path tracing

    Path tracing

    Path tracing is a rendering algorithm in computer graphics that simulates how light interacts with objects and participating media to generate realistic (physically plausible) images. It is based on earlier, more limited, ray tracing algorithms. Path tracing is used to create photorealistic images for artistic purposes, and for applications such as architectural rendering and product design. It is also used to render frames for animated films, and visual effects for film and television. Because it can be very accurate and unbiased, it is commonly used to generate reference images when testing the quality of other rendering algorithms. The technique uses the Monte Carlo method to compute estimates of global illumination and simulate the ways different materials reflect (or scatter), transmit, absorb, and emit light. It can incorporate simple modeling of the effects of aperture and lens (depth of field, and bokeh) and shutter speed (motion blur), or more realistic simulation of the optical components in a camera. The algorithm works by describing illumination in a scene using the rendering equation, or light transport equation, and finding an approximate solution using Monte Carlo integration. An inefficient (but accurate) version of the algorithm can be very simple, and involves tracing a ray from the camera, allowing this ray to bounce in random directions as it hits different objects in the scene, and computing the amount of light transmitted along the path to the camera whenever the path encounters a light source. This process is repeated many times for each pixel (each repetition, with generated path and transmitted light, is called a sample), and the results are averaged. One main difference between this algorithm and standard ray tracing is that a single unbranching path is traced each time, while "Whitted-style" or "Cook-style" ray tracing recursively samples branching paths (e.g. when light is both reflected and refracted by a glass object). More practical versions incorporate improvements such as quasi-Monte Carlo methods (techniques that distribute samples more evenly), importance sampling (take more samples of paths that are likely to transport more light), and next event estimation (allow a very limited form of branching, and sample additional paths that connect to the lights more directly). Because path tracing uses random samples there is noise in the final image, which decreases as more samples are taken. Images commonly require many thousands of samples per pixel (spp) to reduce noise to an acceptable level, and denoising techniques (e.g. based on neural networks) are often used. Denoising is usually necessary when path tracing is used for real-time rendering in video games, because relatively few samples can be taken. Many alternative algorithms for path tracing have been developed, although they do not always outperform more straightforward implementations. These include bidirectional path tracing (which traces paths forwards from the light source as well as backwards from the camera), Metropolis light transport, and ways of combining path tracing with photon mapping. Video games often use biased versions of path tracing to improve performance (e.g. limiting the number of bounces in each path). A family of techniques called ReSTIR has been developed that can help real-time path tracing by sharing data between nearby pixels and consecutive frames. == History == Like all ray tracing methods, path tracing is based on ray casting, which Arthur Appel used for computer graphics rendering in the late 1960s. In 1980, John Turner Whitted published a recursive ray tracing algorithm that allows rendering images of scenes containing mirrored surfaces and refractive transparent objects. In 1984, Cook et al. described a form of ray tracing called distributed ray tracing, which uses Monte Carlo integration to render effects such as depth of field, motion blur, reflection from rough surfaces, and area lights. The same year, the radiosity method (not a ray tracing method) was published, which was the first physically based method for rendering diffuse global illumination. In 1986, Jim Kajiya published a paper exploring how to use distributed ray tracing to render physically-based global illumination, and this paper also introduced and named the method called "path tracing". Path tracing and other distributed ray tracing techniques were further refined in the late 1980s and early 1990s by researchers such as James Arvo and Peter Shirley, and by Greg Ward in the open source Radiance software. Despite being theoretically able to render any lighting, the original form of path tracing can sometimes be very inefficient (or noisy) for rendering light that is reflected or refracted before illuminating a visible surface, including diffuse global illumination where light enters an area through narrow gaps, because it traces paths only from the camera. To address this, variations of path tracing that trace paths from both the camera and from light sources, called bidirectional path tracing, were published in 1993 by Eric Lafortune and Yves Willems, and in 1997 by Eric Veach and Leonidas Guibas. In 1997 Veach and Guibas also published an alternative method called Metropolis light transport, which combines bidirectional path tracing with the Metropolis method. Veach's lengthy Ph.D. dissertation described both techniques, along with the theoretical background of path tracing; later, the book Physically Based Rendering (which won an Academy Award for Technical Achievement in 2014) helped to make information about path tracing more widely available. Path tracing requires tracing a large number of paths of light in order to produce an image with a visually acceptable amount of noise. This made path tracing very slow on computers available in the 1980s and 1990s, and noise remained a problem when trying to reproduce the style of earlier computer graphics animated films. Most animated films produced until around 2010, by studios such as Pixar, used rasterization-based rendering, with ray tracing used selectively for reflections (and later for precomputed or cached global illumination). However the speed of computers rapidly increased during the 1990s. Blue Sky Studios pioneered using Monte Carlo ray tracing for global illumination in animation, including in the 1998 short film "Bunny", but they did not disclose the precise techniques used. Path tracing gradually become more practical for film production in the early 2000s. The Arnold renderer, developed by Marcos Fajardo, was used by Sony Pictures Imageworks to produce the feature-length film Monster House, released in 2006. Pixar rewrote their RenderMan software to use path tracing, and released their first feature-length path-traced film Finding Dory in 2016. Although path tracing still had a large computational cost, animation studios discovered that less human labor was required when using it, for example because global illumination no longer needed to be faked by manually placing lights. The amount of noise present in path traced images still caused difficulties, particularly when rendering motion blur (which was used extensively by earlier animated films) but denoising techniques were developed to address this. New techniques were also needed for rendering hair and fur, and to handle the extremely large scenes sometimes required by films. Renderers such as Arnold, and Disney's Hyperion, originally only used CPUs for rendering, but as GPUs became more capable (and APIs such as CUDA, OpenCL, and OptiX were released) researchers and developers began adapting algorithms and implementations to use GPUs. GPUs can dramatically reduce rendering time: for example using a high-end GPU to accelerate portions of the rendering code can make it over 30 times faster than using only a high-end CPU. == Description == Kajiya's 1986 paper defined a recursive integral equation called the rendering equation, which describes a simplified form of light transport. Using Monte Carlo integration for the integral on the right side of the equation leads fairly directly to the path tracing algorithm: I ( x , x ′ ) = g ( x , x ′ ) [ ϵ ( x , x ′ ) + ∫ S ρ ( x , x ′ , x ″ ) I ( x ′ , x ″ ) d x ″ ] {\displaystyle I(x,x')=g(x,x')\left[\epsilon (x,x')+\int _{S}\rho (x,x',x'')I(x',x'')dx''\right]} This expresses I(x,x'), the light arriving at point x from point x', as the product of a geometry term, g(x,x'), which is 0 if there is something blocking the light between the two points and 1 otherwise, and the amount of light leaving point x' and traveling towards x. The light leaving point x' is the sum of the light emitted by the surface at x', and the integral of the light arriving at x' from all other points in the scene (the integration domain S) and being reflected towards x. The factor ρ(x,x',x''), which calculates how much light is reflected, must take into account the angles at which the light is arriving and leaving, and

    Read more →
  • Object model

    Object model

    In computing, object model has two related but distinct meanings: The properties of objects in general in a specific computer programming language, technology, notation or methodology that uses them. Examples are the object models of Java, the Component Object Model (COM), or Object-Modeling Technique (OMT). Such object models are usually defined using concepts such as class, generic function, message, inheritance, polymorphism, and encapsulation. There is an extensive literature on formalized object models as a subset of the formal semantics of programming languages. A collection of objects or classes through which a program can examine and manipulate some specific parts of its world. In other words, the object-oriented interface to some service or system. Such an interface is said to be the object model of the represented service or system. For example, the Document Object Model (DOM) is a collection of objects that represent a page in a web browser, used by script programs to examine and dynamically change the page. There is a Microsoft Excel object model [1] for controlling Microsoft Excel from another program, and the ASCOM Telescope Driver is an object model for controlling an astronomical telescope. == Features == An object model consists of the following important features: === Object reference === Objects can be accessed via object references. To invoke a method in an object, the object reference and method name are given, together with any arguments. === Interfaces === An interface provides a definition of the signature of a set of methods without specifying their implementation. An object will provide a particular interface if its class contains code that implement the method of that interface. An interface also defines types that can be used to declare the type of variables or parameters and return values of methods. === Actions === An action in object-oriented programming (OOP) is initiated by an object invoking a method in another object. An invocation can include additional information needed to carry out the method. The receiver executes the appropriate method and then returns control to the invoking object, sometimes supplying a result. === Exceptions === Programs can encounter various errors and unexpected conditions of varying seriousness. During the execution of the method many different problems may be discovered. Exceptions provide a clean way to deal with error conditions without complicating the code. A block of code may be defined to throw an exception whenever particular unexpected conditions or errors arise. This means that control passes to another block of code that catches the exception.

    Read more →
  • Text Database and Dictionary of Classic Mayan

    Text Database and Dictionary of Classic Mayan

    The project Text Database and Dictionary of Classic Mayan (abbr. TWKM) promotes research on the writing and language of pre-Hispanic Maya culture. It is housed in the Faculty of Arts at the University of Bonn and was established with funding from the North Rhine-Westphalian Academy of Sciences, Humanities and the Arts. The project has a projected run-time of fifteen years and is directed by Nikolai Grube from the Department of Anthropology of the Americas at the University of Bonn. The goal of the project is to conduct computer-based studies of all extant Maya hieroglyphic texts from an epigraphic and cultural-historical standpoint, and to produce and publish a database and a comprehensive dictionary of the Classic Mayan language. == Subject of the Project == The text database, as well as the dictionary that will be compiled by the conclusion of the project, will be assembled based on all known texts from the pre-Hispanic Maya culture. These texts were produced and used between approximately the third century B.C. through A.D. 1500, in a region that today includes parts of the countries of Mexico, Guatemala, Belize, and Honduras. The thousands of hieroglyphic inscriptions on monuments, ceramics, or daily objects that have survived into the present offer insight into the language's vocabulary and structure. The project's database and dictionary will digitally represent original spellings using the logo-syllabic Maya hieroglyphs, as well as their transcription and transliteration in the Roman alphabet. The data will be additionally annotated with various epigraphic analyses, translations, and further object-specific information. == Project Partners == TWKM will employ digital technologies in order to compile and make available the data and metadata, as well as to publish the project's research results. The project thereby methodologically positions itself in the field of the digital humanities. The project will be conducted in cooperation with the project partners (below), the research association for the eHumanities TextGrid, as well as the University and Regional Library of Bonn (ULB). The working environment that is currently under construction, in which the data and metadata will be compiled and annotated, will be realized in theTextGrid Laboratory, a software of the virtual research environment. A further component of this software, the TextGrid Repository, will make the data that are authorized for publication freely available online and ensure their long-term storage. The tools for data compilation and annotation attained from the modularly constructed and extended TextGrid lab thereby provide all the necessary materials for facilitating the research team's the typical epigraphic workflow. The workflow usually begins by documenting the texts and the objects on which they are preserved, and by compiling descriptive data. It then continues with the various levels of epigraphic and linguistic analysis, and concludes in the best case scenario with a translation of the analyzed inscription and a corresponding publication. In cooperation with the ULB, selected data will additionally be made available. The project's Virtual Inscription Archive will present online, in the Digital Collections of the ULB, hieroglyphic inscriptions selected from the published data in the repository, including an image of and brief information about the texts and the objects on which they are written, epigraphic analysis, and translation. == Project Goal == One of the project's goals is to produce a dictionary of Classic Mayan, in both digital and print form, towards the end of the project run-time. Additionally, a database with a corpus of inscriptions, including their translations and epigraphic analyses, will be made freely available online. The database furthermore will provide an ontology-like link of the contextual object data with the inscriptions and with each other, thereby allowing a cultural-historical arrangement of all contents within the periods of pre-Hispanic Maya culture. The contents of the database are additionally linked to citations of relevant literature. As a result, the database will also make freely available to both the scientific community and other interested parties a bibliography representing the research history and a base of knowledge concerning ancient Maya culture and script. In addition, the Classic Maya script, in its temporally defined stages of language development, will be gathered into and documented in a comprehensive language corpus with the aid of the information gathered by the project. In collaboration with all project participants, the corpus data can be used, together with the aid of various comparable analyses and also computational linguistic methods, such as inference-based methods, to confirm readings of some hieroglyphs that are currently only partially confirmed, and to eventually completely decipher the Classic Maya script.

    Read more →
  • Trustworthy computing

    Trustworthy computing

    The term trustworthy computing (TwC) has been applied to computing systems that are inherently secure, available, and reliable. It is particularly associated with the Microsoft initiative of the same name, launched in 2002. == History == Until 1995, there were restrictions on commercial traffic over the Internet. On, May 26, 1995, Bill Gates sent the "Internet Tidal Wave" memorandum to Microsoft executives assigning "...the Internet this highest level of importance..." but Microsoft's Windows 95 was released without a web browser as Microsoft had not yet developed one. The success of the web had caught them by surprise but by mid 1995, they were testing their own web server, and on August 24, 1995, launched a major online service, The Microsoft Network (MSN). The National Research Council recognized that the rise of the Internet simultaneously increased societal reliance on computer systems while increasing the vulnerability of such systems to failure and produced an important report in 1999, "Trust in Cyberspace". This report reviews the cost of un-trustworthy systems and identifies actions required for improvement. == Microsoft and Trustworthy Computing == Bill Gates launched Microsoft's "Trustworthy Computing" initiative with a January 15, 2002 memo, referencing an internal whitepaper by Microsoft CTO and Senior Vice President Craig Mundie. The move was reportedly prompted by the fact that they "...had been under fire from some of its larger customers–government agencies, financial companies and others–about the security problems in Windows, issues that were being brought front and center by a series of self-replicating worms and embarrassing attacks." such as Code Red, Nimda, Klez and Slammer. Four areas were identified as the initiative's key areas: Security, Privacy, Reliability, and Business Integrity, and despite some initial scepticism, at its 10-year anniversary it was generally accepted as having "...made a positive impact on the industry...". The Trustworthy Computing campaign was the main reason why Easter eggs disappeared from Windows, Office and other Microsoft products.

    Read more →