Thinkfree Office

Thinkfree Office

Thinkfree Office is a web-based commercial office productivity suite developed by South Korea-based Thinkfree Inc. It includes Word (a word processor), Spreadsheet (a spreadsheet) and Presentation (a presentation program). They are compatible with Microsoft Office's Word, PowerPoint, and Excel. It also features collaborative editing. The product is hosted on the client's server. == Supported file formats == Thinkfree Office supports ISO/IEC international standard ISO/IEC 26300 Open Document Format for Office Applications (odf, odt, odp, ods, odg). It also supports Microsoft's XML formats (docx, pptx, xlsx) and Microsoft's legacy binary formats (doc, ppt, xls). == Naming == The software was previously marketed under different names, such as Thinkfree Server, Thinkfree Online, Hancom Office Online, and Hancom Office Web. Eventually, the brand was consolidated under the name Thinkfree Office. == History == In June 2000, Thinkfree Inc. released Thinkfree Office, based in Silicon Valley, California. It is recognized as the world's first online office editor (predating Google Docs and Microsoft 365) and attracted significant media coverage, including reports on CNN. In 2001, Microsoft CEO Steve Ballmer highlighted Thinkfree as a significant competitor in a magazine interview, considering it a potential threat to his company, second only to Linux. In November 2003, Hancom, a South Korean office software company, signed a memorandum of understanding and subsequently acquired Thinkfree. In January 2004, Thinkfree expanded into other foreign markets. Subsidiary Haansoft USA, Inc. was created in San Jose, California to begin formal commercial operations in the US market. At the same time, a partnership was established with Riverdeep with the purpose of improving marketshare. In February 2004, expansion into the Japanese market began. A commercial agency agreement was signed with PSI in Shinjuku, Japan, which allowed for localized distribution. In addition, a global agreement was entered into with Yamada Denki, one of the three main computer distributors in Japan, for a total of 180,000 units. In May 2006, Thinkfree Office received the "Product of the Year" award at the Well-Connected Awards, USA. In January 2009, Thinkfree Mobile was launched at CES 2009 in Las Vegas. In April 2009, Thinkfree Live, Korea's first web office service, was launched. In June 2018, a partnership was formed with Amazon Web Services to integrate Thinkfree Office into WorkDocs, an in-house office suite. In October 2023, Hancom split its online office business unit as "Thinkfree Inc.".

Zardoz (computer security)

In computer security, the Security-Digest list, better known as the Zardoz list, was a semi-private full disclosure mailing list run by Neil Gorsuch from 1989 through 1991. It identified weaknesses in systems and gave directions on where to find them. It was a perennial target for computer hackers, who sought archives of the list for information on undisclosed software vulnerabilities. == Membership restrictions == Access to Zardoz was approved on a case-by-case basis by Gorsuch, principally by reference to the user account used to send subscription requests; requests were approved for root users, valid UUCP owners, or system administrators listed at the NIC. The openness of the list to users other than Unix system administrators was a regular topic of conversation, with participants expressing concern that vulnerabilities and exploitation details disclosed on the list were liable to spread to hackers. The circulation of Zardoz postings was an open secret among computer hackers, and mocked in a Phrack parody of an IRC channel populated by security experts. == Notable participants == Keith Bostic discussed BSD Sendmail vulnerabilities Chip Salzenberg discussed Peter Honeyman's posting of a UUCP worm, and shell script security Gene Spafford discussed VMS and Ultrix bugs, and relayed law enforcement enquiries about the Morris Worm Tom Christiansen discussed SUID shell scripts Chris Torek discussed devising exploits from general descriptions of vulnerabilities Henry Spencer discussed Unix security Brendan Kehoe discussed systems security Alec Muffett announced Crack, the Unix password cracker The majority of Zardoz participants were Unix systems administrators and C software developers. Neil Gorsuch and Gene Spafford were the most prolific contributors to the list.

Someday (short story)

