A data access layer (DAL) is a software architectural layer that provides access to data from one or more sources, such as a relational database, NoSQL database, SQL query engine, file system, or other persistent storage. It separates client code from the details of storage systems, query execution, connection handling, and data retrieval. Data access layers are commonly used to centralize data access logic, reduce coupling between applications and data sources, and provide a consistent interface for retrieving, writing, or querying data. Depending on the system, a data access layer may be implemented as application code, a shared library, an intermediary service, or part of a broader database abstraction layer. == In application architecture == In application software, a data access layer provides a boundary between business logic or application code and the systems used to store or retrieve data. For example, a data access layer may expose methods or interfaces for retrieving, writing, or querying data while hiding details such as connection management, SQL statements, storage APIs, error handling, and result conversion. Depending on the application, the layer may return objects, records, tabular results, documents, streams, or other representations of data. A common implementation is a set of classes, functions, or methods that directly reference database queries, stored procedures, storage APIs, or other data sources. For example, instead of using commands such as insert, delete, and update throughout an application to access a specific table, methods such as registerUser or loginUser may be implemented inside the data access layer. Business logic methods from an application can also be mapped to the data access layer. Instead of making several database queries directly, an application can call a single DAL method that abstracts those database calls. Applications using a data access layer may be either dependent on or independent from a particular database server. If the data access layer supports multiple database systems, the application can use any database system that the DAL can access. In either case, the data access layer provides a centralized location for calls into the underlying data store, which can make it easier to maintain, test, or port the application to other storage systems. == Implementation patterns == A data access layer can be implemented using several patterns and technologies, including data access objects, repositories, stored procedures, query builders, database drivers, or object–relational mapping tools. These mechanisms may implement part or all of a data access layer, but are not always equivalent to the layer itself. Object–relational mapping tools are commonly used in data access layers for object-oriented applications that map records in a relational database to objects in a programming language. Other data access layers may expose lower-level database interfaces, tabular results, document-oriented data, files, streams, or protocol-level interfaces. == Use with multiple underlying data systems == A data access layer may be used to abstract differences between multiple underlying data systems, allowing applications to access them through a more consistent interface. In such designs, applications call the DAL rather than interacting directly with each database or storage system. The layer may then handle connection management, query generation, result mapping, error handling, and other implementation details. A data access layer may be implemented as a shared library or as an intermediary service, such as a proxy or gateway. In this configuration, client applications or services connect to the data access layer, which then communicates with one or more underlying databases or query engines. This can provide a common location for authentication, authorization, logging, routing, and translation between different database interfaces. == Interfaces and protocols == Data access layers may expose or use standardized interfaces and protocols for database access. Examples include Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), database-native wire protocols, and newer interfaces such as Apache Arrow Database Connectivity (ADBC) and Arrow Flight SQL. In systems that support multiple data stores, a data access layer may provide a consistent interface while using different drivers, protocols, or query mechanisms internally. == Distinction from related patterns == A data access layer is related to, but broader than, a data access object, which is usually an object-oriented design pattern for encapsulating access to a persistence mechanism. It is also related to a database abstraction layer, which focuses on hiding differences between database systems. In practice, the terms may overlap.
Art Recognition
Art Recognition is a Swiss technology company headquartered in Adliswil, within the Zurich metropolitan area, Switzerland. Art Recognition specializes in the application of artificial intelligence (AI) for art authentication and the detection of art forgeries. == Overview == Art Recognition was established in 2019 by Dr. Carina Popovici and Christiane Hoppe-Oehl. Art Recognition employs a combination of machine learning techniques, computer vision algorithms, and deep neural networks to assess the authenticity of artworks. The company's technology undergoes a process of data collection, dataset preparation, and training. === Academic partnerships and grants === Art Recognition has established a relationship with Innosuisse, a Swiss innovation agency, to expand its research and development initiatives. It has also formed a strategic collaboration with Nils Büttner, an art historian and professor at the State Academy of Fine Arts Stuttgart (ABK Stuttgart). === Notable developments === In May 2024, Art Recognition played a key role in identifying counterfeit artworks, including alleged Monets and Renoirs, being sold on eBay. Germann Auction in November 2024 became the first auction house to successfully conduct a sale of artwork authenticated entirely by artificial intelligence. As of January 2025, Art Recognition has appointed art crime expert and Pulitzer Prize finalist Noah Charney as an advisor. === Recognition and debates === The company was featured on the front page of The Wall Street Journal for its involvement in the authentication case of the Flaget Madonna, believed to have been partly painted by Raphael. A broadcast by the Swiss public television SRF covered how the algorithm can be used to detect art forgeries with high accuracy. The technology developed by Art Recognition has been recognized for its role in providing a technology-based art authentication solution, compared to traditional methods. == Controversial cases == Art Recognition's AI algorithm has been applied to several high-profile and controversial artworks, sparking significant interest and debate in the art world. Samson and Delilah at the National Gallery in London: The National Gallery's "Samson and Delilah", traditionally attributed to the artist Rubens, has also been examined using Art Recognition's AI, which has assessed the painting as non-authentic. De Brecy Tondo Madonna. A research team from Bradford University and the University of Nottingham initially attributed the painting to Raphael, employing an AI face recognition software, while the AI developed at Art Recognition returned a negative result. The Bradford group's AI was trained on 49 images, whereas Art Recognition employed a larger dataset of over 100 images. Lucian Freud Painting Controversy: Featured in The New Yorker, a painting attributed to Lucian Freud became a subject of dispute. Art Recognition's AI analysis played a big role in examining the painting's authenticity. Titian at Kunsthaus Zürich: A painting attributed to Titian, housed at Kunsthaus Zürich, has been a topic of debate among art experts. The application of Art Recognition's technology offered a new perspective. Following this debate, Kunsthaus Zürich has announced plans to initiate a comprehensive project aimed at resolving the authenticity questions surrounding the painting. Art Recognition has contributed to the authentication debate surrounding The Polish Rider, a painting traditionally attributed to Rembrandt but subject to scholarly debate.
FreePBX Distro
The FreePBX Distro was a freeware unified communications software system that consisted of FreePBX, a graphical user interface (GUI) for configuring, controlling and managing Asterisk PBX software. The FreePBX Distro included packages that offer VoIP, PBX, Fax, IVR, voice-mail and email functions. The FreePBX Distro Linux distribution was based on CentOS, which maintains binary compatibility with Red Hat Enterprise Linux. FreePBX has contributed to the popularity of Asterisk. As a result of CentOS Linux being discontinued and the last version of CentOS 7 going out of support on June 30, 2024, FreePBX 17 has moved over to and is supported on Debian Linux. FreePBX will no longer be providing a pre-configured FreePBX Distro, but will provide a script to install FreePBX on a fresh install of Debian Linux. In-place migration will not be possible, but will be possible by restoring a backup on the new version from the previous version. As FreePBX 16 will be supported until the release of FreePBX 18, FreePBX on this distribution will still work and be supported, however, there will be no further support for the underlying operating system. == Installation == The Official FreePBX Distro is installed from a ISO image available by web download, that includes the system CentOS, Asterisk, FreePBX GUI and assorted dependencies. This can then either be burned to DVD or written to a USB stick for installation == Support for telephony hardware == The FreePBX Distro has built-in support for cards from multiple vendors, including Digium, OpenVox, Alto, Rhino Equipment, Xorcom and Sangoma. The FreePBX Distro supports a large number of phone models via open-source modules. Supported VoIP phone manufacturers include Algo, AND, AudioCodes, Cisco, Cyberdata, Digium, Grandstream, Mitel/Aastra, Nortel/Avaya, Panasonic, Polycom, Sangoma, Snom, Xorcom and Yealink. == Development == FreePBX made its debut in 2004 as the AMP project (Asterisk Management Portal). The FreePBX Distro was released in 2011 as an turnkey solution for building a PBX using Asterisk, CentOS and FreePBX. FreePBX has over 1 million active production PBXs and over 20,000 new systems added each month. The core telephony engine is Asterisk, as configured by the Open Source FreePBX GUI. The last stable release is FreePBX Distro Stable SNG7-PBX16-64bit-2302-1 based on these main components: FreePBX 16 CentOS 7.8 Asterisk 16, 18, 19 (20 supported by upgrade once installed)
IDN Times
IDN Times is a digital multi-platform media outlet that provides news and entertainment for Millennials and Gen Z in Indonesia. IDN Times is one of IDN’s business units under the Digital Media pillar, founded by Winston Utomo and William Utomo on June 8, 2014. Currently, senior journalist Uni Zulfiani Lubis serves as the Editor-in-Chief of IDN Times. == History == IDN Times was initially known as Indonesian Times, a blog featuring articles written by Winston Utomo while he was working at Google Singapore. As interest and readership grew, Indonesian Times evolved into IDN Times, a digital multi-platform media company focused on delivering relevant content for Indonesia’s younger generations. == Bureau == IDN Times has a representative bureau that has spread over 12 provinces in Indonesia: == Events == === Indonesia Millennial and Gen Z Summit === The Indonesia Millennial and Gen-Z Summit (IMGS) is an annual event organized by IDN. This event aims to empower Indonesia’s younger generations through discussions and interdisciplinary collaborations. IMGS features inspirational figures, professionals, and leaders from various fields who share insights and drive positive change. The event hosts dozens of discussion sessions in collaboration with eight prominent communities. Topics covered include politics, economics, technology, and pop culture. === Indonesia Writers Festival === The Indonesia Writers Festival is an independent writing festival organized by IDN Times. The event seeks to empower Indonesians through writing by inviting experts and literacy activists from various backgrounds. == Duniaku.com == Duniaku.com is a multi-platform digital media part of IDN Times which presents content about geek culture ranging from video games, anime, comics, films, technology and gadgets. Duniaku.com was officially launched on September 6, 2019 by the Minister of Communication and Informatics Rudiantara together with CEO of IDN Media Winston Utomo and IDN Times and Editor-in-Chief of Duniaku.com Uni Lubis. == Awards == 2019 IDN won WAN-IFRA Asia Digital Media Awards 2019 as the Best Digital Project to Engage Younger and/or Millennial Audiences for IDN Times’ #MillennialsMemilih program 2020 IDN Times (IDN Times Community) won WAN-IFRA Asia Digital Media Awards 2019 in The Best in Audience Engagement category. 2021 IDN Times journalists won awards at the Subroto Award, Ministry of Energy and Mineral Resources (ESDM) on 28 September 2021. 2024 IDN Times won WAN-IFRA event at both the Asia and Global levels in Best Use of AI in Revenue Strategy. === #Interconnected22 by Pulitzer Center === One of the IDN Times journalists, Dhana Kencana, was the speaker at the #Interconnected22 conference held from June 9 to June 10, 2022, in Washington DC, United States of America. Dhana Kencana is also a grant recipient Pulitzer Center through the Rainforest Journalism Fund (RJF) program, a funding program for journalists that makes a number of coverage of the rainforest.
T.38
T.38 is an ITU recommendation for allowing transmission of fax over IP networks (FoIP) in real time. == History == The T.38 fax relay standard was devised in 1998 as a way to transport faxes across IP networks between existing Group 3 (G3) fax terminals. T.4 and related fax standards were published by the ITU in 1980, before the rise of the Internet. In the late 1990s, VoIP, or voice over IP, began to gain ground as an alternative to the conventional public switched telephone network (PSTN). However, because most VoIP systems are optimized (through their use of aggressive lossy bandwidth-saving compression) for voice rather than data calls, conventional fax machines worked poorly or not at all on them due to the network impairments such as delay, jitter, packet loss, and so on. Thus, some way of transmitting fax over IP was needed. == Overview == In practical scenarios, a T.38 fax call has at least part of the call being carried over PSTN, although this is not required by the T.38 definition, and two T.38 devices can send faxes to each other. This particular type of device is called Internet-Aware Fax device, or IAF, and it is capable of initiating or completing a fax call towards the IP network. The typical scenario where T.38 is used is – T.38 fax relay – where a T.30 fax device sends a fax over PSTN to a T.38 fax gateway which converts or encapsulates the T.30 protocol into a T.38 data stream. This is then sent either to a T.38-enabled end point such as fax machine or fax server or another T.38 gateway that converts it back to a PSTN PCM or analog signal and terminates the fax on a T.30 device. The T.38 recommendation defines the use of both TCP and UDP to transport T.38 packets. Implementations tend to use UDP, due to TCP's requirement for acknowledgement packets and resulting retransmission during packet loss, which introduces delays. When using UDP, T.38 copes with packet loss by using redundant data packets. T.38 is not a call setup protocol, thus the T.38 devices need to use standard call setup protocols to negotiate the T.38 call, e.g. H.323, SIP & MGCP. == Operation == There are two primary ways that fax transactions are conveyed across packet networks. The T.37 standard specifies how a fax image is encapsulated in e-mail and transported, ultimately, to the recipient using a store-and-forward process through intermediary entities. T.38, however, defines a protocol that supports the use of the T.30 protocol in both the sender and recipient terminals. (See diagram above.) T.38 lets one transmit a fax across an IP network in real time, just as the original G3 fax standards did for the traditional (time-division multiplexed (TDM)) network, also called the public switched telephone network or PSTN. A special protocol is needed for real-time fax over IP (Internet Protocol) since existing fax terminals only supported PSTN connections, where the information flow was generally smooth and uninterrupted, as opposed to the jittery arrival of IP packets. The trick was to come up with a protocol that makes the IP network “invisible” to the endpoint fax terminals, which would mean the user of a legacy fax terminal need not know that the fax call was traversing an IP network. The network interconnections supported by T.38 are shown above. The two fax terminals on either side of the figure communicate using the T.30 fax protocol published by the ITU in 1980. Interconnection of the PSTN with the IP packet network requires a “gateway” between the PSTN and IP networks. PSTN-IP Gateways support TDM voice on the PSTN side and VoIP and FoIP on the packet side. For voice sessions, the gateway will take in voice packets on the IP side, accumulate a few packets to ensure a smooth flow of TDM data upon their release, and then meter them out over TDM where they eventually are heard by a human or stored on a computer for later playback. The gateway employs packet-management techniques to enhance the quality of the speech in the presence of network errors by taking advantage of the natural ability of a listener to not really hear the occasional missing or repeated packet. But facsimile data are transmitted by modems, which aren't as forgiving as the human ear is for speech. Missing packets will often cause a fax session to fail at worst or create one or more image lines in error at best. So the job of T.38 is to “fool” the terminal into “thinking” that it's communicating directly with another T.30 terminal. It will also correct for network delays with so-called spoofing techniques, and missing or delayed packets with fax-aware buffer-management techniques. Spoofing refers to the logic implemented in the protocol engine of a T.38 relay that modifies the protocol commands and responses on the TDM side to keep network delays on the IP side from causing the transaction to fail. This is done, for example, by padding image lines or deliberately causing a message to be re-transmitted to render network delays transparent to the sending/receiving fax terminals. Networks that do not have packet loss or excessive delay can exhibit acceptable fax performance without T.38, provided the PCM clocks in all gateways are of very high accuracy (explained below). T.38 not only removes the effect of PCM clocks not being synchronized, but also reduces the required network bandwidth by a factor of 10, while it corrects for packet loss and delay. === Bandwidth reduction === As shown in the diagram below, a T.38 gateway is composed of two primary elements: the fax modems and the T.38 subsystem. The fax modems modulate and demodulate the PCM samples of the analog data, turning the sampled-data representation of the fax terminal's analog signal to its binary translation, and vice versa. The PSTN network samples the analog signal of a voice or modem signal (it doesn't know the difference) 8,000 times per second (SPS), and encodes them as 8-bit data bytes. This means 8000 samples-per-second times 8-bits per sample, or 64,000 bits per second (bit/s) to represent the modem (or voice) data in one direction. For both directions the modem transaction consumes 128,000 bits of network bandwidth. However, the typical modem in a fax terminal transmits the image data at 33,600 bit/s, so if the analog data are first converted to the digital content they represent, only 33,600 bits (plus network overhead of a few bytes) are needed. And since T.30 fax is a half-duplex protocol, the network is only needed for one direction at a time. Refer to RFC 3261 === PCM clock synchronization === In the diagram above, there is a sample-rate clock in the fax terminal and one in the gateway's modems that is used to trigger the sampling of the analog line 8,000 times per second. These clocks are usually quite accurate, but in some low-cost terminal adapters (a one or two-line gateway) the PCM clock can be surprisingly inaccurate. If the terminal is sending data to the gateway, and the gateway's clock is too slow, the buffers (jitter buffers) in the gateway will eventually overflow, causing the transaction to fail. Since the difference is often quite small, this problem occurs on long, detailed fax images giving the clocks more time to cause the jitter buffer in gateway to either underflow or overflow, which is just the same as missing or duplicated packets. === Packet loss === T.38 provides facilities to eliminate the effects of packet loss through data redundancy. When a packet is sent, either zero, one, two, three, or even more of the previously sent packets are repeated. (The specification does not impose a limit.) This increases the network bandwidth required (it's still much less than not using T.38) but it allows the receiving gateway to reconstruct the complete packet sequence, even with a fairly high level of packet loss. == Related standards == T.4 is the umbrella specification for fax. It specifies the standard image sizes, two forms of image-data compression (encoding), the image-data format, and references, T.30 and the various modem standards. T.6 specifies a compression scheme that reduces the time required to transmit an image by roughly 50-percent. T.30 specifies the procedures that a sending and receiving terminal use to set up a fax call, determine the image size, encoding, and transfer speed, the demarcation between pages, and the termination of the call. T.30 also references the various modem standards. V.21, V.27ter, V.29, V.17, V.34: ITU modem standards used in facsimile. The first three were ratified prior to 1980, and were specified in the original T.4 and T.30 standards. V.34 was published for fax in 1994. T.37 The ITU standard for sending a fax-image file via e-mail to the intended recipient of a fax. G.711 pass through - this is where the T.30 fax call is carried in a VoIP call encoded as audio. This is sensitive to network packet loss, jitter and clock synchronization. When using voice high-compression encoding techniques such as, but not limited to, G.729, some fax tonal signa
Nobody (username)
In many Unix variants, "nobody" is the conventional name of a user identifier which owns no files, is in no privileged groups, and has no abilities except those which every other user has. It is normally not enabled as a user account, i.e. has no home directory or login credentials assigned. Some systems also define an equivalent group "nogroup". == Uses == The pseudo-user "nobody" and group "nogroup" are used, for example, in the NFSv4 implementation of Linux by idmapd, if a user or group name in an incoming packet does not match any known username on the system. It was once common to run daemons as nobody, especially on servers, in order to limit the damage that could be done by a malicious user who gained control of them. However, the usefulness of this technique is reduced if more than one daemon is run like this, because then gaining control of one daemon would provide control of them all. The reason is that processes owned by the same user have the ability to send signals to each other and use debugging facilities to read or even modify each other's memory. Modern practice, as recommended by the Linux Standard Base, is to create a separate user account for each daemon.
W3C Device Description Working Group
The W3C Device Description Working Group (DDWG), operating as part of the World Wide Web Consortium (W3C) Mobile Web Initiative (MWI), was chartered to "foster the provision and access to device descriptions that can be used in support of Web-enabled applications that provide an appropriate user experience on mobile devices." Mobile devices exhibit the greatest diversity of capabilities, and therefore present the greatest challenge to content adaptation technologies. The group published several documents, including a list of requirements for an interface to a Device Description Repository (DDR) and a standard interface meeting those requirements. The group was rechartered in 2006 to work in public towards the development of the Application Programming Interface (API) for a DDR. Early in 2007, the group launched a wiki and a blog to add to the public mailing list. The group subsequently published a formal vocabulary of core device properties, and an API called the DDR Simple API, which became a W3C Recommendation in December 2008. The group closed at the end of 2008, but with the intention of maintaining the Web pages, blog and wiki through W3C volunteer effort. == Publications == The DDWG published several W3C Working Group Notes and one W3C Recommendation. A W3C WG Note that articulates what the W3C and other organizations are doing or have already done with regard to device information. This document suggests an environment in which these technologies work together to meet the goals of content adaptation. The completed document was published on 31 October 2007. A W3C WG Note describing the ecosystem surrounding creation, maintenance and use of device descriptions. The completed document was published on 31 October 2007. A W3C WG Note describing a set of requirements for a reference repository of device descriptions. The completed document was published on 17 December 2007. A W3C WG Note describing a process to manage contributions to an initial core vocabulary, identification of key device properties, a formal initial core vocabulary and the identification of a maintainer for the core vocabulary. The details were contained in the Working Group Note describing the DDWG Core Vocabulary published on 14 April 2008. A W3C WG Note defining useful grouping and structure patterns in device descriptions. The Device Description Structures document was published as a Working Draft on 5 December 2008. The intention is that this document will be future input to other W3C groups. A W3C Recommendation defining a language-neutral programming interface to a Device Description Repository. The DDR Simple API was published on 5 December 2008. There is the possibility of future publications on the DDWG wiki describing implementations of the API in various languages, including Java, IDL, WSDL, C# etc. Much of the DDWG's material was developed in public via the DDWG Wiki and through their public mailing lists.