Avid Symphony is non-linear editing software aimed at professionals in the film and television industry. It is available for Microsoft Windows PCs and Apple Macintosh platforms. Symphony is Avid's high end SD/HD finishing platform for long form work, such as documentary and episodic TV. Its interface is based on the same look and feature set as the Media Composer and Xpress systems, but contains the highest level of features and resolution including secondary color correction, uncompressed HD, and higher real-time performance. == Release history == Symphony is the software component of a tightly integrated package that includes specific hardware audio/video interfaces, storage, and the computer, also sold by Avid. Its release history is therefore tightly related to the release of new Avid interface hardware: Symphony was introduced to the market in 1998. It was based on Avid's Meridien hardware, supporting SD only, and was available first only for the PC and later for the Macintosh platforms. Its last release was 5.0.5 which supported Windows 2000 and Mac OS X v10.2. The next major upgrade was Symphony Nitris in 2005, with a redesigned software and integration with the Nitris DNA hardware (PCI-X). It supported 8 bit and 10 bit SD and HD resolutions in both compressed and uncompressed forms, the MXF format and DNxHD codec, and ran only on Windows PC platforms. Symphony Nitris DX, released in 2008, added support for a range of HD codecs, including HDV, XDCAM-HD, DVCPRO HD, and AVC-I, and brought back Mac OS support for OS X 10.5, as well as Windows Vista. Since the introduction of Symphony 6, it can be used in software-only mode (where a Nitris or Nitris DX BOB used to be required), and at the same time, like Media Composer, Symphony was opened up with "Open I/O", allowing users to have Symphony use their third party hardware from companies like AJA, Matrox, BlueFish, Blackmagic Design and MOTU. The last remaining features that differentiate it from Media Composer are Advanced Color Correction (channels, secondary color correction,), Relational Color Correction (corrections based on common clip name, tape name, program track) and Universal HD Mastering (only with Nitris DX hardware). The latter allows cross-conversions of 23.976p or 24p projects sequences to most any other format during Digital Cut. In 2013, Avid announced it would no longer offer Symphony a standalone product. Starting version 7, Symphony will be sold as an option to Media Composer. This optional package (sold at a premium) will contain all the traditional Symphony-only features to any Media Composer install. == Use in movies == The Celibacy, Director: Horacio Bocaranda Avid Media Composer 6 and Avid Symphony 6 Nitris DX American Hardcore, Director: Paul Rachman Avid Xpress Pro and Symphony Summercamp!, Director: Spike Lee Avid Xpress Pro and Symphony When the Levees Broke Avid Media Composer and Symphony Nitris Superman Returns Edited with Mac-based Film Composer XL, but HD screenings prepped with Symphony
Autognostics
Autognostics is a new paradigm that describes the capacity for computer networks to be self-aware. It is considered one of the major components of Autonomic Networking. == Introduction == One of the most important characteristics of today's Internet that has contributed to its success is its basic design principle: a simple and transparent core with intelligence at the edges (the so-called "end-to-end principle"). Based on this principle, the network carries data without knowing the characteristics of that data (e.g., voice, video, etc.) - only the end-points have application-specific knowledge. If something goes wrong with the data, only the edge may be able to recognize that since it knows about the application and what the expected behavior is. The core has no information about what should happen with that data - it only forwards packets. Although an effective and beneficial attribute, this design principle has also led to many of today's problems, limitations, and frustrations. Currently, it is almost impossible for most end-users to know why certain network-based applications do not work well and what they need to do to make it better. Also, network operators who interact with the core in low-level terms such as router configuration have problems expressing their high-level goals into low-level actions. In high-level terms, this may be summarized as a weak coupling between the network and application layers of the overall system. As a consequence of the Internet end-to-end principle, the network performance experienced by a particular application is difficult to attribute based on the behavior of the individual elements. At any given moment, the measure of performance between any two points is typically unknown and applications must operate blindly. As a further consequence, changes to the configuration of given element, or changes in the end-to-end path, cannot easily be validated. Optimization and provisioning cannot then be automated except against only the simplest design specifications. There is an increasing interest in Autonomic Networking research, and a strong conviction that an evolution from the current networking status quo is necessary. Although to date there have not been any practical implementations demonstrating the benefits of an effective autonomic networking paradigm, there seems to be a consensus as to the characteristics which such implementations would need to demonstrate. These specifically include continuous monitoring, identifying, diagnosing and fixing problems based on high-level policies and objectives. Autognostics, as a major part of the autonomic networking concept, intends to bring networks to a new level of awareness and eliminate the lack of visibility which currently exists in today's networks. == Definition == Autognostics is a new paradigm that describes the capacity for computer networks to be self-aware, in part and as a whole, and dynamically adapt to the applications running on them by autonomously monitoring, identifying, diagnosing, resolving issues, subsequently verifying that any remediation was successful, and reporting the impact with respect to the application's use (i.e., providing visibility into the changes to networks and their effects). Although similar to the concept of network awareness, i.e., the capability of network devices and applications to be aware of network characteristics (see References section below), it is noteworthy that autognostics takes that concept one step further. The main difference is the auto part of autognostics, which entails that network devices are self-aware of network characteristics, and have the capability to adapt themselves as a result of continuous monitoring and diagnostics. == Path to autognostics == Autognostics, or in other words deep self-knowledge, can be best described as the ability of a network to know itself and the applications that run on it. This knowledge is used to autonomously adapt to dynamic network and application conditions such as utilization, capacity, quality of service/application/user experience, etc. In order to achieve autognosis, networks need a means to: Continuously monitor/test the network for application-specific performance Analyze the monitoring/test data to detect problems (e.g., performance degradation) Diagnose, identify and localize sources of degradation Automatically take actions to resolve problems via remediation/provisioning Verify the problems have been resolved (potentially rolling back changes if ineffective) Subsequently, continue to monitor/test for performance
Serverless computing
Serverless computing is "a cloud service category where the customer can use different cloud capability types without the customer having to provision, deploy and manage either hardware or software resources, other than providing customer application code or providing customer data. Serverless computing represents a form of virtualized computing", according to ISO/IEC 22123-2. Serverless computing is a broad ecosystem that includes the cloud provider, function as a service (FaaS), managed services, tools, frameworks, engineers, stakeholders, and other interconnected elements. == Overview == Serverless is a misnomer in the sense that servers are still used by cloud service providers to execute code for developers. The definition of serverless computing has evolved over time, leading to varied interpretations. According to Ben Kehoe, serverless represents a spectrum rather than a rigid definition. Emphasis should shift from strict definitions and specific technologies to adopting a serverless mindset, focusing on leveraging serverless solutions to address business challenges. Serverless computing does not eliminate complexity but shifts much of it from the operations team to the development team. However, this shift is not absolute, as operations teams continue to manage aspects such as identity and access management (IAM), networking, security policies, and cost optimization. Additionally, while breaking down applications into finer-grained components can increase management complexity, the relationship between granularity and management difficulty is not strictly linear. There is often an optimal level of modularization where the benefits outweigh the added management overhead. According to Yan Cui, serverless techniques should be adopted only when they help to deliver customer value faster. And while adopting, organizations should take small steps and de-risk along the way. == Challenges == Serverless applications are prone to fallacies of distributed computing. In addition, they are prone to the following fallacies: Versioning is simple Compensating transactions always work Observability is optional === Monitoring and debugging === Monitoring and debugging serverless applications can present unique challenges due to their distributed, event-driven nature and proprietary environments. Traditional tools may fall short, making it difficult to track execution flows across services. However, modern solutions such as distributed tracing tools (e.g., AWS X-Ray, Datadog), centralized logging, and cloud-agnostic observability platforms are mitigating these challenges. Emerging technologies like OpenTelemetry, AI-powered anomaly detection, and serverless-specific frameworks are further improving visibility and root cause analysis. While challenges persist, advancements in monitoring and debugging tools are steadily addressing these limitations. === Security === According to OWASP, serverless applications are vulnerable to variations of traditional attacks, insecure code, and some serverless-specific attacks (like denial of wallet). So, the risks have changed and attack prevention requires a shift in mindset. === Vendor lock-in === Serverless computing is provided as a third-party service. Applications and software that run in the serverless environment are by default locked to a specific cloud vendor. This issue is exacerbated in serverless computing, as with its increased level of abstraction, public vendors only allow customers to upload code to a FaaS platform without the authority to configure underlying environments. More importantly, when considering a more complex workflow that includes backend-as-a-service (BaaS), a BaaS offering can typically only natively trigger a FaaS offering from the same provider. This makes the workload migration in serverless computing virtually impossible. Therefore, considering how to design and deploy serverless workflows from a multi-cloud perspective could mitigate this. == High-performance computing == Serverless computing may not be ideal for certain high-performance computing (HPC) workloads due to resource limits often imposed by cloud providers, including maximum memory, CPU, and runtime restrictions. For workloads requiring sustained or predictable resource usage, bulk-provisioned servers can sometimes be more cost-effective than the pay-per-use model typical of serverless platforms. However, serverless computing is increasingly capable of supporting specific HPC workloads, particularly those that are highly parallelizable and event-driven, by leveraging its scalability and elasticity. The suitability of serverless computing for HPC continues to evolve with advancements in cloud technologies. == Anti-patterns == The grain of sand anti-pattern refers to the creation of excessively small components (e.g., functions) within a system, often resulting in increased complexity, operational overhead, and performance inefficiencies. Lambda pinball is a related anti-pattern that can occur in serverless architectures when functions (e.g., AWS Lambda, Azure functions) excessively invoke each other in fragmented chains, leading to latency, debugging and testing challenges, and reduced observability. These anti-patterns are associated with the formation of a distributed monolith. These anti-patterns are often addressed through the application of clear domain boundaries, which distinguish between public and published interfaces. Public interfaces are technically accessible interfaces, such as methods, classes, API endpoints, or triggers, but they do not come with formal stability guarantees. In contrast, published interfaces involve an explicit stability contract, including formal versioning, thorough documentation, a defined deprecation policy, and often support for backward compatibility. Published interfaces may also require maintaining multiple versions simultaneously and adhering to formal deprecation processes when breaking changes are introduced. Fragmented chains of function calls are often observed in systems where serverless components (functions) interact with other resources in complex patterns, sometimes described as spaghetti architecture or a distributed monolith. In contrast, systems exhibiting clearer boundaries typically organize serverless components into cohesive groups, where internal public interfaces manage inter-component communication, and published interfaces define communication across group boundaries. This distinction highlights differences in stability guarantees and maintenance commitments, contributing to reduced dependency complexity. Additionally, patterns associated with excessive serverless function chaining are sometimes addressed through architectural strategies that emphasize native service integrations instead of individual functions, a concept referred to as the functionless mindset. However, this approach is noted to involve a steeper learning curve, and integration limitations may vary even within the same cloud vendor ecosystem. Reporting on serverless databases presents challenges, as retrieving data for a reporting service can either break the bounded contexts, reduce the timeliness of the data, or do both. This applies regardless of whether data is pulled directly from databases, retrieved via HTTP, or collected in batches. Mark Richards refers to this as the reach-in reporting anti-pattern. A possible alternative to this approach is for databases to asynchronously push the necessary data to the reporting service instead of the reporting service pulling it. While this method requires a separate contract between services and the reporting service and can be complex to implement, it helps preserve bounded contexts while maintaining a high level of data timeliness. == Principles == Adopting DevSecOps practices can help improve the use and security of serverless technologies. In serverless applications, the distinction between infrastructure and business logic is often blurred, with applications typically distributed across multiple services. To maximize the effectiveness of testing, integration testing is emphasized for serverless applications. Additionally, to facilitate debugging and implementation, orchestration is used within the bounded context, while choreography is employed between different bounded contexts. Ephemeral resources are typically kept together to maintain high cohesion. However, shared resources with long spin-up times, such as AWS RDS clusters and landing zones, are often managed in separate repositories, deployment pipeline, and stacks.
Dimensions CM
Dimensions CM is a software change and configuration management product developed by OpenText Corporation. It includes revision control, change, build and release management capabilities. Since 2014 (v14.1) Dimensions CM includes PulseUno module providing Code review and Continuous integration capabilities. Starting with the version 14.5.2 (2020) it can also serve as a binary repository manager. == History == Previous product names: PCMS Dimensions (SQL Software) PVCS Dimensions (Merant, Intersolv)
Army Chief Information Officer/G-6
In September 2020, the Army realigned the previously consolidated CIO/G-6 function into two separate roles, Office of the Chief Information Officer and Deputy Chief of Staff, G-6, that report to the secretary of the Army and chief of staff of the Army, respectively. The realignment came after several months of planning and coordination. Lt. Gen. John Morrison was nominated to the Senate for promotion and assignment as the G-6 and confirmed, assuming that position in August 2020. Subsequently, the Secretary of the Army, Ryan McCarthy appointed Dr. Raj G. Iyer as the first civilian Chief Information Officer, a career Senior Executive Service position in November 2020. == G-6 == Advise chief of staff of the Army and the Chief Information Officer on planning, fielding, and execution of C4IT worldwide Army operations Develop and execute the plan for the Unified Network Implement Army information assurance Supervise C4IT, Signal support, Information security, Force structure and equipping activities in support of warfighting operations Oversee management of the Signal forces == Planned realignment == On June 11, 2020, the Army announced that the two roles of CIO and Deputy Chief of Staff, G-6 (DCS, G-6) would be realigned no later than August 31, 2020, with separate individuals responsible for each position. With the realignment: CIO core functions will be policy, governance, and oversight. Focus areas include: Information Environment, Cybersecurity, Enterprise Architecture, and Data Policy/Oversight/Governance, Enterprise Architecture, Enterprise Cloud Management and IT Spend/Category Management. DCS, G-6 core functions will be planning, strategy, and implementation. Focus areas include: Information Environment/Network, Planning and Integration, Theater Synchronization, Architecture Integration, Enterprise Information Environment (EIE) Mission Area Portfolio Management and Mission Decision Packet Management. In order to support multi-domain operations, the Army will have to connect Enterprise networks and tactical networks. —LTG Morrison, DCS, G-6 DCS G-6 released the Army Unified Network Plan under the Army Digital Transformation Strategy, to help the Army to establish a Multi-Domain Operations capable force by 2028. The Unified Network will enable Army formations, as part of the Joint Force, to operate in highly contested and congested operational environments with the speed and global range to achieve decision dominance and maintain overmatch. The plan shapes, synchronizes, integrates and governs Unified Network efforts and aligns the personnel, organizational structure and capabilities required to enable MDO at all echelons. == Chief signal officers and their successors == Chief signal officers (1860–1964) Maj. Albert J. Myer 1860–1863 Lt. Col. William J. L. Nicodemus 1863–1864 Col. Benjamin F. Fisher 1864–1866 Col. Albert J. Myer 1866–1880 (promoted to brigadier general 16 June 1880) Brig. Gen. William B. Hazen 1880–1887 Brig. Gen. Adolphus W. Greely 1887–1906 Brig. Gen. James Allen 1906–1913 Brig. Gen. George P. Scriven 1913–1917 Brig. Gen. George O. Squier 1917–1923 (promoted to major general 6 October 1917) Maj. Gen. Charles McK. Saltzman 1924–1928 Maj. Gen. George Sabin Gibbs 1928–1931 Maj. Gen. Irving J. Carr 1931–1934 Maj. Gen. James B. Allison 1935–1937 Maj. Gen. Joseph O. Mauborgne 1937–1941 Maj. Gen. Dawson Olmstead 1941–1943 Maj. Gen. Harry C. Ingles 1943–1947 Maj. Gen. Spencer B. Akin 1947–1951 Maj. Gen. George I. Back 1951–1955 Lt. Gen. James D. O’Connell 1955–1959 Maj. Gen. Ralph T. Nelson 1959–1962 Maj. Gen. Earle F. Cook 1962–1963 Maj. Gen. David Parker Gibbs 1963–1964 Chiefs of communications-electronics (1964–1967) Maj. Gen. David Parker Gibbs 1964–1966 Maj. Gen. Walter E. Lotz, Jr. 1966–1967 Assistant chiefs of staff for communications-electronics (1967–1974) Maj. Gen. Walter E. Lotz, Jr. 1967–1968 Maj. Gen. George E. Pickett 1968–1972 Lt. Gen. Thomas Rienzi 1972–1974 Directors of telecommunications and command and control (1974–1978) (a directorate of ODCSOPS) Lt. Gen. Thomas Rienzi 1974–1977 Lt. Gen. Charles R. Myer 1977–1978 Assistant chiefs of staff for automation and communications (1978–1981) Lt. Gen. Charles R. Myer 1978–1979 Maj. Gen. Clay T. Buckingham 1979–1981 Assistant deputy chiefs of staff for operations and plans (command, control, communications, and computers) (1981–1984) Maj. Gen. Clay T. Buckingham 1981–1982 Maj. Gen. James M. Rockwell 1982–1984 Assistant chiefs of staff for information management (1984–1987) Lt. Gen. David K. Doyle 1984–1986 Lt. Gen. Thurman D. Rodgers 1986–1987 Directors of information systems for command, control, communications, and computers Lt. Gen. Thurman D. Rodgers 1987–1988 Lt. Gen. Bruce R. Harris 1988–1990 Lt. Gen. Jerome B. Hilmes 1990–1992 Lt. Gen. Peter A. Kind 1992–1994 Lt. Gen. Otto J. Guenther 1995–1997 Lt. Gen. William H. Campbell Chief Information Officer, Military Deputy to the Army Acquisition Executive, and Director of Information Systems for Command, Control, Communications and Computers Lt. Gen. William H. Campbell 1997–2000
WinFIG
WinFIG is a proprietary shareware vector graphics editor application. The file format and rendering are as close to Xfig as possible, but the program takes advantage of Windows features like clipboard, printer preview, multiple documents etc. As of 2011, WinFIG is under active development, with new features being added regularly. == History == The first release was in March 2003 and based on the Amiga program AmiFIG by the same author, which is also an Xfig compatible vector drawing application. WinFIG was not created by porting the Xfig source code to Windows. It is an independent implementation. Starting with release 4.0 WinFIG was ported from MFC to the Qt toolkit as the application framework and thereby enabling the first release of a Linux version. After Version 7.8 the Version scheme changes to years with version 2021.1. == Interface and usability == WinFIG is designed to provide a clear, efficient and convenient graphical user interface. It allows working on multiple documents using an MDI user interface and provides unlimited undo and redo of actions. == Features == === Object creation === The basic types of objects in WinFIG are: Open and closed Splines Ellipses Polylines and Polygons Texts LaTeX formatted texts Arcs Images: PNG, GIF, JPEG, EPS and more Compound objects, which are hierarchical compositions of objects Objects can have several attributes, which depend on the object type: Line width Line style Line cap style Line join style Arrows Outline color, fill color and fill pattern === Object manipulation === move copy scale rotate align add/delete points from lines or splines copy object attributes Numerical input of point coordinates === Exports === WinFIG can export into various formats: Raster formats: GIF, JPEG, PNG, PPM, XBM, XPM, PCX, TIFF, SLD Formats for printed documents: PostScript, PDF, LaTeX, HP-GL (printer control language used by Hewlett-Packard plotters), Vector graphics formats: EPS, SVG, PSTricks, TPIC, PIC, CGM, Metafont, MetaPost, EMF, Tk. === Miscellaneous === Winfig can handle smart links. A smart link is a moving connection from a source to a target object. It is established by connecting the end point of a line or spline to another object. The connecting line or spline segment follows the movements of the target object. Smart links are useful for diagrams, graphs etc. WinFIG can show a grid and provides several magnet modes for constraining editing operations to discrete coordinates. Objects can be organized in layers to control their Z-order. This is important to control overlapping of filled shapes. Object library: drawings can be stored in a special sub-folder in the program installation directory, which makes them available in the library dialog for easy reuse.
ZipBooks
ZipBooks is a free online accounting software company based in American Fork, Utah. The cloud-based software is an accounting and bookkeeping tool that helps business owners process credit cards, track finances, and send invoices, among other features. == History == ZipBooks was founded by Tim Chaves in June 2015, backed by venture capital firm Peak Ventures. The company secured an additional $2 million of funding in July 2016, and in 2017 it was awarded a $100,000 economic grant by the Utah Governor's Office of Economic Development Technology Commercialization and Innovation Program. == Products == ZipBooks' core modules are invoicing, transactions, bills, reporting, time tracking, contacts, and payroll. Accrual accounting was added in 2017. The application is available on G Suite, iOS, Slack, and as a web application. == Reception == Computerworld compared ZipBooks favorably with other accounting software. PC Magazine praised its user experience, but stated it lacked "a lot of features that competing sites offer".