"Someday" is a science fiction short story by American writer Isaac Asimov. It was first published in the August 1956 issue of Infinity Science Fiction and reprinted in the collections Earth Is Room Enough (1957), The Complete Robot (1982), Robot Visions (1990), and The Complete Stories, Volume 1 (1990). == Plot summary == The story is set in a future where computers play a central role in organizing society. Humans are employed as computer operators, but they leave most of the thinking to machines. Indeed, whilst binary programming is taught at school, reading and writing have become obsolete. The story concerns a pair of boys who dismantle and upgrade an old Bard, a child's computer whose sole function is to generate random fairy tales. The boys download a book about computers into the Bard's memory in an attempt to expand its vocabulary, but the Bard simply incorporates computers into its standard fairy tale repertoire. The story ends with the boys excitedly leaving the room after deciding to go to the library to learn "squiggles" (writing) as a means of passing secret messages to one another. As they leave, one of the boys accidentally kicks the Bard's on switch. The Bard begins reciting a new story about a poor mistreated and often ignored robot called the Bard, whose sole purpose is to tell stories, which ends with the words: "the little computer knew then that computers would always grow wiser and more powerful until someday—someday—someday—…"

Dominic Harris

Dominic Harris (born 16 November 1976) is a British artist known for integrating modern technology and classical design in his interactive artworks. == Background == Dominic Harris was born in London on 16 November 1976, and grew up in London, Brussels, and Michigan before returning to London in 1995. Harris attended the Cranbrook Kingswood Upper School, and then trained as an architect at the Bartlett School of Architecture, and has been ARB registered since 2011. Harris designs and fabricates his artworks at Dominic Harris Studio, a multi-disciplinary practice he founded in 2007. This studio consists of 25 people with diverse backgrounds including architecture, product design, electronics, programming, graphic design, and workshop skills. Harris uses the resources of his studio for the ongoing development, prototyping and production of his artworks. Harris also oversees the studio's international projects where his fascinations are translated into larger scale projects that span residential, retail, and public art projects. In 2015, Harris was granted permission by the Walt Disney Company to use their Intellectual Property for the purpose of making new interactive artworks. Harris is the only artist to gain permission to use Disney's back catalogue of characters, and led him to creating his interactive versions of "Snow White and the Seven Dwarfs" and "Mickey and Minnie: An Interactive Diptych". Harris is fascinated by the idea of using data streams, algorithms, and computer code to generate dynamic and ever-changing artworks. He sees data as a raw material that can be transformed into visual poetry. Many of his installations and sculptures are interactive, responding to the presence and movement of viewers/participants. This creates an immersive experience where the observer becomes part of the artwork itself. Harris is also the founding partner of a sister studio in London called Cinimod Studio that creates large commissioned installations, interactive events and lighting designs for large brands. == Works == == Exhibitions == The works of Dominic Harris have been exhibited internationally, both through direct and gallery representation. Solo shows: "Feeding Consciousness" at Halcyon Gallery, Mayfair, London, UK – 2023 "US: NOW" at Halcyon Gallery, Mayfair, London, UK – 2020 "Imagine" at Halcyon Gallery, Mayfair, London, UK – 2019 "5 Year Celebration", Priveekollektie Contemporary Art | Design, London, UK – 2016. "Moments of Reflection" at PHOS ART + DESIGN, Mayfair, London, UK – 2015 Recent exhibitions include: In Plain Sight, 2024 Halcyon Gallery Victoria & Albert Museum Dublin Science Museum Design Miami / Basel Design Miami Art Miami Art 14, London PAD Paris PAD London Art Geneva == Gallery Representation == 2010 to 2019: Dominic Harris was represented by Priveekollektie Contemporary Art | Design, a Dutch gallery based in Heusden, the Netherlands, and with a regular presence on the international art and design circuits. 2015: Dominic Harris was shown with PHOS ART + DESIGN Gallery, in Mayfair, London, UK. 2019 – ongoing: Dominic Harris is exclusively represented by the Halcyon Gallery, an established international gallery based in Mayfair, London. == Collections == The majority of Harris's work has been bought by private collectors. Since 2012 Harris's work is also being acquired by several large institutional collections, including the Borusan Contemporary Art Collection in Istanbul. Harris's artworks include some of the biggest and most respected international art collectors and are also displayed in public spaces. == Books == Dominic Harris: Feeding Consciousness. Halcyon Gallery, 2023. Imagine: Dominic Harris (exhibition catalogue). Halcyon Gallery, 2019. A Touch Of Code: Documents the "Beacon" art installation and "Flutter" artwork (ISBN 978-3899553314) Dominic Harris, Artworks, Edition Eight. (ISBN 978-0957306325) Digital Real: Kunst & Nachhaltigkeit Vol 8.

