Machin-like formula

In mathematics, Machin-like formulae are a popular technique for computing to a large number of digits. They are generalizations of John Machin's formula from 1706:
which he used to compute to 100 decimal places.
Machin-like formulas have the form
where formula_2 and formula_3 are positive integers such that formula_4, formula_5 is a signed non-zero integer, and formula_6 is a positive integer.
These formulae are used in conjunction with the Taylor series expansion for arctangent:
Derivation.
The following equations were derived in Angle addition formula:
Algebraic manipulation of these equations yields the following:
if
All of the Machin-like formulae can be derived by repeated application of equation . As an example, we show the derivation of Machin's original formula:
An insightful way to visualize equation is to picture what happens when two complex numbers are multiplied together:
The angle associated with a complex number formula_29 is given by:
Thus, in equation , the angle associated with the product is:
Note that this is the same expression as occurs in equation . Thus equation can be interpreted as saying that the act of multiplying two complex numbers is equivalent to adding their associated angles (see multiplication of complex numbers).
The expression:
is the angle associated with:
Equation can be re-written as:
Here formula_35 is an arbitrary constant that accounts for the difference in magnitude between the vectors on the two sides of the equation. The magnitudes can be ignored, only the angles are significant.
Using complex numbers.
Other formulas may be generated using complex numbers. For example, the angle of a complex number formula_36 is given by formula_37 and, when one multiplies complex numbers, one adds their angles. If a=b then formula_37 is 45 degrees or formula_39 radians. This means that if the real part and complex part are equal then the arctangent will equal formula_39. Since the arctangent of one has a very slow convergence rate if we find two complex numbers that when multiplied will result in the same real and imaginary part we will have a Machin-like formula. An example is formula_41 and formula_42. If we multiply these out we will get formula_43. Therefore, formula_44.
If you want to use complex numbers to show that formula_45 you first must know that when multiplying angles you put the complex number to the power of the number that you are multiplying by. So formula_46 and since the real part and imaginary part are equal then, formula_47
Lehmer's measure.
One of the most important parameters that characterizes computational efficiency of the Machin-like formula is the Lehmer's measure, defined as
In order to obtain the Lehmer's measure as small as possible, it is necessary to decrease the ratio of positive integers formula_49 in the arctangent arguments and to minimize the number of the terms in the Machin-like formula. Nowadays at formula_50 the smallest known Lehmer's measure is formula_51 due to H. Chien-Lih (1997), whose Machin-like formula is shown below. It is very common in the Machin-like formulas when all integers formula_52.
Two-term formulas.
In the special case where formula_50, there are exactly four solutions having only two terms. These are
Euler's:
Hermann's:
Hutton's (or Vega's):
and Machin's:
In the general case, where the value of formula_2 is not restricted, there are infinitely many other solutions. For example:
Example.
The adjacent diagram demonstrates the relationship between the arctangents and their areas. From the diagram, we have the following:
More terms.
The 2002 record for digits of , 1,241,100,000,000, was obtained by Yasumasa Kanada of Tokyo University. The calculation was performed on a 64-node Hitachi supercomputer with 1 terabyte of main memory, performing 2 trillion operations per second. The following two equations were both used:
Two equations are used so that one can check they both give the same result; it is helpful if the equations reuse some but not all of the arctangents because those need only be computed once - note the reuse of 57 and 239 above.
Machin-like formulae for can be constructed by finding a set of numbers where the prime factorisations of together use no more distinct primes than the number of elements in the set, and then using either linear algebra or the LLL basis-reduction algorithm to construct linear combinations of formula_62. For example, for the Størmer formula above, we have
so four terms using between them only the primes 2, 5, 13 and 61.
The most efficient currently known Machin-like formula pair discovered by Hwang Chien-Lih (黃見利) (2004) for computing are:
You will note that these formulae reuse all the same arctangents after the first one. They are constructed by looking for numbers where is divisible only by primes less than 101.
The most efficient currently known Machin-like formulas for computing are:
A further refinement is to use "Todd's Process", as described in; this leads to results such as
where the large prime 834312889110521 divides the of the last two indices.<br>
M. Wetherfield found 2004
Efficiency.
For large computations of formula_72, the binary splitting algorithm can be used to compute the arctangents much, much more quickly than by adding the terms in the Taylor series naively one at a time. In practical implementations such as y-cruncher, there is a relatively large constant overhead per term plus a time proportional to formula_73, and a point of diminishing returns appears beyond three or four arctangent terms in the sum; this is why the supercomputer calculation above used only a four-term version.
It is not the goal of this section to estimate the actual run time of any given algorithm. Instead, the intention is merely to devise a relative metric by which two algorithms can be compared against each other.
Let formula_74 be the number of digits to which formula_72 is to be calculated.
Let formula_76 be the number of terms in the Taylor series (see equation ).
Let formula_77 be the amount of time spent on each digit (for each term in the Taylor series).
The Taylor series will converge when:
Thus:
For the first term in the Taylor series, all formula_74 digits must be processed. In the last term of the Taylor series, however, there's only one digit remaining to be processed. In all of the intervening terms, the number of digits to be processed can be approximated by linear interpolation. Thus the total is given by:
The run time is given by:
Combining equations, the run time is given by:
Where formula_35 is a constant that combines all of the other constants. Since this is a relative metric, the value of formula_35 can be ignored.
The total time, across all the terms of equation , is given by:
formula_77 cannot be modelled accurately without detailed knowledge of the specific software. Regardless, we present one possible model.
The software spends most of its time evaluating the Taylor series from equation . The primary loop can be summarized in the following pseudo code:
In this particular model, it is assumed that each of these steps takes approximately the same amount of time. Depending on the software used, this may be a very good approximation or it may be a poor one.
The unit of time is defined such that one step of the pseudo code corresponds to one unit. To execute the loop, in its entirety, requires four units of time. formula_77 is defined to be four.
Note, however, that if formula_2 is equal to one, then step one can be skipped. The loop only takes three units of time. formula_77 is defined to be three.
As an example, consider the equation:
The following table shows the estimated time for each of the terms:
The total time is 0.75467 + 0.54780 + 0.60274 = 1.9052
Compare this with equation . The following table shows the estimated time for each of the terms:
The total time is 1.1191 + 0.8672 = 1.9863
The conclusion, based on this particular model, is that equation is slightly faster than equation , regardless of the fact that equation has more terms. This result is typical of the general trend. The dominant factor is the ratio between formula_2 and formula_3. In order to achieve a high ratio, it is necessary to add additional terms. Often, there is a net savings in time.


Fuduntu

Fuduntu Linux was a Fedora-based Linux distribution created by Andrew Wyatt. It was actively developed between 2010 and 2013. It was designed to fit in somewhere between Fedora and Ubuntu. It was notable for providing a 'classic' desktop experience. Although it was optimized for netbooks and other portable computers it is a general-purpose OS.
History.
After forking Fedora 14 in early November 2011, Fuduntu became an independent distribution and was no longer considered a "remix" of Fedora, it did not qualify as a "spin" because it contained packages not included in Fedora.
On a Team Meeting held on 14 April 2013, it was decided that Fuduntu would discontinue development and no new versions will be released. Large parts of the team were planning to work on a new rebased OS. The move of wider support to GTK 3 and Systemd were also factors, as Fuduntu used GTK 2 and wasn't systemd based.
Post development.
On 28 April 2013 the Fuduntu website officially informed that the project has come to an end and that users may want to switch to the new project Cloverleaf Linux which is based on openSUSE instead.
In late August, the development team decided to discontinue Cloverleaf, due to lack of manpower. Other concerns included image leaks and other issues regarding source code for KDE's upcoming lightweight desktop environment KLyDE, which in term was supposed to be used as Cloverleaf's default desktop environment.
Features.
As Fuduntu was originally targeted at the Asus Eee PC and other netbooks it contained tweaks to reduce power consumption. This included moving the /tmp and /var/log directories to a RAM disk, and reducing swappiness 10, to reduce the frequency of disk spin-up. Also, Fuduntu includes the Jupiter power management applet (also developed by Andrew Wyatt), for easy adjustment of CPU performance settings, screen output and resolution, etc.
The default packages include Nautilus Elementary, Adobe Flash, the Fluendo MP3 Codec, VLC, Infinality Freetype, LibreOffice, and the nano editor.
Look and Feel.
The used icon theme is called Faenza Cupertino. It features the distinctive square icon set of Faenza. Because it was originally based on Fedora and Ubuntu it has GNOME as window manager, giving the opportunity to change themes, including window frames.
It aimed for a 'classic' desktop experience, as opposed to a 'mobile' experience.


Device driver synthesis and verification

