A cryptographic service provider (CSP) is a package that "provides a concrete implementation of certain cryptographic services." A CSP offers operations and protocols to support a variety of use cases. The cryptographic application programming interface (API) provided by the CSP provides common solutions for different platforms, for example hardware and cloud services. == Microsoft Windows == In Microsoft Windows, a Cryptographic Service Provider is a software library that implements the Microsoft CryptoAPI (CAPI). CSPs implement encoding and decoding functions, which computer application programs may use, for example, to implement strong user authentication or for secure email. CSPs are independent modules that can be used by different applications. A user program calls CryptoAPI functions and these are redirected to CSPs functions. Since CSPs are responsible for implementing cryptographic algorithms and standards, applications do not need to be concerned about security details. Furthermore, each application can define which CSP it is going to use on its calls to CryptoAPI. In fact, all cryptographic activity is implemented in CSPs. CryptoAPI only works as a bridge between the application and the CSP. CSPs are implemented basically as a special type of DLL with special restrictions on loading and use. Every CSP must be digitally signed by Microsoft and the signature is verified when Windows loads the CSP. In addition, after being loaded, Windows periodically re-scans the CSP to detect tampering, either by malicious software such as computer viruses or by the user him/herself trying to circumvent restrictions (for example on cryptographic key length) that might be built into the CSP's code. To obtain a signature, non-Microsoft CSP developers must supply paperwork to Microsoft promising to obey various legal restrictions and giving valid contact information. As of circa 2000, Microsoft did not charge any fees to supply these signatures. For development and testing purposes, a CSP developer can configure Windows to recognize the developer's own signatures instead of Microsoft's, but this is a somewhat complex and obscure operation unsuitable for nontechnical end users. The CAPI/CSP architecture had its origins in the era of restrictive US government controls on the export of cryptography. Microsoft's default or "base" CSP then included with Windows was limited to 512-bit RSA public-key cryptography and 40-bit symmetric cryptography, the maximum key lengths permitted in exportable mass market software at the time. CSPs implementing stronger cryptography were available only to U.S. residents, unless the CSPs themselves had received U.S. government export approval. The system of requiring CSPs to be signed only on presentation of completed paperwork was intended to prevent the easy spread of unauthorized CSPs implemented by anonymous or foreign developers. As such, it was presented as a concession made by Microsoft to the government, in order to get export approval for the CAPI itself. After the Bernstein v. United States court decision establishing computer source code as protected free speech and the transfer of cryptographic regulatory authority from the U.S. State Department to the more pro-export Commerce Department, the restrictions on key lengths were dropped, and the CSPs shipped with Windows now include full-strength cryptography. The main use of third-party CSPs is to interface with external cryptography hardware such as hardware security modules (HSM) or smart cards. === Smart Card CSP === These cryptographic functions can be realized by a smart card, thus the Smart Card CSP is the Microsoft way of a PKCS#11. Microsoft Windows is identifying the correct Smart Card CSP, which have to be used, analyzing the answer to reset (ATR) of the smart card, which is registered in the Windows Registry. Installing a new CSP, all ATRs of the supported smart cards are enlisted in the registry. === Use of CSP in MS Office password protection === Cryptographic service providers can be used for encryption of Word, Excel, and PowerPoint documents starting from Microsoft Office XP. A standard encryption algorithm with a 40-bit key is used by default, but enabling a CSP enhances key length and thus makes decryption process more continuous. This only applies to passwords that are required to open document because this password type is the only one that encrypts a password-protected document.
Computer Graphics International
Computer Graphics International (CGI) is one of the oldest annual international conferences on computer graphics. It is organized by the Computer Graphics Society (CGS). Researchers across the whole world are invited to share their experiences and novel achievements in various fields - like computer graphics and human-computer interaction. Former conferences have been held recently in Hong Kong (China), Geneva (Switzerland), Shanghai (China), Geneva (virtually), Calgary (Canada), Bintan (Indonesia) and Yokohama (Japan). == Awards == Starting in the year of 2013, CGI has given yearly a Best Paper Award and a Career Achievement Award. == Venues ==
IQTELL
IQTELL was a productivity app that allowed users to manage email, tasks, projects, calendars, contacts, Evernotes and more in a single app. IQTELL was available as a web app, as well as an iOS and Android app. All user information was automatically synced between all devices. iOS and Android apps supported offline access. The app could be used to implement concepts and techniques described in the book Getting Things Done by David Allen. == History == IQTELL was created by Ran Flam and released in 2013. In 2014, mobile apps for iOS and Android were released. In 2015, Premium and Platinum subscription plans were introduced (while maintaining the free user version). In April 2017, a new web app was launched. On July 31, 2017, all IQTell services have been closed. == Productivity methods == IQTell was designed to fit in with the Getting Things Done (GTD) productivity methods. Users may have had utilized GTD lists, such as Inbox, Actions, Projects, Someday, Ticklers, and Reference information to process their Inbox items into relevant GTD lists. Using the web app, iOS and/or Android apps, users could deploy macros/shortcuts to quickly process their email. Email was turned into tasks (actions), projects, etc. The original email was removed from the email inbox. The email became a part of the items created (e.g. actions, project, etc.) and could also be viewed in the All Mail folder (if Gmail), or the Archive folder (if non-Gmail). Users had flexibility to use the out-of-the-box macros/shortcuts as well as edit/create additional macros. IQTELL features included email, calendars, contacts, list management, sharing and collaboration with team members. All of the features were compatible with commonly used organization software such as Evernote and iCloud.
SQLBuddy
SQL Buddy is an open-source web-based application primarily coded in PHP, that allows users to control both MySQL and SQLite database through a web browser. The project was well regarded for its easy installation process and the friendly user interface it offered. The application was further praised for its cross-platform compatibility, meaning users could manage their databases on various operating systems, including Linux, Windows, and macOS. The development of SQL Buddy has stopped, with version 1.3.3 being the final release on January 18, 2011. No further releases are expected.
Observability (software)
In software engineering, more specifically in distributed computing, observability is the ability to collect data about programs' execution, modules' internal states, and the communication among components. To improve observability, software engineers use a wide range of logging and tracing techniques to gather telemetry information, and tools to analyze and use it. Observability is foundational to site reliability engineering, as it is the first step in triaging a service outage. One of the goals of observability is to minimize the amount of prior knowledge needed to debug an issue. == Etymology, terminology and definition == The term is borrowed from control theory, where the "observability" of a system measures how well its state can be determined from its outputs. Similarly, software observability measures how well a system's state can be understood from the obtained telemetry (metrics, logs, traces, profiling). The definition of observability varies by vendor: Observability is the process of making a system’s internal state more transparent. Systems are made observable by the data they produce, which in turn helps you to determine if your infrastructure or application is healthy and functioning normally. a measure of how well you can understand and explain any state your system can get into, no matter how novel or bizarre [...] without needing to ship new code software tools and practices for aggregating, correlating and analyzing a steady stream of performance data from a distributed application along with the hardware and network it runs onobservability starts by shipping all your raw data to central service before you begin analysisthe ability to measure a system’s current state based on the data it generates, such as logs, metrics, and traces Observability is tooling or a technical solution that allows teams to actively debug their system. Observability is based on exploring properties and patterns not defined in advance. proactively collecting, visualizing, and applying intelligence to all of your metrics, events, logs, and traces—so you can understand the behavior of your complex digital system The term is frequently referred to as its numeronym o11y (where 11 stands for the number of letters between the first letter and the last letter of the word). This is similar to other computer science abbreviations such as i18n and l10n and k8s. === Observability vs. monitoring === Observability and monitoring are sometimes used interchangeably. As tooling, commercial offerings and practices evolved in complexity, "monitoring" was re-branded as observability in order to differentiate new tools from the old. The terms are commonly contrasted in that systems are monitored using predefined sets of telemetry, and monitored systems may be observable. Majors et al. suggest that engineering teams that only have monitoring tools end up relying on expert foreknowledge (seniority), whereas teams that have observability tools rely on exploratory analysis (curiosity). == Telemetry types == Observability relies on three main types of telemetry data: metrics, logs and traces. Those are often referred to as "pillars of observability". === Metrics === A metric is a point in time measurement (scalar) that represents some system state. Examples of common metrics include: number of HTTP requests per second; total number of query failures; database size in bytes; time in seconds since last garbage collection. Monitoring tools are typically configured to emit alerts when certain metric values exceed set thresholds. Thresholds are set based on knowledge about normal operating conditions and experience. Metrics are typically tagged to facilitate grouping and searchability. Application developers choose what kind of metrics to instrument their software with, before it is released. As a result, when a previously unknown issue is encountered, it is impossible to add new metrics without shipping new code. Furthermore, their cardinality can quickly make the storage size of telemetry data prohibitively expensive. Since metrics are cardinality-limited, they are often used to represent aggregate values (for example: average page load time, or 5-second average of the request rate). Without external context, it is impossible to correlate between events (such as user requests) and distinct metric values. === Logs === Logs, or log lines, are generally free-form, unstructured text blobs that are intended to be human readable. Modern logging is structured to enable machine parsability. As with metrics, an application developer must instrument the application upfront and ship new code if different logging information is required. Logs typically include a timestamp and severity level. An event (such as a user request) may be fragmented across multiple log lines and interweave with logs from concurrent events. === Traces === ==== Distributed traces ==== A cloud native application is typically made up of distributed services which together fulfill a single request. A distributed trace is an interrelated series of discrete events (also called spans) that track the progression of a single user request. A trace shows the causal and temporal relationships between the services that interoperate to fulfill a request. Instrumenting an application with traces means sending span information to a tracing backend. The tracing backend correlates the received spans to generate presentable traces. To be able to follow a request as it traverses multiple services, spans are labeled with unique identifiers that enable constructing a parent-child relationship between spans. Span information is typically shared in the HTTP headers of outbound requests. === Continuous profiling === Continuous profiling is another telemetry type used to precisely determine how an application consumes resources. === Instrumentation === To be able to observe an application, telemetry about the application's behavior needs to be collected or exported. Instrumentation means generating telemetry alongside the normal operation of the application. Telemetry is then collected by an independent backend for later analysis. In fast-changing systems, instrumentation itself is often the best possible documentation, since it combines intention (what are the dimensions that an engineer named and decided to collect?) with the real-time, up-to-date information of live status in production. Instrumentation can be automatic, or custom. Automatic instrumentation offers blanket coverage and immediate value; custom instrumentation brings higher value but requires more intimate involvement with the instrumented application. Instrumentation can be native - done in-code (modifying the code of the instrumented application) - or out-of-code (e.g. sidecar, eBPF). Verifying new features in production by shipping them together with custom instrumentation is a practice called "observability-driven development". == "Pillars of observability" == Metrics, logs and traces are most commonly listed as the pillars of observability. Majors et al. suggest that the pillars of observability are high cardinality, high-dimensionality, and explorability, arguing that runbooks and dashboards have little value because "modern systems rarely fail in precisely the same way twice." == Self monitoring == Self monitoring is a practice where observability stacks monitor each other, in order to reduce the risk of inconspicuous outages. Self monitoring may be put in place in addition to high availability and redundancy to further avoid correlated failures.
Wadhwani Institute for Artificial Intelligence
Wadhwani AI, based in Mumbai, Maharashtra, is an independent, non-profit institute. Founded in 2018, it is dedicated to developing Artificial intelligence solutions for social good. Their mission is to build AI-based innovations and solutions for underserved communities in developing countries, for a wide range of domains including agriculture, education, financial inclusion, healthcare, and infrastructure. == History and funding == The institute was founded with a $30 million philanthropic effort by the Wadhwani brothers, Romesh Wadhwani and Sunil Wadhwani. The institute was inaugurated and dedicated to the nation by Narendra Modi, the 14th Prime Minister of India. In 2019, the institute received a $2 million grant from Google.org to create technologies to help reduce crop losses in cotton farming, through integrated pest management. The United States Agency for International Development awarded $2 million to the institute in 2020 to develop tools, using mathematical modeling techniques and digital technologies such as artificial intelligence and machine learning, to forecast COVID-19 disease patterns, estimate resources needed, and plan interventions. == Collaboration == With assistance from Google, the Ministry of Agriculture and Farmers' Welfare and the Wadhwani AI developed Krishi 24/7, the first AI-powered automated agricultural news monitoring and analysis tool. Through better decision-making, Krishi 24/7 will support the identification of valuable news, provide timely notifications, and respond quickly to safeguard farmers' interests and advance sustainable agricultural growth. The application converts news articles into English after scanning them in several languages. It ensures that the ministry is informed in a timely manner about pertinent occurrences that are published online by extracting key information from news items, including the headline, crop name, event type, date, location, severity, summary, and source link. The National Center for Disease Control has effectively implemented a comparable automated surveillance and analysis tool for disease outbreaks.
Apache Hama
Apache Hama is a distributed computing framework based on bulk synchronous parallel computing techniques for massive scientific computations e.g., matrix, graph and network algorithms. Originally a sub-project of Hadoop, it became an Apache Software Foundation top level project in 2012. It was created by Edward J. Yoon, who named it (short for "Hadoop Matrix Algebra"), and Hama also means hippopotamus in Yoon's native Korean language (하마), following the trend of naming Apache projects after animals and zoology (such as Apache Pig). Hama was inspired by Google's Pregel large-scale graph computing framework described in 2010. When executing graph algorithms, Hama showed a fifty-fold performance increase relative to Hadoop. Retired in April 2020, project resources are made available as part of the Apache Attic. Yoon cited issues of installation, scalability, and a difficult programming model for its lack of adoption. == Architecture == Hama consists of three major components: BSPMaster, GroomServers and Zookeeper. === BSPMaster === BSPMaster is responsible for: Maintaining groom server status Controlling super steps in a cluster Maintaining job progress information Scheduling jobs and assigning tasks to groom servers Disseminating execution class across groom servers Controlling fault Providing users with the cluster control interface. A BSP Master and multiple grooms are started by the script. Then, the bsp master starts up with a RPC server for groom servers. Groom servers starts up with a BSPPeer instance and a RPC proxy to contact the bsp master. After started, each groom periodically sends a heartbeat message that encloses its groom server status, including maximum task capacity, unused memory, and so on. Each time the BSP master receives a heartbeat message, it brings the groom server status up-to-date. The bsp master makes use of groom servers' status in order to assign tasks to idle groom servers - and returns a heartbeat response containing assigned tasks and others actions for a groom server to do. Currently BSP master has a FIFO job scheduler and simple task assignment algorithms. === GroomServer === A groom server (shortly referred to as groom) is a process that performs BSP tasks assigned by BSPMaster. Each groom contacts the BSPMaster, and it takes assigned tasks and reports its status by means of periodical piggybacks with BSPMaster. Each groom is designed to run with HDFS or other distributed storages. Basically, a groom server and a data node should be run on one physical node. === Zookeeper === A Zookeeper is used to manage the efficient barrier synchronisation of the BSPPeers.