Proof assistant

In computer science and mathematical logic, a proof assistant or interactive theorem prover is a software tool to assist with the development of formal proofs by human–machine collaboration. This involves some sort of interactive proof editor, or other interface, with which a human can guide the search for proofs, the details of which are stored in, and some steps provided by, a computer. A recent effort within this field is making these tools use artificial intelligence to automate the formalization of ordinary mathematics. == Automated proof checking == Automated proof checking is the process of using software for checking proofs for correctness. It is one of the most developed fields in automated reasoning. Automated proof checking differs from automated theorem proving in that automated proof checking simply mechanically checks the formal workings of an existing proof, instead of trying to develop new proofs or theorems itself. Because of this, the task of automated proof verification is much simpler than that of automated theorem proving, allowing automated proof checking software to be much simpler than automated theorem proving software. Because of this small size, some automated proof checking systems can have less than a thousand lines of core code, and are thus themselves amenable to both hand-checking and automated software verification. The Mizar system, HOL Light, and Metamath are examples of automated proof checking systems. Automated proof checking can be done either as a batch operation, or interactively, as part of an interactive theorem proving system. == History == Automath, which was developed by Nicolaas Govert de Bruijn starting in 1967, is often considered the first proof checker and the first system to utilize the Curry–Howard correspondence between programs and proofs. Automath was used by L.S. van Benthem Jutting in 1977 to formalize Landau's Foundations of Analysis, which was the first formalization of the real numbers. In 1973, Robert Boyer and J Moore published Proving Theorems about LISP Functions which aimed to verify programs, not mathematics. Their theorem prover is now known as ACL2. In the 1970s, Edinburgh LCF introduced the idea of using a functional programming language as the metalanguage for a theorem prover, and led to the HOL family of proof assistants. The 1990s saw the rise of Rocq, (then known as Coq), which has been used for many large-scale formalization projects. Since the late 2010s, Lean, a proof assistant strongly influenced by Rocq, has become another popular choice, especially for formalizing mathematics. == System comparison == ACL2 – a programming language, a first-order logical theory, and a theorem prover (with both interactive and automatic modes) in the Boyer–Moore tradition. HOL theorem provers – A family of tools ultimately derived from the LCF theorem prover. In these systems, the logical core is a library of their programming language. Theorems represent new elements of the language and can only be introduced via "strategies" which guarantee logical correctness. Strategy composition gives users the ability to produce significant proofs with relatively few interactions with the system. Members of the family include: HOL4 – The "primary descendant", still under active development. Support for both Moscow ML and Poly/ML. Has a BSD-style license. HOL Light – A thriving "minimalist fork". OCaml based. ProofPower – Went proprietary, then returned to open source. Based on Standard ML. IMPS, An Interactive Mathematical Proof System. Isabelle is an interactive theorem prover where other systems can be encoded. Isabelle/HOL is its most popular instance, whose foundation is close to that of the HOL prover. Other instances include Isabelle/ZF and Isabelle/FOL. The main code-base is BSD-licensed, but the Isabelle distribution bundles many add-on tools with different licenses. Jape – Java based. Lean is both an interactive theorem prover and a functional, dependently-typed programming language. It is based on the calculus of inductive constructions with non-cumulative universes. Since version 4 (released in 2023), it is self-hosting. It can be used to formalise mathematics (and has a large, coherent library for formal mathematics), but also for software and hardware verification. LEGO Matita – A light system based on the calculus of inductive constructions. MINLOG – A proof assistant based on first-order minimal logic. Mizar – A proof assistant based on first-order logic, in a natural deduction style, and Tarski–Grothendieck set theory. PhoX – A proof assistant based on higher-order logic which is eXtensible. Prototype Verification System (PVS) – a proof language and system based on higher-order logic. Rocq (formerly named Coq) – A popular interactive theorem prover based on the calculus of inductive constructions. Theorem Proving System (TPS) and ETPS – Interactive theorem provers also based on simply typed lambda calculus, but based on an independent formulation of the logical theory and independent implementation. == User interfaces == A commonly used front-end for proof assistants was the Emacs-based Proof General, developed at the University of Edinburgh. Nowadays, many provers include their own editor. Rocq includes RocqIDE, which is based on OCaml/Gtk. Isabelle includes Isabelle/jEdit, which is based on jEdit and the Isabelle/Scala infrastructure for document-oriented proof processing. More recently, Visual Studio Code extensions have been developed for Rocq, Isabelle by Makarius Wenzel, and for Lean 4 by the leanprover developers. == Formalization extent == Freek Wiedijk has been keeping a ranking of proof assistants by the amount of formalized theorems out of a list of 100 well-known theorems. As of September 2025, only six systems have formalized proofs of more than 70% of the theorems, namely Isabelle, HOL Light, Lean, Rocq, Metamath and Mizar. == Notable formalized proofs == The following is a list of notable proofs that have been formalized within proof assistants.