Device drivers are programs which allow software or higher-level computer programs to interact with a hardware device. These software components act as a link between the devices and the operating systems, communicating with each of these systems and executing commands. They provide an abstraction layer for the software above and also mediate the communication between the operating system kernel and the devices below.
Usually the operating systems comes with a support for the common device drivers and usually the hardware vendors provide the device driver for their hardware devices for most platforms. The aggressive scaling of the hardware devices and the complex software components has made the device driver development process cumbersome and complex. When the size and functionality of the drivers started increasing the device drivers became a key factor in defining the reliability of the system. This has created an incentive towards automatic synthesis and verification of device drivers. This article sheds some light into some approaches in synthesis and verification of device drivers.
Motivation for automatic driver synthesis and verification.
Device drivers are the principal failing component in most systems. The Berkeley Open Infrastructure for Network Computing (BOINC) project found that OS crashes are predominantly caused by poorly written device driver code. In Windows XP, drivers account for 85% of the reported failures. In the Linux kernel 2.4.1 device driver code accounts for about 70% of the code size. The driver fault can crash the whole system as it is running in the kernel mode. These findings resulted in various methodologies and techniques for verification of device drivers. An alternative was to develop techniques which can synthesize device drivers robustly. Less human interaction in the development process and proper specification of the device and operating systems can lead to more reliable drivers.
The other motivation for driver synthesis, is the large number of flavors of operating systems and device combinations. Each of these has its own set of input/output control and specifications which makes support of hardware devices on each of the operating systems difficult. So the ability to use a device with an operating system requires the availability of corresponding device driver combination. Hardware vendors usually supply the drivers for Windows, Linux and Mac OS but due to the high development or porting costs and technical support difficulties they are unable to provide drivers on all platforms. An automated synthesis technique can help the vendors in providing drivers to support any devices on any operating system.
Verification of Device Drivers.
There are two challenges that limit testing the device drivers.
The wave of verification of device drivers was initiated by Microsoft through their SLAM project as early as the year 2000. The motivation for the project was that 500,000 crashes reported a day were found to be caused by one video driver, leading to concern about the great vulnerability in using complex device drivers. More details can be found here, in the speech delivered by Bill Gates. A large number of static and runtime techniques have since been proposed for bug detection and isolation.
Static Analysis.
Static analysis means analyzing the program to check whether it complies with the safety-critical properties specified. For example, the system software should conform to rules such as "check user permissions before writing to kernel data structures", "don't reference null pointer without check", "prohibit overflowing buffer size" etc. Such checks can be made without actually executing the code being checked. Using the traditional testing process (dynamic execution) requires writing many test cases to exercise these paths and drive the system into error states. This process can take a long time and effort and is not a practical solution. Another theoretically possible approach is manual inspection, but this is impractical in modern systems in which millions of lines of code are involved, making the logic too complex to be analyzed by humans.
Compiler Techniques.
The rules that have a straightforward mapping to source code can be checked using a compiler. Rule violations can be found by checking if the source operation does not make sense. For example, rules like "enabling an interrupt after being disabled" can be checked by looking at the order of function calls. But if the source code type system cannot specify the rules in its semantics, then the compilers cannot catch errors of that kind. Many type-safe languages allow memory safety violations resulting from unsafe type casting to be detected by compiler.
Another approach is to use meta-level compilation (MC). Metacompilers constructed for this purpose may extend the compilers with lightweight, system specific checkers and optimizers. These extensions need to be written by system implementers in a high level language and dynamically linked to the compilers to do strict static analysis.
Software Model Checking.
Software model checking is the algorithmic analysis of programs to prove properties of their executions. This automates the reasoning about the program behavior with respect to the given correct specifications. Model checking and symbolic execution are used to verify the safety-critical properties of device drivers. The input to the model checker is the program and the temporal safety properties. The output is the proof that the program is correct or a demonstration that there exists a violation of the specification by means of a counterexample in the form of a specific execution path.
The tool SDV (Static Driver Verifier) from Microsoft uses static analysis for windows device drivers. The back end analysis engine SLAM used model checking and symbolic execution for compile time static verification. The rules that are to be observed by the drivers for each API are specified in a C like language SLIC (Specification Language for Interface Checking). The analysis engine finds all paths which can lead to violations of the API usage rules and are presented as source level error paths through the driver source code. Internally, it abstracts the C code into a boolean program and a set of predicates which are rules that are to be observed on this program. Then it uses the symbolic model checking to validate the predicates on the boolean program.
The model checker BLAST (Berkeley Lazy Abstraction Software verification Tool) is used to find memory safety and incorrect locking errors in Linux kernel code. It uses an abstraction algorithm called lazy abstraction to build the model from the driver C code. It has been successful in verifying temporal safety properties of C programs with up to 50K lines of code. It is also used to determine if a change in the source code affects the proof of property in the previous version and is demonstrated on a Windows device driver.
Avinux is another tool that facilitates the automatic analysis of Linux device drives and is built on top of bounded model checker CBMC. There exist fault localization methods to find the bug location as these model checking tools return a long counter example trace and it is hard to find the exact faulty location.
Run Time Analysis.
Dynamic program analysis is performed by running the program with sufficient test inputs to produce interesting behaviors. Safe Drive is a low overhead system for detecting and recovering from type safety violations in device drivers. With only 4% changes to the source code of Linux network drivers they were able to implement SafeDrive and give better protection and recovery to Linux kernel. A similar project using hardware to isolate the device drivers from the main kernel is Nook. They place device drivers in separate hardware protection domain called "nooks" and they have separate permission setting for each pages making sure that a driver does not modify pages which are not in its domain but can read all kernel data since they share the same address space.
Another similar work in this area is on automatic recovery of operating systems due to driver faults. MINIX 3 is an operating system which can isolate major faults, defects are detected and failing components are replaced on the fly.
Device driver Synthesis.
An alternative to verification and isolation of faults is to deploy techniques in device driver development process to make it more robust. Given a device specification and operating system functions, one method is to synthesize device driver for that device. This helps to reduce the human introduced errors as well as the cost and time involved in developing the system software. All the synthesis methods rely on some form of specification from the hardware device manufacturers and operating system functions.
Interface Specification Languages.
Hardware operating code is usually low level and is prone to errors. The code development engineer rely on the hardware documentation which typically contains imprecise or inaccurate information. There are several Interface Definition Languages (IDL) to express the hardware functionalities. The modern OSes uses these IDLs to glue components or to hide heterogeneity, like remote procedural call IDL. The same applies to hardware functionalities as well. In this section we discuss writing device drivers in domain specific languages which helps to abstract the low level coding and use specific compilers to generate the code.
Devil allows high level definition of the communication with the device. The hardware components are expressed as I/O ports and memory-mapped registers. These specifications are then converted to a set of C macros which can be called from the driver code and thus eliminates the error induced by programmer while writing low level functions. NDL is an enhancement to Devil, describing the driver in terms of its operational interface. It uses the Devil's interface definition syntax and includes set of register definitions, protocols for accessing those registers and a collection of device functions. Device functions are then translated into a series of operations on that interface. For a device driver generation, one have to first write the driver functionalities in these interface specification languages and then use a compiler which will generate the low level driver code.
HAIL (Hardware Access Interface Language) is another domain-specific device driver specification language. The driver developer needs to write the following.
The HAIL compiler takes these inputs and translates the specification into C code.
Hardware Software Co-design.
In hardware software co-design, the designer specifies the structure and behavior of the system using finite state machines which communicate among themselves. Then a series of testing, simulation and formal verification are done on these state machines before deciding which components go into the hardware and which of these into the software. The hardware is usually done in field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs), whereas the software part is translated into low-level programming language. This approach mostly applies in embedded systems which is defined as a collection of programmable parts that interact continuously with environment through sensors. Existing techniques are intended for generating simple micro-controllers and their drivers.
Standalone Driver Synthesis.
In the standalone synthesis both the device and the system software are done separately. The device is modeled using any Hardware Description Language (HDL) and the software developer does not have access to the HDL specifications. The hardware developers put forth the device interface in the data sheet for the device. From the data sheet, the driver developer extracts register and memory layout of the device and the behavioral model in the form of finite state machines. This is expressed in the domain specific languages described in the Interface language section. Final step involves generating the code from these specifications.
The tool Termite takes three specifications to generate the driver.
Given these specifications Termite will generate the driver implementation that translates any valid sequence of OS request into a sequence of device commands. Due to formal specification of the interfaces, Termite can generate the driver code which holds the safety and liveness properties.
Another very interesting hacking effort has been done by RevNIC, which generates a driver state machine by reverse engineering an existing driver to create inter-portable and safe drivers for new platforms. To reverse engineer a driver, it wiretaps the hardware I/O operations by executing the driver using symbolic and concrete executions. The output of the wiretap is fed to a synthesizer, which reconstructs a control flow graph of the original driver from these multiple traces along with the boilerplate template for the corresponding device class. Using these methods, the researchers have ported some Windows drivers for network interfaces to other Linux and embedded operating systems.
Criticism.
While many of the static analysis tools are widely used, many of the driver synthesis and verification tools have not seen widespread acceptance in practice. One of the reasons is that drivers tend to support multiple devices and the driver synthesis work usually generates one driver per device supported which can potentially lead to a large number of drivers. Another reason is drivers also do some processing and the state machine model of drivers cannot depict processing.
Conclusion.
The various verification and synthesis techniques surveyed in this article have their own advantages and disadvantages. For example, runtime fault isolation has performance overhead, whereas the static analysis does not cover all classes of errors. The complete automation of device driver synthesis is still in its early stages and has a promising future research direction. Progress will be facilitated if the many languages available today for interface specification can eventually consolidate into a single format, which is supported universally by device vendors and operating systems teams. The payoff from such a standardization effort could be the realization of completely automated synthesis of reliable device drivers in the future.


Westmere (microarchitecture)

Westmere (formerly Nehalem-C) is the code name given to the 32 nm die shrink of "Nehalem". While sharing the same CPU sockets, Westmere included Intel HD Graphics, while Nehalem did not.
The first "Westmere"-based processors were launched on January 7, 2010, by Intel Corporation.
The Westmere architecture has been available under the Intel brands of Core i3, Core i5, Core i7, Pentium, Celeron and Xeon.
Technology.
Westmere's feature improvements from Nehalem, as reported:
Roadmap.
The successor to "Nehalem" and "Westmere" is "Sandy Bridge".


CD (command)


Comparison of DOS operating systems

This article details versions of MS-DOS, IBM PC DOS, and at least partially compatible disk operating systems. It does not include the many other operating systems called "DOS" which are unrelated to IBM PC compatibles.
Historical and licensing information.
Originally MS-DOS was designed to be an operating system that could run on "any" computer with a 8086-family microprocessor. It competed with other operating systems written for such computers, such as CP/M-86 and UCSD Pascal. Each computer would have its own distinct hardware and its own version of MS-DOS, a situation similar to the one that existed for CP/M, with MS-DOS emulating the same solution as CP/M to adapt for different hardware platforms. So there were many different original equipment manufacturer (OEM) versions of "MS-DOS" for different hardware. But the greater speed attainable by direct control of hardware was of particular importance, especially when running computer games. So very soon an IBM-compatible architecture became the goal, and before long all 8086-family computers closely emulated IBM hardware, and only a single version of MS-DOS for a fixed hardware platform was all that was needed for the market. This specific version of MS-DOS is the version that is discussed here, as all other versions of MS-DOS died out with their respective systems. One version of such a "generic MS-DOS" (Z-DOS) is mentioned here, but there were dozens more. All these were for personal computers that used an 8086-family microprocessor, but which were not fully IBM PC compatible.


DSPXVBE.EXE


Arthur van Hoff