Product-family engineering

Product-family engineering (PFE), also known as product-line engineering (PLE), is based on the ideas of "domain engineering" created by the Software Engineering Institute, a term coined by James Neighbors in his 1980 dissertation at University of California, Irvine. Software product lines are quite common in our daily lives, but before a product family can be successfully established, an extensive process has to be followed. This process is known as product-family engineering. Product-family engineering can be defined as a method that creates an underlying architecture of an organization's product platform. It provides an architecture that is based on commonality as well as planned variabilities. The various product variants can be derived from the basic product family, which creates the opportunity to reuse and differentiate on products in the family. Product-family engineering is conceptually similar to the widespread use of vehicle platforms in the automotive industry. Product-family engineering is a relatively new approach to the creation of new products, recently evolving to Model-Based Product Line Engineering (MBPLE), emphasizing the centrality of a model-centric approach in PLE. It focuses on the process of engineering new products in such a way that it is possible to reuse product components and apply variability with decreased costs and time. Product-family engineering is all about reusing components and structures as much as possible, according to the ISO/IEC 26550/2015 and the latest ISO/IEC 26580/2021 that introduced the concept of feature-based Product Line Engineering. Several studies have proven that using a product-family engineering approach for product development can have several benefits. Here is a list of some of them: Higher productivity Higher quality Faster time-to-market Lower labor needs The Nokia case mentioned below also illustrates these benefits. In 2025 the publishing of the book Model-Based Product Line Engineering (MBPLE): The feature-based path to product lines success by Marco Forlingieri, Tim Weilkiens and Hugo Guillermo Chalé-Gongora formalized the foundation of the discipline, including best practices and new industrial cases. == Overall process == The product family engineering process consists of several phases. The three main phases are: Phase 1: Product management Phase 2: Domain engineering Phase 3: Product engineering The process has been modeled on a higher abstraction level. This has the advantage that it can be applied to all kinds of product lines and families, not only software. The model can be applied to any product family. Figure 1 (below) shows a model of the entire process. Below, the process is described in detail. The process description contains elaborations of the activities and the important concepts being used. All concepts printed in italic are explained in Table 1. === Phase 1: product management === The first phase is the starting up of the whole process. In this phase some important aspects are defined especially with regard to economic aspects. This phase is responsible for outlining market strategies and defining a scope, which tells what should and should not be inside the product family. ==== Evaluate business visioning ==== During this first activity all context information relevant for defining the scope of the product line is collected and evaluated. It is important to define a clear market strategy and take external market information into account, such as consumer demands. The activity should deliver a context document that contains guidelines, constraints and the product strategy. ==== Define product line scope ==== Scoping techniques are applied to define which aspects are within the scope. This is based upon the previous step in the process, where external factors have been taken into account. The output is a product portfolio description, which includes a list of current and future products and also a product roadmap. It can be argued whether phase 1, product management, is part of the product-family-engineering process, because it could be seen as an individual business process that is more focused on the management aspects instead of the product aspect. However phase 2 needs some important input from this phase, as a large piece of the scope is defined in this phase. So from this point of view it is important to include the product-management phase (phase 1) into the entire process as a base for the domain-engineering process. === Phase 2: domain engineering === During the domain-engineering phases, the variable and common requirements are gathered for the whole product line. The goal is to establish a reusable platform. The output of this phase is a set of common and variable requirements for all products in the product line. ==== Analyze domain requirements ==== This activity includes all activities for analyzing the domain with regard to concept requirements. The requirements are categorized and split up into two new activities. The output is a document with the domain analysis. As can be seen in Figure 1 the process of defining common requirements is a parallel process with defining variable requirements. Both activities take place at the same time. ==== Define common requirements ==== Includes all activities for eliciting and documenting the common requirements of the product line, resulting in a document with reusable common requirements. ==== Define variable requirements ==== Includes all activities for eliciting and documenting the variable requirements of the product line, resulting in a document with variable requirements. ==== Design domain ==== This process step consists of activities for defining the reference architecture of the product line. This generates an abstract structure for all products in the product line. ==== Implement domain ==== During this step a detailed design of the reusable components and the implementation of these components are created. ==== Test domain ==== Validates and verifies the reusability of components. Components are tested against their specifications. After successful testing of all components in different use cases and scenarios, the domain engineering phase has been completed. === Phase 3: product engineering === In the final phase a product X is being engineered. This product X uses the commonalities and variability from the domain engineering phase, so product X is being derived from the platform established in the domain engineering phase. It basically takes all common requirements and similarities from the preceding phase plus its own variable requirements. Using the base from the domain engineering phase and the individual requirements of the product engineering phase a complete and new product can be built. After the product has been fully tested and approved, the product X can be delivered. ==== Define product requirements ==== Developing the product requirements specification for the individual product and reuse the requirements from the preceding phase. ==== Design product ==== All activities for producing the product architecture. Makes use of the reference architecture from the step "design domain", it selects and configures the required parts of the reference architecture and incorporates product specific adaptations. ==== Build product ==== During this process the product is built, using selections and configurations of the reusable components. ==== Test product ==== During this step the product is verified and validated against its specifications. A test report gives information about all tests that were carried out, this gives an overview of possible errors in the product. If the product in the next step is not accepted, the process will loop back to "build product", in Figure 1 this is indicated as "[unsatisfied]". ==== Deliver and support product ==== The final step is the acceptance of the final product. If it has been successfully tested and approved to be complete, it can be delivered. If the product does not satisfy to the specifications, it has to be rebuilt and tested again. The next figure shows the overall process of product-family engineering as described above. It is a full process overview with all concepts attached to the different steps. == Process data diagram == On the left side the entire process from the top to bottom has been drawn. All activities on the left side are linked to the concepts on the right side through dotted lines. Every concept has a number, which reflects the association with other concepts. == List of concepts == Below the list with concepts will be explained. Most concept definitions are extracted from Pohl, Bockle, & Linden (2005) and also some new definitions have been added. Table 1: List of concepts == Example == There are some good examples of the use of product family engineering, which were quite successful. The abstract model of product family engineering allows different kinds of uses, most of them are related to the consumer electronics m

Fuzzy differential inclusion

Fuzzy differential inclusion is the extension of differential inclusion to fuzzy sets introduced by Lotfi A. Zadeh. x ′ ( t ) ∈ [ f ( t , x ( t ) ) ] α {\displaystyle x'(t)\in [f(t,x(t))]^{\alpha }} with x ( 0 ) ∈ [ x 0 ] α {\displaystyle x(0)\in [x_{0}]^{\alpha }} Suppose f ( t , x ( t ) ) {\displaystyle f(t,x(t))} is a fuzzy valued continuous function on Euclidean space. Then it is the collection of all normal, upper semi-continuous, convex, compactly supported fuzzy subsets of R n {\displaystyle \mathbb {R} ^{n}} . == Second order differential == The second order differential is x ″ ( t ) ∈ [ k x ] α {\displaystyle x''(t)\in [kx]^{\alpha }} where k ∈ [ K ] α {\displaystyle k\in [K]^{\alpha }} , K {\displaystyle K} is trapezoidal fuzzy number ( − 1 , − 1 / 2 , 0 , 1 / 2 ) {\displaystyle (-1,-1/2,0,1/2)} , and x 0 {\displaystyle x_{0}} is a trianglular fuzzy number (-1,0,1). == Applications == Fuzzy differential inclusion (FDI) has applications in Cybernetics Artificial intelligence, Neural network, Medical imaging Robotics Atmospheric dispersion modeling Weather forecasting Cyclone Pattern recognition Population biology