Arthur van Hoff (born 16 February 1963) is a Dutch computer scientist and businessman.
Biography.
After studying computer science at the University of Strathclyde and Hogere Informatica Opleiding, Van Hoff joined Sun Microsystems as an engineer with the Distributed Objects Everywhere team. In 1993, he joined the Java development team, writing the language's compiler and taking responsibility for its first release to Netscape in August 1995. In 1996, he left Sun, feeling that the options to develop Java outside of the organisation were "too tempting", and established the startup Marimba, serving as its Chief Technology Officer. At Marimba, Van Hoff led the engineering team in developing a pull technology-based software distribution system, Castanet.
In 2002, Van Hoff left Marimba, which was acquired by BMC Software for $240 million. He started Strangeberry, a startup that developed software to play computer-stored content on televisions. It was acquired by TiVo, Inc. in January 2004 and he joined TiVo as Principal Engineer. He resigned from TiVo in 2005 and later joined Flipboard as their Chief Technology Officer. He left Flipboard in November 2012 and started Jaunt Virtual Reality with co-founders Tom Annau and Jens Christensen. He currently serves as Chief Technology Officer of Jaunt, Inc., as well as the Entrepreneur-in-Residence of Redpoint Ventures.


Relocatable Object Module Format

The Relocatable Object Module Format (OMF) is an object file format used primarily for software intended to run on Intel 80x86 microprocessors. Version 4.0 was released by Intel in 1981 under the name "Object Module Format", and is perhaps best known to DOS users as an ".OBJ file". It has since been standardized by the Tool Interface Standards Committee.
File format.
Many object file formats consist of a set of tables, such as the relocation table, which are either stored on fixed positions in the file, like the a.out format, or are pointed to by the header, like the ELF format. The "sections", code, data area, etc., are stored as contiguous areas of bytes within such files.
The Relocatable Object Module Format, however, was designed to require minimal memory when linking, and consists of a series of records that have the following format:
There is a wide variety of record types because of consolidation of OMF variants from several vendors, and because of adding such features as 32-bit code and dynamic linking. These are important record types:
There is no header containing file offsets, such as a pointer to a symbol table, in the file; a linker must completely parse the object file to extract all the information.
In the OMF format the data of one section is not necessarily stored as contiguous bytes in the file, instead it "can" be represented by multiple records. The file format specification (version 1.1) says that this "must" be done for sections larger than 1 KiB. Records containing relocation information (fixups) must be stored immediately following the data records of the section they apply to, so the section data and the relocation information is "mixed" in the file.
The file format provides special records (LIDATA) that allow compression of repeating data sequences in an object file. It also provides the possibility to store the symbol name of the entry point of the later executable file in one object file.
The file format can also be used as library file format.
Use.
The file format is the most important object file format under DOS, 16-bit Windows, and 16-bit and 32-bit OS/2.
Few toolchains use the 32-bit version of the OMF format. For example, the Watcom C toolchain allows generating code for targets that use 32-bit segmented memory layouts; Iron Spring PL/I can generate code for OS/2 32-bit flat memory layouts.
The Embarcadero Delphi compiler used this format when generating codice_2 files for C++. It was the only format of object files that could be linked to a program or unit written in Object Pascal prior to version XE2 of Delphi, which introduced support of COFF format, along with 64-bit Windows target.


Ututo

Ututo is a Linux distribution consisting entirely of free software. The distribution is named for a variety of gecko found in northern Argentina.
Ututo was the first fully free Linux-based system recognized by the GNU Project. The founder of the GNU Project, Richard Stallman, formerly endorsed the distribution nearly exclusively, and used it on his personal computer, before he switched to gNewSense, and later Trisquel.
History.
Ututo was first released in 2000 by Diego Saravia in National University of Salta. Argentina. It was one of the first live CD distributions in the world and the first Linux distribution in Argentina. Ututo carried Simusol, a system to simulate Solar Energy projects. Ututo was simple to install, because it did not need any configuration. It automatically detected the hardware in the machine, it only asked to "move your mouse". At that time no other distribution worked that way.
In 2002, Ututo-R was created, which offered the possibility of operating like a software router. This version was created by Marcos Zapata and used in Buenos Aires public schools.
In 2004, the Ututo-e project was born, swiftly becoming the most important derivative of Ututo. This project was started by Daniel Olivera.
In 2006, Ututo was declared "of National Interest" by the Argentine Chamber of Deputies.
Ututo XS.
Ututo XS is the current stable version of Ututo.
Ututo XS is compiled using Gentoo Linux "ebuilds" and "emerge" software. All documentation is in Spanish.
With the emergence of the XS series, many new features were added, including a faster system installer. Ututo has been used in different hardware projects such as iFreeTablet. Pablo Manuel Rizzo designed the package management system, Ututo-Get, modelled after Debian's APT; however, as other Gentoo-based distros, Ututo is compatible with Portage.
Ututo has different binaries optimized for different Intel and AMD processors .
With no releases since 2012 the distribution is considered "dormant".
Ututo UL.
Ututo UL (or Ubuntu-Libre) is the current developed version of Ututo. Ututo UL utilize Ubuntu as the distro base, with all nonfree software removed as usual in the Ututo project, and Linux-libre as the kernel.
In 2017 the original idea of distributing Simusol, a system to simulate Solar Energy projects, returned to the heart of the project.
Reception.
Tux Machines reviewed Utoto in 2006:


Intel Atom

Intel Atom is the brand name for a line of IA-32 and x86-64 instruction set ultra-low-voltage microprocessors by Intel Corporation designed to reduce electric consumption and power dissipation in comparison with ordinary processors of the Intel Core series. Atom is mainly used in netbooks, nettops, embedded applications ranging from health care to advanced robotics, and mobile Internet devices (MIDs). The line was originally designed in 45 nm complementary metal–oxide–semiconductor (CMOS) technology and subsequent models, codenamed "Cedar", used a 32 nm process.
The first generation of Atom processors are based on the Bonnell microarchitecture. On December 21, 2009, Intel announced the "Pine Trail" platform, including new Atom processor code-named "Pineview" (Atom N450), with total kit power consumption down 20%. On December 28, 2011, Intel updated the Atom line with the "Cedar" processors.
In December 2012, Intel launched the 64-bit "Centerton" family of Atom CPUs, designed specifically for use in servers. "Centerton" adds features previously unavailable in Atom processors, such as Intel VT virtualization technology and support for ECC memory. On September 4, 2013 Intel launched a 22 nm successor to "Centerton", codenamed "Avoton".
In 2012, Intel announced a new system on chip (SoC) platform designed for smartphones and tablets which would use the Atom line of CPUs. It was a continuation of the partnership announced by Intel and Google on September 13, 2011 to provide support for the Android operating system on Intel x86 processors. This range competed with existing SoCs developed for the smartphone and tablet market from companies like Texas Instruments, Nvidia, Qualcomm and Samsung.
On April 29, 2016, Intel announced the decision to cancel the Broxton SoC for smartphones and tablets. Broxton was to use the newest Atom microarchitecture (Goldmont on a 14 nm node) in combination with an Intel modem. Apollo Lake, announced early the same month for low-cost entry PCs, will continue using Atom cores.
History.
Intel Atom is a direct successor of the Intel A100 and A110 low-power microprocessors (code-named Stealey), which were built on a 90 nm process, had 512 kB L2 cache and ran at 600 MHz/800 MHz with 3 W TDP (Thermal Design Power). Prior to the Silverthorne announcement, outside sources had speculated that Atom would compete with AMD's Geode system-on-a-chip processors, used by the One Laptop per Child (OLPC) project, and other cost and power sensitive applications for x86 processors. However, Intel revealed on October 15, 2007 that it was developing another new mobile processor, codenamed Diamondville, for OLPC-type devices.
"Atom" was the name under which Silverthorne would be sold, while the supporting chipset formerly code-named Menlow was called Centrino Atom.
At Spring Intel Developer Forum (IDF) 2008 in Shanghai, Intel officially announced that Silverthorne and Diamondville are based on the same microarchitecture. Silverthorne would be called the Atom Z5xx series and Diamondville would be called the Atom N2xx series. The more expensive lower-power Silverthorne parts was to be used in Intel mobile Internet devices (MIDs) whereas Diamondville was to be used in low-cost desktop and notebooks. Several Mini-ITX motherboard samples have also been revealed. Intel and Lenovo also jointly announced an Atom powered MID called the IdeaPad U8.
In April 2008, a MID development kit was announced by Sophia Systems and the first board called CoreExpress-ECO was revealed by a German company LiPPERT Embedded Computers, GmbH. Intel offers Atom based motherboards.
In December 2012, Intel released Atom for servers, the S1200 series. The primary difference between these processors and all prior versions, is that ECC memory support has been added, enabling the use of the Atom in mission-critical server environments that demand redundancy and memory failure protection.
Availability.
Atom processors became available to system manufacturers in 2008. Because they are soldered onto a mainboard, like northbridges and southbridges, Atom processors are not available to home users or system builders as separate processors, although they may be obtained preinstalled on some ITX motherboards. The Diamondville and Pineview Atom is used in the HP Mini Series, Asus N10, Lenovo IdeaPad S10, Acer Aspire One & Packard Bell's "dot" (ZG5), recent ASUS Eee PC systems, Sony VAIO M-series, AMtek Elego, Dell Inspiron Mini Series, Gigabyte M912, LG X Series, Samsung NC10, Sylvania g Netbook Meso, Toshiba NB series (100, 200, 205, 255, 300, 500, 505), MSI Wind PC netbooks, RedFox Wizbook 1020i, Sony Vaio X Series, Zenith Z-Book, a range of Aleutia desktops, Magic W3, Archos and the ICP-DAS LP-8381-Atom. The Pineview line is also used in multiple AAC devices for the disabled individual who is unable to speak and the AAC device assists the user in everyday communication with dedicated speech software.
Marketing.
Intel has applied the Atom branding to product lines targeting several different market segments, including: MID/UMPC/Smartphone, Netbook/Nettop, Tablet, Embedded, Wireless Base Stations (for 5G networking infrastructure), Microserver/Server and Consumer electronics.
Consumer electronics.
Intel consumer electronic (CE) SoCs are marketed under the Atom brand. Prior to application of the Atom brand, there were number of Intel CE SoCs including: Olo River (CE 2110 which had an XScale ARM architecture) and Canmore (CE 3100 which like Stealey and Tolapai had a 90 nm Pentium M microarchitecture). Intel Atom CE branded SoCs include: Sodaville, Groveland, and Berryville.
Architecture.
Instruction set architecture.
32-bit and 64-bit hardware support.
All Atom processors implement the x86 (IA-32) instruction set; however, support for the AMD 64 instruction set was not added until the desktop "Diamondville" and desktop and mobile "Pineview" cores. The Atom N2xx and Z5xx series Atom models cannot run x86-64 code. The "Centerton" server processors will support the Intel 64 instruction set.
Intel 64 software support.
Intel states the Atom supports 64-bit operation only "with a processor, chipset, BIOS" that all support Intel 64. Those Atom systems not supporting all of these cannot enable Intel 64. As a result, the ability of an Atom-based system to run 64-bit versions of operating systems may vary from one motherboard to another. Online retailer mini-itx.com has tested Atom-based motherboards made by Intel and Jetway, and while they were able to install 64-bit versions of Linux on Intel-branded motherboards with D2700 (Cedarview; supports maximum of 4 GB memory DDR3-800/1066) processors, Intel 64 support was not enabled on a Jetway-branded motherboard with a D2550 (Cedarview) processor.
Even among Atom-based systems which have Intel 64 enabled, not all are able to run 64-bit versions of Microsoft Windows. For those "Pineview" processors which support 64-bit operation, Intel Download Center currently provides 64-bit Windows Vista and Windows 7 drivers for Intel GMA 3150 graphics, found in "Pineview" processors. However, no 64-bit Windows drivers are available for Intel Atom "Cedarview" processors, released Q3 2011. However, Intel's Bay Trail-M processors, built on the Silvermont microarchitecture and released in the second half of 2013, regain 64-bit support, although driver support for Linux and Windows 7 is limited at launch.
The lack of 64-bit Windows support for "Cedarview" processors appears to be due to a driver issue. A member of the Intel Enthusiast Team has stated in a series of posts on enthusiast site Tom's Hardware that while the Atom D2700 (Cedarview) was designed with Intel 64 support, due to a "limitation of the board" Intel had pulled their previously-available 64-bit drivers for Windows 7 and would not provide any further 64-bit support. Some system manufacturers have similarly stated that their motherboards with Atom Cedarview processors lack 64-bit support due to a "lack of Intel® 64-bit VGA driver support". Because all "Cedarview" processors use the same Intel GMA 3600 or 3650 graphics as the D2700, this indicates that Atom Cedarview systems will remain unable to run 64-bit versions of Windows, even those which have Intel 64 enabled and are able to run 64-bit versions of Linux.
Microarchitecture.
The first Atom processors were based on the "Bonnell" microarchitecture.
Those Atom processors are able to execute up to two instructions per cycle. Like many other x86 microprocessors, they translate x86-instructions (CISC instructions) into simpler internal operations (sometimes referred to as micro-ops, i.e., effectively RISC style instructions) prior to execution. The majority of instructions produce one micro-op when translated, with around 4% of instructions used in typical programs producing multiple micro-ops. The number of instructions that produce more than one micro-op is significantly fewer than the P6 and NetBurst microarchitectures. In the Bonnell microarchitecture, internal micro-ops can contain both a memory load and a memory store in connection with an ALU operation, thus being more similar to the x86 level and more powerful than the micro-ops used in previous designs. This enables relatively good performance with only two integer ALUs, and without any instruction reordering, speculative execution, or register renaming. The Bonnell microarchitecture therefore represents a partial revival of the principles used in earlier Intel designs such as P5 and the i486, with the sole purpose of enhancing the performance per watt ratio. However, Hyper-Threading is implemented in an easy (i.e., low power) way to employ the whole pipeline efficiently by avoiding typical single thread dependencies.
Atom branded processors have historically featured the following microarchitectures:
Performance.
The performance of a single-core Atom is about half that of a Pentium M of the same clock rate. For example, the Atom N270 (1.60 GHz) found in many netbooks such as the Eee PC can deliver around 3300 MIPS and 2.1 GFLOPS in standard benchmarks, compared to 7400 MIPS and 3.9 GFLOPS for the similarly clocked (1.73 GHz) Pentium M 740.
The Pineview platform has proven to be only slightly faster than the previous Diamondville platform. This is because the Pineview platform uses the same Bonnell execution core as Diamondville and is connected to the memory controller via the FSB, hence memory latency and performance in CPU-intensive applications are minimally improved.
Collaborations.
In March 2009, Intel announced that it would be collaborating with TSMC for the production of the Atom processors. The deal was put on hold due to lack of demand in 2010.
On September 13, 2011 Intel and Google held a joint announcement of a partnership to provide support in Google's Android operating system for Intel processors (beginning with the Atom). This would allow Intel to supply chips for the growing smartphone and tablet market.
Competition.
Embedded processors based on the ARM version 7 instruction set architecture (such as Nvidia's Tegra 3 series, TI's 4 series and Freescale's i.MX51 based on the Cortex-A8 core, or the Qualcomm Snapdragon and Marvell Armada 500/600 based on custom ARMv7 implementations) offer similar performance to the low end Atom chipsets but at roughly one quarter the power consumption, and (like most ARM systems) as a single integrated system on a chip, rather than a two chip solution like the current Atom line. Although the second-generation Atom codenamed "Pineview" should greatly increase its competitiveness in performance/watt, ARM plans to counter the threat with the multi-core capable Cortex-A9 core as used in Nvidia's Tegra 2/3, TI's OMAP 4 series, and Qualcomm's next-generation Snapdragon series, among others.
The Nano and Nano Dual-Core series from VIA is slightly above the average thermal envelope of the Atom, but offers hardware AES support, random number generators, and out-of-order execution. Performance comparisons of the Intel Atom against the Via Nano indicate that a single core Intel Atom is easily outperformed by the Via Nano which is in turn outperformed by a dual core Intel Atom 330 in tests where multithreading is used. The Core 2 Duo SU7300 outperforms the dual-core Nano.
The Xcore86 (also known as the PMX 1000) is x586 based System on Chip (SoC) that offers a below average thermal envelope compared to the Atom.
In 2014, Kenton Williston of EE Times said that while Atom will not displace ARM from its current markets, the ability to apply the PC architecture into smaller, cheaper and lower power form factors will open up new markets for Intel.
In 2014, ARM claimed that Intel's Atom processors offer less compatibility and lower performance than their chips when running Android, and higher power consumption and less battery life for the same tasks under both Android and Windows.
Issues.
In February 2017 Cisco Systems reported a clock signal issue that would disable several of its products. Cisco stated, "we expect product failures to increase over the years, beginning after the unit has been in operation for approximately 18 months". Soon after, The Register broke the news that this issue was linked to the Intel Atom SoC, and reports of other vendors being affected started appearing online.


ECHO (command)


Loop device

In Unix-like operating systems, a loop device, vnd (vnode disk), or lofi (loop file interface) is a pseudo-device that makes a computer file accessible as a block device.
Before use, a loop device must be connected to an extant file in the file system. The association provides the user with an application programming interface (API) that allows the file to be used in place of a block special file (cf. device file system). Thus, if the file contains an entire file system, the file may then be mounted as if it were a disk device.
Files of this kind are often used for CD ISO images and floppy disk images. Mounting a file containing a file system via such a loop mount makes the files within that file system accessible. They appear in the mount point directory.
A loop device may allow some kind of data elaboration during this redirection. For example, the device may be the unencrypted version of an encrypted file. In such a case, the file associated with a loop device may be another pseudo-device. This is mostly useful when this device contains an encrypted file system. If supported, the loop device is in this case the decrypted version of the original encrypted file and can therefore be mounted as if it were a normal file system.
Uses of loop mounting.
After mounting a file that holds a file system, the files in that system can be accessed through the usual file system interface of the operating system, without any need for special functionality, such as reading and writing to ISO images, in applications.
Loop mounting has several uses. It is a convenient method for managing and editing file system images offline, that are later used for normal system operation. This includes CD or DVD images or installation systems. It may be used to install an operating system onto a file system without repartitioning a disk. It also provides a permanent segregation of data, for example, when simulating removable media on a faster and more convenient hard disk or encapsulating encrypted file system.
Availability.
Various Unix-like operating systems provide the loop device functionality using different names.
In Linux, device names are encoded in the symbol table entries of their corresponding device drivers. The device is called a "loop" device and device nodes are usually named "/dev/loop0", "/dev/loop1", etc. They can be created with makedev for the static device directory, dynamically by the facilities of the device file system (udev), or directly with mknod. The management user interface for the loop device is "losetup", which is part of the package util-linux.
Sometimes, the loop device is erroneously referred to as loopback device, but this term is reserved for a networking device in operating systems. The concept of the "loop" device is distinct.
In BSD-derived systems, such as NetBSD and OpenBSD, the loop device is called "virtual node device" or "vnd", and generally located at "/dev/vnd0", "/dev/rvnd0" or "/dev/svnd0", etc., in the file system. The program "vnconfig" is used for configuration.
FreeBSD followed the same conventions as other BSD systems until release version 5, in which the loop device was incorporated into the memory disk driver ("md"). Configuration is now performed using the utility "mdconfig".
In Solaris/OpenSolaris, the loop device is called "loopback file interface" or lofi, and located at "/dev/lofi/1", etc. SunOS has the configuration program "lofiadm". "lofi" supports read-only compression and read-write encryption. Available is also a 3rd-party driver "fbk" ("File emulates Blockdevice"), for SunOS/Solaris since summer 1988.
UnixWare includes a dynamically loadable device driver "marry"(7) and the utility "marry"(1M). The marry driver allows a regular file to be treated as a device. The regular file can be accessed through either a block device, "/dev/marry/regfile", or as a character device, "/dev/marry/rregfile". The command "marry" also supports encrypting and decrypting of the regular file.
MacOS implements a native image mounting mechanism as part of its random access disk device abstraction. The command "hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount <filename>" causes a block device to appear in "/dev" as a regular disk device and subdevices for recognized partitions. Reads from and writes to those devices are sent to a user-mode helper process, which reads the data from the file or writes it to the file. In the user interface it is automatically activated by opening the disk image. MacOS can handle disk (.dmg or .iso), CD-ROM or DVD images in various formats.
Loop mounting was not available on Microsoft Windows operating systems until , where this functionality is natively implemented, and available through the diskpart utility. However, the facility is often added using third-party applications such as "Daemon Tools" and "Alcohol 120%". Freely-available tools from VMware (Disk Mount Utility) and LTR Data (ImDisk) can also be used to achieve similar functionality. Under Windows XP and Vista it is also possible to use the virtual hard disk feature by adding some component from Microsoft Virtual Server 2005 R2.
In A2, formerly AOS then Bluebottle, a file-based virtual disk is created with "VirtualDisks.Create". A file system can be installed in such a "disk" with "VirtualDisks.Install".
Example.
Mounting a file containing a disk image on a directory requires two steps:
These two operations can be performed either using two separate commands, or through special flags to the mount command. The first operation may be performed by programs such as "losetup" in Linux, or "lofiadm" in SunOS. As an example, if codice_1 is a regular file containing a file system and codice_2 is a Linux user's directory, the superuser (root) may mount the file on the directory by executing the following two commands:
 losetup /dev/loop0 example.img
 mount /dev/loop0 /home/you/dir
The second command mounts the device on the directory codice_2. The overall effect of executing these two commands is that the content of the file is used as a file system rooted at the mount point.
To identify an available loop device for use in the above commands, the superuser (root) can use:
 losetup -f
The mount utility is usually capable of handling the entire procedure:
 mount -o loop example.img /home/you/dir
The device can then be unmounted with the following command:
 umount /home/you/dir
 # or, after finding the associated loop number by e.g. mount | grep "/home/you/dir"
 # or losetup -a | grep example.img
 umount /dev/loop<N>
At a lower level application programming interface (API), the association and disassociation of a file with a loop device is performed with the ioctl system call on a loop device.


Ariel the Little Mermaid

Disney's Ariel the Little Mermaid, usually shorted to simply Ariel the Little Mermaid, is a 1992 video game developed by Blue Sky Software for the Sega Genesis, Game Gear and Master System, based on the 1989 film "The Little Mermaid."
A Master System version was released exclusively in Brazil by Tec Toy.
Gameplay and plot.
Despite being based on the 1989 film, the game's plot bears little resemblance to it. The player guides Ariel or King Triton through underwater levels similarly to the game "Ecco the Dolphin", and can move in any direction. Gameplay is identical regardless of character choice, and both feature two attacks for defeating enemies - a "normal" and a "special". Supporting characters from the film such as Flounder and Sebastian make appearances, and can aid the player in their quest.
There are a total of five stages, four of them regular. Each features a boss fight at the end, with the final boss being Ursula.
Reception.
The Genesis version of Ariel the Little Mermaid has received mixed to negative reviews. "AllGame" gave the game a somewhat positive review, stating a young child may enjoy it, but older or more skilled players should stick to more challenging/overall better Disney games, recommending titles "Aladdin" and "The Lion King".


List of Intel Core 2 microprocessors

The Core 2 brand refers to Intel's x86 and x86-64 microprocessors with the Core microarchitecture made for the consumer and business markets (except servers) above Pentium. The Core 2 solo branch covered single-core CPUs for notebook computers, Core 2 Duo – dual-core CPUs for desktop and notebook computers, Core 2 Quad – quad-core CPUs for desktop and notebook computers, and Core 2 Extreme – dual-core and quad-core CPUs for desktop and notebook computers.
Desktop processors.
Dual-Core Desktop processors.
Core 2 Duo.
"Allendale" (65 nm, 800 MT/s).
Note: The M0 and G0 Steppings have better optimizations to lower idle power consumption from 12W to 8W.
Note: The E4700 uses G0 Stepping which makes it a Conroe CPU.
"Conroe" (65 nm, 1066 MT/s).
Note: of the E6000 series processors, only models E6550, E6750, and E6850 support Intel's Trusted Execution Technology (TXT).
Note: The L2 Stepping, and models with sSpec SL9ZL, SL9ZF, SLA4U, SLA4T, have better optimizations to lower idle power consumption from 22W to 12W.
Note: The M0 and G0 Steppings have better optimizations to lower idle power consumption from 12W to 8W.
"Conroe" (65 nm, 1333 MT/s).
Note: of the E6000 series processors, only models E6550, E6750, and E6850 support Intel's Trusted Execution Technology (TXT).
Note: The L2 Stepping, and models with sSpec SL9ZL, SL9ZF, SLA4U, SLA4T, have better optimizations to lower idle power consumption from 22W to 12W.
Note: The M0 and G0 Steppings have better optimizations to lower idle power consumption from 12W to 8W.
"Wolfdale" (45 nm, 1333 MT/s).
Note: The E8190 and E8290 do not support Intel VT-d.
See also: Versions of the same Wolfdale core in an LGA 771 are available under the Dual-Core Xeon brand.
Core 2 Extreme.
"Conroe XE" (65 nm).
"These models feature an unlocked clock multiplier"
Quad-Core Desktop processors.
Core 2 Quad.
"Yorkfield-6M" (45 nm).
Note: Q8200, Q8200S, Q8300 SLB5W does not support Intel VT-x.
Note: Q8200, Q8200S, Q8300, Q8400, Q8400S, Q9500 does not support Intel VT-d.
Note: Q8200, Q8200S, Q8300, Q8400, Q8400S does not support TXT.
Core 2 Extreme.
"Kentsfield XE" (65 nm).
"These models feature an unlocked clock multiplier"
Notebook (mobile) processors.
Dual-Core Notebook processors.
Core 2 Duo.
"Merom", "Merom-2M" (standard-voltage, 65 nm).
See also: Versions of the same Merom-2M core with half the L2 cache disabled are available under the Pentium Dual-Core brand.
"Penryn", "Penryn-3M" (standard-voltage, 45 nm).
Note that models T8100, T8300, T9300, T9500 are Penryn processors designed for Santa Rosa Refresh platforms with maximum FSB of 800 MT/s, whereas the rest of the Penryn processors are designed for Montevina platforms that can go up to maximum FSB of 1066 MT/s.
Penryn processors support Dynamic Front Side Bus Throttling between 400–800MT/s.
Core 2 Extreme.
"Merom XE" (65 nm).
"These models feature an unlocked clock multiplier"
Quad-Core Notebook processors.
Core 2 Quad.
"Penryn QC" (45 nm).


Bomberman (2006 video game)

 is a video game developed by Hudson Soft for the PlayStation Portable handheld console. It was released in Japan in July 2006, in North America in September 2006, and in PAL regions in February 2007. It was initially released as simply "Bomberman" outside Japan, but later released in North America as "Bomberman Legacy".
Gameplay.
Players must navigate a series of levels, defeating enemies by blowing them up with Bomberman's infinite supply of bombs. Unlike previous games, power-ups are added to an inventory to be used when the player wishes, rather than activated immediately upon collection. Power-ups in the player's inventory are carried over should the player lose a life, but those which have been used have their effects canceled. A total of 18 different power-ups are available in the game.


UKUUG

UKUUG is the UK's Unix and Open Systems User Group a non-profit organization and technical forum for the advocacy of open systems, particularly Unix and Unix-like operating systems, the promotion of Free and Open Source Software (FOSS), and the advancement of open programming standards and networking protocols.
In 2010 the name has been changed to "FLOSS UK", along with a change of web domain.


Harvest Moon 64

Harvest Moon 64, released in Japan as , is a farm simulation video game developed and published by Victor Interactive Software for the Nintendo 64 video game console, and the third game in the "Story of Seasons" series (following "Harvest Moon GB"). It was released in Japan on February 5, 1999, and in North America by Natsume on December 22, 1999.
Natsume initially stated bringing it to Wii U Virtual Console was not possible due to technical issues, despite the Wii proving the task to be possible through homebrew emulation. However, in celebration of the series' twentieth anniversary, the game saw release on the Wii U Virtual Console on February 23, 2017. This also marked the game's debut in the PAL regions (the original had been cancelled due to time constraints), as well as the game's first official re-release (as well as the first time digital) in nearly two decades.
Gameplay.
The objective of "Harvest Moon 64" is to restore and maintain an abandoned farm left to the player by their grandfather. Along with restoring the farm, there are a number of other side quests that the player may choose to partake in, including training and racing a horse, selling crops, participating in a variety of town festivals, falling in love and getting married, collecting recipes, and collecting photographs from various achievements and events.
The player starts out with the bare minimum features for the farm, including an empty chicken coop and barn, but animals and house extensions can be purchased and tools can be upgraded over the course of the game. The local town, where most of the villagers spend their day, contains a church, a bar, a bakery, a town square, a flower shop, a library, a tool shop, among other things.
Unlike the original "Harvest Moon" for the SNES, there is a limited amount of time to work in any given day as well as a limited amount of stamina for work. Many game features, such as character locations and which shops are open, vary depending on the current time and day of the week. There are four seasons per year, each with its own weather patterns, crops to grow, and wild herbs available. Some days are reserved for festivals, where every shop is closed and special events take place. This offers a break from daily chores and a chance to interact with the townsfolk in unique ways, such as dancing or swimming.
Planting, growing, and harvesting crops is one of the main focuses of the "Story of Seasons" series. The crops available to plant include turnips, potatoes, corn, and strawberries, and they can be purchased in the village during their respective season. To plant crops, the player must till the soil, plant the seeds, then water the plots. Several crops will yield multiple vegetables throughout the season if continually watered. When the season ends and a new begins, all crops from the previous season will wither and must be cut down. Alternatively, a greenhouse can be built so that any plant can grow anytime during the year.
Along with crops planted on the farm, there are also wild growing plants and herbs that the player may pick as he goes through his daily chores. The wild growing plants also change from season to season and reappear each day. Though all wild plants are edible, some can cause sickness while others prevent it.
The player starts with five basic tools to help restore the farm: a hammer, an axe, a sickle, a hoe, and a watering can. After a certain amount of usage, a tool will automatically upgrade (signified when the tool becomes silver and then later gold), allowing the player to do more work faster using less energy. Tools for livestock such as a cow milker and an animal brush can be purchased in the village.
Taking care of animals is an essential part of maintaining the farm. Livestock, such as cows, sheep, and chickens, may be purchased at a nearby ranch. These animals require food and care, and if left unfed or left outside in the rain, it will become sick and eventually die unless the player gives it medicine. If the animals are treated well, the products they give will increase in quality.
The player can own a dog and a horse. The dog originally belonged to the player character's grandfather and is a throwback to the original "Harvest Moon". A horse can be obtained by visiting the nearby ranch, and can be ridden or used as a portable shipping crate. Both the dog and the horse can compete in yearly races, where their performance is largely determined by their relationship with the player.
One of the other major features of "Harvest Moon 64" is the ability to marry and have a child. There are five eligible girls in "Harvest Moon 64", represented by hearts that appear in their dialogue boxes, representative of her affection toward the player, ranging from white (indifferent) to pink (in love). Each of these girls has a non-player character suitor that will eventually marry her if the player chooses to marry another girl or chooses not to pursue anyone.
The game features a series of collectable items. When the player reaches a certain milestone or achieves one of several goals, they will receive a photograph in the mail to remember the event. Earned photographs are available for viewing at any time by checking the photo album on the bedside table and are a way to track a player's success in the game.
Reception.
Many reviews claim that although "Harvest Moon 64" has a repetitive soundtrack and often glitchy visual displays, the game's captivating and unique gameplay make up for it.
Aaron Boulding, who rated "Harvest Moon 64" for IGN, rated the game at 8.2 out of 10, or "great", stating that "(he) was able to forgive a lot of shortcomings like poor audio and visual elements because (he) found (himself) playing it for hours at a time."
Joe Fielder, who rated it for GameSpot, gave it 7.3 out of 10 and claimed that "although not for everyone, "Harvest Moon 64" is a strangely compelling, original little game that makes hours melt away incomprehensibly."
Mars Publishing's "Parent's Guide to Nintendo Games" gave "Harvest Moon 64" the only Parent's Guide Choice Award for a Nintendo 64 game because it met the requirements of a game that "displays imagination, creativity, ingenuity of the first order, while offering a playing atmosphere that is educational and enriching."
"Nintendo Power" ranked "Harvest Moon 64" as the 278th greatest Nintendo game of all time.


List of AMD Duron microprocessors


List of Intel Core M processors

Intel Core M is a family of ultra low-voltage microprocessors belonging to the Intel Core series and designed specifically for ultra-thin notebooks, 2-in-1 detachables, and other mobile devices. The thermal design power (TDP) of all Core M microprocessors is 5 watts or lower. Intel Core M microprocessors are fanless due to their low TDP.
Kaby Lake microarchitecture (7th/8th generation).
"Kaby Lake-Y" (SoC, dual-core, 14 nm).
Core m5 and Core m7 models were rebranded as Core i5 and Core i7.


IBMBIO.SYS


Java processor

A Java processor is the implementation of the Java virtual machine (JVM) in hardware. In other words, the Java bytecode that makes up the instruction set of the abstract machine becomes the instruction set of a concrete machine. These are the most popular form of a high-level language computer architecture today.
Implementations.
There are many Java processors available, including:


CrunchBang Linux

CrunchBang Linux (abbreviated #!) was a Linux distribution derived from Debian by Philip Newborough (who is more commonly known by his username, corenominal).
CrunchBang was designed to use comparatively few system resources. Instead of a desktop environment it used a customized implementation of the Openbox window manager. Many of its preinstalled applications used the GTK+ widget toolkit.
CrunchBang had its own software repository but drew the vast majority of packages from Debian's repositories.
Philip Newborough announced on 6 February 2015 that he had stopped developing CrunchBang and that users would benefit from using vanilla Debian. Some Linux distributions have arisen in its place in an effort to continue its environment. Among the most significant are BunsenLabs and CrunchBang++.
Editions.
CrunchBang Linux provided an Openbox version for i686, i486 and amd64 architectures. Until October 2010 there also was a "Lite" version with fewer installed applications. The "Lite" version was effectively discontinued after the distribution on which it was based – Ubuntu 9.04 – reached its end-of-life and CrunchBang prepared to switch to a different base system.
CrunchBang 10, made available in February 2011, was the first version based on Debian. The final version, CrunchBang 11, was made available on 6 May 2013.
Each CrunchBang Linux release was given a version number as well as a code name, using a name of a "Muppet Show" character. The first letter of the code name was the first letter of the upstream Debian release (previously Debian Squeeze and CrunchBang Statler and currently Debian Wheezy and CrunchBang Waldorf).
Reception.
In May 2013 Jim Lynch of desktoplinuxreviews.com reviewed CrunchBang 11:
Successors.
Newborough announced in February 2015 that he was abandoning further development of CrunchBang Linux, feeling that it no longer served a purpose. The users did not all agree, and a number proceeded to develop successor distributions BunsenLabs, CrunchBang++ (#!++) and CrunchBang-Monara.
BunsenLabs.
BunsenLabs Linux is a community-organized successor to Crunchbang. It is based on the Debian 10 (Buster) stable release. Between 17 and 30 September 2015, CrunchBang's domain began redirecting to BunsenLabs.
BunsenLabs is one of the few modern Debian-based live distributions that still offers a CD edition supporting 32-bit systems, with both the X Window System and a modern version of Firefox, making the distro useful for running on old computers with just around 1 GB of RAM.
The latest version, based on Debian 10, was released on 2 August 2020.
CrunchBang++.
CrunchBang PlusPlus (#!++) was developed in response to Newborough's announcement of the end of CrunchBang. It is currently based on the Debian Buster (release 10.1) distribution. Release 1.0 was announced on 29 April 2015. The latest version based on Debian 10.0 was released on 8 July 2019.
CrunchBang-Monara.
CrunchBang-Monara is another successor to CrunchBang. It is based on the Debian 8 stable release.


Flying Dragon

Flying Dragon, known in Japan as , is a fighting game with role-playing video game elements that was developed by Culture Brain and released for the Nintendo 64 in 1998. Part of the "Hiryū no Ken" series, it was published in Japan by Culture Brain, and by Natsume in North America and Europe.
Its most notable feature was the game's SD mode that featured a character progression system, in which characters advance in levels as they become more experienced, and in which it is possible to collect credits and treasure items to equip characters with. The game received relatively low scores on specialized reviews at the time of its release. It had a sequel a year later, titled "S.D. Hiryu no Ken Densetsu".
"" is also the name of a NES game released by Culture Brain in 1989, which is part of the same series.
Characters.
The game consists of two different fighting modes, though the two share many common characters.
"S.D. Hiryu no Ken Densetsu".
An updated version of the game, entitled , was released in Japan only, adding more characters (such as Jack, Ryu, and Gofire from the "Super Chinese" series), items and a new gameplay mode. It also removed the more realistic "Virtual Mode", favoring the super deformed "Quest Mode".
Playable characters are Ryuhi, Hayato, Min Min, Wiler, Shouryu, Yuka, Suzaku, Powers, Robo No Hana, Bokuchin (unlockable), Jack, Ryu, Raima, E. Quaker, Ellie, Gofire, Ryumaou (unlockable).


Bodhi Linux

Bodhi Linux is a light-weight Linux distribution based on Ubuntu that uses the Moksha window manager. The philosophy for the distribution is to provide a minimal base system so that users can populate it with the software they want. Thus, by default it only includes software that is essential to most Linux users, including a file browser (PCManFM), a web browser (GNOME Web) and a terminal emulator (Terminology). It does not include software or features that its developers deem unnecessary. To make populating systems with software easy, Bodhi Linux developers maintain an online database of lightweight software that can be installed in one click via apturl.
In addition to the standard version of Bodhi Linux, which is for Intel-compatible processors, there was an alpha release version for tablet devices with ARM processors, based on Debian. The tablet device version of Bodhi is not officially supported anymore, because of the amount of time needed to keep it up to date. Package and image updates will rarely be made, if at all, in the future.
Performance.
System requirements include 512 MB RAM, 5 GB hard disk space, and a 500 MHz processor. 32-bit processors without PAE capability are supported on same terms as PAE-enabled ones. Only difference between the Bodhi versions is that an older kernel is used.
By using an Enlightenment DR17-based fork called Moksha Desktop, Bodhi provides rich desktop effects and animations that do not require high end computer hardware. The rationale for forking the project from DR17 was due to its established performance & functionality while E19 possessed "optimizations that break existing features users enjoy and use" as per Jeff Hoogland's statement. The Enlightenment window manager, as well as the tools developed specifically for Bodhi Linux, were written in C programming language and Python.
Support.
Bodhi Linux is derived from the Ubuntu long term support releases (14.04, 16.04, 18.04...), so support follows the same pattern: Security bug fixes are released on a daily basis throughout the five-year period. As opposed to Ubuntu, Bodhi has no short-term support release. An installed Bodhi Linux can be upgraded to the latest state via command line or package manager.
Release cycle.
Releases are numbered x.y.z, where
The major release (x.y.z; e.g. version 2.y.z > 3.0.0) follows the Ubuntu long term support with a delay of a few months. The goal is to deliver a new major release in July every other year following the new Ubuntu LTS, which is expected in April. New functionality is not added after the release. The Bodhi Linux 3.0.0 branch was released in February 2015 with an additional "legacy" version for older hardware.
The update/point release (x.y.z; e.g. version 2.3.z > 2.4.0) is similar to point releases in Ubuntu (12.04.1, 12.04.2...). Once more frequent, they are used for delivering new software versions and other improvements which are not related to security.
Beginning with version 2.4.0 update frequency is reduced to three times a year. Every four months - in January, May and September for now - a new update should come out. Bodhi Linux 2.4.0 (planned for release in August 2013) appeared a little late in mid-September, "when it [was] ready". A bug fix release (x.y.z; e.g. version 2.4.0 > 2.4.1) is meant for correcting errors with the default configuration.
R_Pi Bodhi Linux.
The "R_Pi Bodhi Linux" build was built directly on top of Raspbian and incorporates all of the changes and improvements to produce optimized "″hard float″" code for the Raspberry Pi ("armhf" or "ARM HF"). Technically, R_Pi Bodhi Linux is built with compilation settings adjusted to produce optimized "″hard float″" code for the Raspberry Pi ("armhf" or "ARM HF"). The "hard float application binary interface" of the ARM11, a 32-bit RISC microprocessor ARM architecture with ARMv6 architectural additions, provides enormous performance gains for many use cases. However, this has required significant effort to port elements of Debian Wheezy to ARMv6 CPU, as official builds require ARMv7. This should significantly enhance performance for applications that make heavy use of floating point arithmetic operations, as previous less efficient "soft float" settings, that is, native ARMv6 architecture floating point arithmetic operations simulated by software. Because of the effort to build a working release, the ARMHF release is not officially supported anymore at the moment.
Reception.
Jack Germain from "LinuxInsider" wrote a positive review of Bodhi Linux 5.0.0, noting that Bodhi Linux is "elegant and lightweight", and that this distribution "can be a productive computing platform".


Remastersys

remastersys is a free and open-source program for Debian, Ubuntu-based, Linux Mint or derivative software systems that can:
As of April 28, 2013, the originator's direct development has ceased.<br>
After this project development ceased by the originator - Fragadelic, a group of developers who are members of Copper Linux User Group in Arizona, began Respin. This development (project "fork") was in transition to new supporters. The original code was received by the originator and the team members discussed the fork with him. This fork released a working version late July 2015. In early October 2015, the Debian Principal Developer, reverted to maintaining Remastersys, but kept Linux Respin open as a project for future features and development. Both the Ubuntu developer/maintainer, Sergio Mejia, and the Debian developer/maintainer, Marcia "aicra" Wilbur, keep respin available on gitlab and launchpad respectively.
History.
It was initially created to be able to easily back up or create a distributable copy of an Ubuntu or derivative installation. Inspiration for this tool came from the mklivecd script that Mandriva uses and the remasterme script that is in PCLinuxOS. Since those scripts were not very easy to port to Ubuntu, it was written from scratch.
Uses.
remastersys is intended to serve as an easy way to create a customized Live CD/DVD version of Ubuntu. The resulting iso can also be installed on a USB pendrive, creating a Live USB distro, using either a command-line approach or a graphical tool such as UNetbootin. Future enhancements discussion include possible rescue software incorporated with remastersys.
It has a command line version and a GUI version.


SciTech SNAP

SciTech SNAP (System Neutral Access Protocol) is an operating system portable, dynamically loadable, native-size 32-bit/64-bit device driver architecture. SciTech SNAP defines the architecture for loading an operating system neutral binary device driver for any type of hardware device, be it a graphics controller, audio controller, SCSI controller or network controller. SciTech SNAP drivers are source code portable between different microprocessor platforms, and the binary drivers are operating system portable within a particular microprocessor family.
SNAP drivers were originally developed for Intel 386+ CPU with any 32-bit operating system or environment supported on that CPU. With the introduction of SNAP 3.0, native binary SNAP drivers are available for 32-bit PowerPC CPUs and 64-bit x86-64 CPUs.
On 27 August 2002, SciTech Software, Inc. announced the intention to release the Scitech SNAP driver development kit.
On 16 November 2006, SciTech Software, Inc. announced that it has ceased further development of its SNAP device driver technology in favor of a new line of web and business logic technologies. SciTech also announced that it would begin looking for a buyer for SciTech SNAP.
In December 2008 Alt Richmond Inc. closed the acquisition of SciTech Software's SNAP technology. The plans of SciTech Software in 2008 to create OpenSNAP, an open source version of the driver technology, are therefore no longer an option unless Alt Richmond decides to pick this up.
In May 2015, Arca Noae, LLC announced that they have reached an agreement with Alt Richmond, Inc. to license the source code for SNAP Graphics for OS/2.
Relationship with Scitech Display Doctor.
SciTech Display Doctor 6.5 included a replacement video driver for Windows 95 or higher, which works with any hardware supported by SDD. In SDD 7, the driver was renamed to Scitech Nucleus Graphics driver. The Nucleus Graphics driver was later incorporated into SciTech SNAP Graphics. In SNAP 3, Nucleus was renamed to SNAP.
SciTech SNAP Graphics version 2 also included VBETest/Lite - VESA BIOS Extensions (VBE) Compliance Test version 8.00. It was later removed in SciTech SNAP Graphics 3.
In SciTech SNAP 3 for DOS, most of the OpenGL tests from SciTech Display Doctor 7 beta can be found in GACtrl Driver Control Center.
The Windows version of Scitech SNAP Graphics maintained the user interface found in SDD 7 beta.
SciTech SNAP Graphics.
It is the first product for the SciTech SNAP line, which provides accelerated graphics.
SciTech SNAP Graphics has been ported to DOS, OS/2, Microsoft Windows (CE, NT, 2000, XP), QNX, SMX (the SunOS/Solaris port of MINIX), Linux, On Time RTOS-32, Unununium OS operating systems. Supported hardware included video processors from 3dfx, 3Dlabs, Alliance Semiconductor, AMD (Geode GX2), ARK Logic, ATI, Chips & Technologies, Cirrus Logic, Cyrix, IBM, InteGraphics, Intel, Matrox, NeoMagic, Number Nine, NVIDIA, Oak, Philips, Rendition, S3, Sigma Designs, Silicon Motion, SiS, Tseng Labs, Trident, VIA, Weitek, as well as any video card supporting VBE 1.2 or higher.
Although SciTech SNAP Graphics does not offer standalone VBE driver, SNAP driver accelerates applications using VBE calls via SciTech SNAP Graphics driver. SNAP Graphics for Windows can also accelerate VBE 3 calls, if DOS programs is run in Windows DOS box.
Personal Edition.
SciTech also offer SciTech SNAP Graphics "PE" (Personal Edition) under the My SciTech site, which allows registered users to download a SNAP driver of hardware and operating system specified by users. Each user account can download two drivers per week. The driver generated by the service can be run for six months.
In Scitech SNAP Graphics PE, tools GACtrl, GAMode, GAOption, GAPerf DOS tools are included. The GLDirect tests are not included in Windows driver.
SciTech SNAP Audio.
Similar to Scitech SNAP Graphics, it provides OS-independent audio drivers. It has been ported to Windows NT 4.0. Supported hardware include AC'97 and Intel HDA, but HDA does not support modem function.
SciTech SNAP DDC.
It is designed to provide easy access to an attached display in order to program it directly via I²C or simply to read the monitor's EDID record.


Mirror driver

A mirror driver is a display driver for a virtual device that mirrors the drawing operations of one or more additional physical display devices.
When video mirroring is active, each time the system draws to the primary video device at a location inside the mirrored area, a copy of the draw operation is executed on the mirrored video device in real-time.
Windows' mirror drivers were first introduced in 1998 with the Windows 2000 display driver model, which was renamed later to XPDM. In 2006, for Windows Vista, Microsoft introduced a new Windows Display Driver Model. The older drivers were still supported under Vista, but since the older model did not encompass support for features first introduced with Vista, those newer features would necessarily be disabled when an older driver was active. As a consequence, when a mirror driver designed for the older model was active, such as when Windows Remote Assistance or Windows Live Mesh were in use, Vista disabled Desktop Window Manager and Windows Aero. A similar situation existed with the transition from Windows 7 to Windows 8. Beginning with the DDK targeted at Windows 8, mirror drivers have to fulfill very exacting specifications - they must support a specific set of functions, and no more than those.
Windows installations come with two mirror drivers preinstalled - "mnmdd" used by NetMeeting, and "RDPDD Chained DD" used for Terminal Server/RemoteDesktop services. Third-party mirror drivers are included with screen readers such as JAWS, Window-Eyes and FreedomBox; the monitoring software LanSchool; and remote desktop software such as Timbuktu, LogMeIn, UltraVNC, TightVNC, Radmin and RemotePC.


Dm-cache

dm-cache is a component (more specifically, a target) of the Linux kernel's device mapper, which is a framework for mapping block devices onto higher-level virtual block devices. It allows one or more fast storage devices, such as flash-based solid-state drives (SSDs), to act as a cache for one or more slower storage devices such as hard disk drives (HDDs); this effectively creates hybrid volumes and provides secondary storage performance improvements.
The design of dm-cache requires three physical storage devices for the creation of a single hybrid volume; dm-cache uses those storage devices to separately store actual data, cache data, and required metadata. Configurable operating modes and cache policies, with the latter in the form of separate modules, determine the way data caching is actually performed.
dm-cache is licensed under the terms of GNU General Public License (GPL), with Joe Thornber, Heinz Mauelshagen and Mike Snitzer as its primary developers.
Overview.
dm-cache uses solid-state drives (SSDs) as an additional level of indirection while accessing hard disk drives (HDDs), improving the overall performance by using fast flash-based SSDs as caches for the slower mechanical HDDs based on rotational magnetic media. As a result, the costly speed of SSDs becomes combined with the storage capacity offered by slower but less expensive HDDs. Moreover, in the case of storage area networks (SANs) used in cloud environments as shared storage systems for virtual machines, dm-cache can also improve overall performance and reduce the load of SANs by providing data caching using client-side local storage.
dm-cache is implemented as a component of the Linux kernel's device mapper, which is a volume management framework that allows various mappings to be created between physical and virtual block devices. The way a mapping between devices is created determines how the virtual blocks are translated into underlying physical blocks, with the specific translation types referred to as "targets". Acting as a mapping target, dm-cache makes it possible for SSD-based caching to be part of the created virtual block device, while the configurable operating modes and cache policies determine how dm-cache works internally. The operating mode selects the way in which the data is kept in sync between an HDD and an SSD, while the cache policy, selectable from separate modules that implement each of the policies, provides the algorithm for determining which blocks are promoted (moved from an HDD to an SSD), demoted (moved from an SSD to an HDD), cleaned, etc.
When configured to use the "multiqueue" (mq) or "stochastic multiqueue" (smq) cache policy, with the latter being the default, dm-cache uses SSDs to store the data associated with performed random reads and writes, capitalizing on near-zero seek times of SSDs and avoiding such I/O operations as typical HDD performance bottlenecks. The data associated with sequential reads and writes is not cached on SSDs, avoiding undesirable cache invalidation during such operations; performance-wise, this is beneficial because the sequential I/O operations are suitable for HDDs due to their mechanical nature. Not caching the sequential I/O also helps in extending the lifetime of SSDs used as caches.
History.
Another dm-cache project with similar goals was announced by Eric Van Hensbergen and Ming Zhao in 2006, as the result of an internship work at IBM.
Later, Joe Thornber, Heinz Mauelshagen and Mike Snitzer provided their own implementation of the concept, which resulted in the inclusion of dm-cache into the Linux kernel. dm-cache was merged into the Linux kernel mainline in kernel version 3.9, which was released on April 28, 2013.
Design.
In dm-cache, creating a mapped virtual block device that acts as a hybrid volume requires three physical storage devices:
Internally, dm-cache references to each of the origin devices through a number of fixed-size blocks; the size of these blocks, equaling to the size of a caching extent, is configurable only during the creation of a hybrid volume. The size of a caching extent must range between 32 KB and 1 GB, and it must be a multiple of 32 KB; typically, the size of a caching extent is between 256 and 1024 KB. The choice of the caching extents bigger than disk sectors acts a compromise between the size of metadata and the possibility for wasting cache space. Having too small caching extents increases the size of metadata, both on the metadata device and in kernel memory, while having too large caching extents increases the amount of wasted cache space due to caching whole extents even in the case of high hit rates only for some of their parts.
Operating modes supported by dm-cache are "write-back", which is the default, "write-through", and "pass-through". In the write-back operating mode, writes to cached blocks go only to the cache device, while the blocks on origin device are only marked as dirty in the metadata. For the write-through operating mode, write requests are not returned as completed until the data reaches both the origin and cache devices, with no clean blocks becoming marked as dirty. In the pass-through operating mode, all reads are performed directly from the origin device, avoiding the cache, while all writes go directly to the origin device; any cache write hits also cause invalidation of the cached blocks. The pass-through mode allows a hybrid volume to be activated when the state of a cache device is not known to be consistent with the origin device.
The rate of data migration that dm-cache performs in both directions (i.e., data promotions and demotions) can be throttled down to a configured speed so regular I/O to the origin and cache devices can be preserved. Decommissioning a hybrid volume or shrinking a cache device requires use of the "cleaner" policy, which effectively flushes all blocks marked in metadata as dirty from the cache device to the origin device.
Cache policies.
 and version 4.2 of the Linux kernel, the following three cache policies are distributed with the Linux kernel mainline, out of which dm-cache by default uses the "stochastic multiqueue" policy:
Use with LVM.
Logical Volume Manager includes codice_1, which provides a wrapper for codice_2 integrated with LVM.


IO.DOS


Intel Extreme Masters

The Intel Extreme Masters (IEM) is a series of international esports tournaments held in countries around the world. These Electronic Sports League (ESL) sanctioned events, sponsored by Intel, currently host events in ' and '. Other game titles were hosted in the past. The body that owns the league is Turtle Entertainment. The League has operated 14 seasons . The season finals, with the largest prize pool, takes place in Katowice, Poland. Mid-season events are held in numerous cities around the globe, including Chicago, Shanghai and Sydney.
History.
The Intel Extreme Masters are a product of the ESL. In 2006, when the Intel sponsored European tournament saw room for expansion outside of Europe, especially in North American markets, Intel provided funds for a worldwide tournament, billing it as the Intel Extreme Masters. In 2007, when established, the IEM established a format of many smaller qualifying events, leading up to a large final event that is held at CeBIT. All of the Grand Finals have been held at CeBIT. Starting in 2008, the Tournament was billed as being worldwide, boasting participants from Europe, North America, and Asia. Although Counterstrike 1.6 was the only game offered in the first season, the variety of games has increased greatly, to the four that were offered during Season 5. World of Warcraft was offered during Season 4, but was dropped for Season 5. The Season 5 Finals will be held at CeBIT and will included a prize pool.
Games offered in Intel Extreme Masters: Counter-Strike (Seasons 1–6), Warcraft 3: Reign of Chaos and Warcraft 3: The Frozen Throne (Seasons 1–2, 3: Asian Championship Finals — CS1.6 and Asian Championship Finals — WoW, 4: Global Challenge Chengdu, 5: Global Challenge Shanghai), World of Warcraft (Seasons 2: Global Challenge Dreamhack, 3–4), Quake Live (Seasons 4–5), StarCraft II (Seasons 5–6), League of Legends (LoL) (Seasons 5: World Championship (LoL Invitational), 6)
IEM seasons.
Season XIV.
Intel Extreme Masters Season XIV – World Championship in Katowice.
Format.
IEM utilizes a fair number of offline qualifiers. During Season 5, qualifiers were held for North America, Europe, and Southeast Asia regions. Those who qualify for the finals are placed into two groups of six, of which the top two advance. The first place member of each group goes directly to the semifinals, and the second and third place members go into the quarterfinals.
Organisation.
The Intel Extreme Masters are run by the ESL which is owned by Turtle Entertainment GmbH. Turtle Entertainment is based in Cologne, Germany.


Namco System 246

The Namco System 246 is a development of the Sony PlayStation 2 technology as a basis for an arcade system board. It was released in December 2000 on its first game "Bloody Roar 3". Like the Sega NAOMI, it is widely licensed for use by other manufacturers. Games such as "Battle Gear 3" and "Capcom Fighting Evolution" are examples of System 246-based arcade games that are not Namco products.
Specifications.
Namco System 256 is an upgraded version of System 246 but the upgrades are unknown (more VRAM and faster CPU speeds likely).
Namco Super System 256 is the same as regular Namco System 256 but it has the gun board integrated, though this variant was only used in "Time Crisis 4".
Namco System 147 is similar to 246 but does not use a DVD-ROM drive, instead it has ROM chips on the system board.


Sempron

Sempron has been the marketing name used by AMD for several different budget desktop CPUs, using several different technologies and CPU socket formats. The Sempron replaced the AMD Duron processor and competes against Intel's Celeron series of processors. AMD coined the name from the Latin "semper", which means "always", to suggest the Sempron is suitable for "daily use, practical, and part of everyday life".
History and features.
The first Sempron CPUs were based on the Athlon XP architecture using the "Thoroughbred" or "Thorton" core. These models were equipped with the Socket A interface, 256 KiB L2 cache and 166 MHz Front side bus (FSB 333). Thoroughbred cores natively had 256 KiB L2 cache, but Thortons had 512 KiB L2 cache, half of which was disabled and could sometimes be reactivated with a slight physical modification to the chip. Later, AMD introduced the Sempron 3000+ CPU, based on the "Barton" core with 512 KiB L2 cache. From a hardware and user standpoint, the Socket A Sempron CPUs were essentially identical to Athlon XP desktop CPUs with a new brand name. AMD has ceased production of all Socket A Sempron CPUs.
The second generation ("Paris"/"Palermo" core) was based on the architecture of the Socket 754 Athlon 64. Some differences from Athlon 64 processors include a reduced cache size (either 128 or 256 KiB L2), and the absence of AMD64 support in earlier models. Apart from these differences, the Socket 754 Sempron CPUs share most features with the more powerful Athlon 64, including an integrated (on-die) memory controller, the HyperTransport link, and AMD's "NX bit" feature.
In the second half of 2005, AMD added 64-bit support (AMD64) to the Sempron line. Some journalists (but not AMD) often refer to this revision of chips as "Sempron 64" to distinguish it from the previous revision. AMD's intent in releasing 64-bit entry-level processors was to extend the market for 64-bit processors, which at the time of Sempron 64's first release, was a niche market.
In 2006, AMD announced the Socket AM2 and Socket S1 line of Sempron processors. These are functionally equivalent to the previous generation, except they have a dual-channel DDR2 SDRAM memory controller which replaces the single-channel DDR SDRAM version. The TDP of the standard version remains at 62 W (watts), while the new "Energy Efficient Small Form Factor" version has a reduced 35 W TDP. The Socket AM2 version also does not require a minimum voltage of 1.1 volts to operate, whereas all socket 754 Semprons with Cool'n'Quiet did. In 2006, AMD was selling both Socket 754 and Socket AM2 Sempron CPUs concurrently. In the middle of 2007 AMD appears to have dropped the 754 line and is shipping AM2 and S1 Semprons.
Semprons without Cool'n'Quiet.
AMD has released some Sempron processors without Cool'n'Quiet support. The following table describes those processors lacking Cool'n'Quiet.


Turkix

Turkix was a live Linux distribution, capable of self-installing on hard disk using a graphical wizard. The main goal of Turkix was to provide a very user-friendly Linux environment. Turkix was based on the Mandriva distribution. In visual style Turkix was similar to Windows XP.
First two releases of Turkix (1.0 and 1.9) were in Turkish and Azerbaijani only, but later releases had more language support, especially English.
Latest stable release of Turkix was 3.0, and the last unstable release was 10.0 Alpha. At this point the project was aborted.


Direction flag

The direction flag is a flag that controls the "left-to-right" or "right-to-left" direction of string processing, stored in the FLAGS register on all x86-compatible CPUs. It is bit number 10.
This flag is used to determine the direction ('forward' or 'backward') in which several bytes of data will be copied from one place in the memory, to another. The direction is important mainly when the original data position in memory and the target data position overlap.


Asterix at the Olympic Games (video game)

Asterix at the Olympic Games is an adventure sports video game for the Wii, Xbox 360, PlayStation 2, Microsoft Windows and Nintendo DS developed by Étranges Libellules and published by Atari Europe. It is loosely based on the comic with the same name and mostly based on the live action film. It was released in Europe on 9 November 2007 for the Windows, Wii, PlayStation 2 and Nintendo DS, followed by the UK release on 29 February 2008. The game also released on Xbox 360 in 2008.
Plot.
Astérix and Obélix have to win the Olympic Games in order to help their lovesick friend Lovestorix marry Princess Irina. Brutus uses every trick in the book to have his own team win the game, and get rid of his father Julius Caesar in the process.
Gameplay.
While letting the players to switch control between both Asterix and Obelix anytime, the action is split between platforming in 3D through the city and competing in challenges to unlock new areas. Players can throw the javelin and hammer, participate in the long jump, running events, and various other Olympic events (in Wii's case, by using the controller). Besides the main Story mode, there is also the Antique mode, which gives a freedom of selecting any Olympic event and playing it right away.


Comparison of ARMv7-A cores

This is a table comparing microarchitectures which implement the ARM ARMv7-A (A means Application) instruction set architecture and mandatory or optional extensions of it, the last AArch32.