Camp.

The camp was established in connection with the ethnic cleansing project that included the liquidation of Polish elites (members of the intelligentsia, religious and political leaders) in the Danzig area and Western Prussia.  Even before the war began, the German Selbstschutz in Pomerania created lists of people to be arrested, and the Nazi authorities were secretly reviewing suitable places to set up concentration camps in their area.  Originally, Stutthof was a civilian internment camp under the Danzig police chief, before its subsequent massive expansion. In November 1941, it became a "labor education" camp (like Dachau), administered by the German Security Police. Finally, in January 1942, Stutthof became a regular concentration camp.  The original camp (known as the old camp) was surrounded by the barbed-wire fence. It comprised eight barracks for the inmates and a "Kommandantur" for the SS guards, totaling 120,000 m2. In 1943, the camp was enlarged and a new camp was constructed alongside the earlier one. It was also surrounded by electrified barbed-wire fence and contained thirty new barracks, raising the total area to 1.2 km2 (0.5 sq mi). A crematorium and gas chamber were added in 1943, just in time to start mass executions when Stutthof was included in the "Final Solution" in June 1944. Mobile gas wagons were also used to complement the maximum capacity of the gas chamber (150 people per execution) when needed.

Staff.

The camp staff consisted of German "SS" guards and after 1943, the Ukrainian auxiliaries brought in by "SS-Gruppenführer" Fritz Katzmann.  In 1942 the first German female "SS" "Aufseherinnen" guards arrived at Stutthof along with female prisoners. A total of 295 women guards worked as staff in the Stutthof complex of camps.  Among the notable female guard personnel were: Elisabeth Becker, Erna Beilhardt, Ella Bergmann, Ella Blank, Gerda Bork, Herta Bothe, Erna Boettcher, Hermine Boettcher-Brueckner, Steffi Brillowski, Charlotte Graf, Charlotte Gregor, Charlotte Klein, Gerda Steinhoff, Ewa Paradies, and Jenny-Wanda Barkmann. Thirty-four female guards including Becker, Bothe, Steinhoff, Paradies, and Barkmann were identified later as having committed crimes against humanity. The "SS" in Stutthof began conscripting women from Danzig and the surrounding cities in June 1944, to train as camp guards because of their severe shortage after the women's subcamp of Stutthof called Bromberg-Ost (Konzentrationslager Bromberg-Ost) was set up in the city of Bydgoszcz.  Several Norwegian Waffen SS volunteers worked as guards or as instructors for prisoners from Nordic countries, according to senior researcher at the Norwegian Center for Studies of Holocaust and Religious Minorities, Terje Emberland.

Prisoners.

The first 150 inmates, imprisoned on 2 September 1939, were selected among Poles and Jews arrested in Danzig immediately after the outbreak of war. The inmate population rose to 6,000 in the following two weeks, on 15 September 1939. Until 1942, nearly all of the prisoners were Polish. The number of inmates increased considerably in 1944, with Jews forming a significant proportion of the newcomers. The first contingent of 2,500 Jewish prisoners arrived from Auschwitz in July 1944. In total, 23,566 Jews (including 21,817 women) were transferred to Stutthof from Auschwitz, and 25,053 (including 16,123 women) from camps in the Baltic states. When the Soviet army began its advance through German-occupied Estonia in July and August 1944, the camp staff of Klooga concentration camp evacuated the majority of the inmates by sea and sent them to Stutthof.  Stutthof's registered inmates included citizens of 28 countries, and besides Jews and Poles - Germans, Czechs, Dutch, Belgians, French, Norwegians, Finns, Danes, Lithuanians, Latvians, Belarusians, Russians and others. Among 110,000 prisoners were Jews from all of Europe, members of the Polish underground, Polish civilians deported from Warsaw during the Warsaw Uprising, Lithuanian and Latvian intelligentsia, Latvian resistance fighters, psychiatric patients, Soviet prisoners of war, and communists (as an example of communist deportations to Stutthof, see the Danish Horserød camp). It is believed that inmates sent for immediate execution were not registered.

Conditions.

Conditions in the camp were extremely harsh. The first executions were carried out on 11 January and 22 March 1940 - 89 Polish activists and government officials were shot. Many prisoners died in typhus epidemics that swept the camp in the winter of 1942 and again in 1944. Those whom the SS guards judged too weak or sick to work were gassed in the camp's small gas chamber. Gassing with Zyklon B began in June 1944. 4,000 prisoners, including Jewish women and children, were killed in a gas chamber before the evacuation of the camp. Another method of execution practiced in Stutthof was lethal injection of phenol into the heart. Between 63,000 and 65,000 people died in the camp.  A range of German organisations and individuals used Stutthof prisoners as forced laborers. Many prisoners worked in SS-owned businesses such as DAW ("Deutsche Ausrüstungswerke"), the heavily guarded armaments factory meaning literally the German Equipment Works which was located inside the camp ("see map") next to prisoner barracks. Other inmates labored in local brickyards, in private industrial enterprises, in agriculture, or in the camp's own workshops. In 1944, as forced labor by concentration camp prisoners became increasingly important in armaments production, a Focke-Wulf aircraft factory was constructed at Stutthof. Eventually, the Stutthof camp system became a network of forced-labor camps. The "Holocaust Encyclopedia" estimates that (less officially) some 105 Stutthof subcamps were established throughout northern and central Poland. The major subcamps were in Toruń (Thorn) and in Elbląg (Elbing).

Sub-camps.

The main German concentration camp in Stutthof had as many as 40 sub-camps during World War II. In total, the sub-camps held 110,000 prisoners from 25 countries according to the Jewish Virtual Library. The sub-camps of Stutthof included:

Death march.

The evacuation of prisoners from the Stutthof camp system began on 25 January 1945. When the final evacuation began, there were nearly 50,000 prisoners, the majority of them Jews, in the Stutthof camp system. About 5,000 prisoners from Stutthof subcamps were marched to the Baltic Sea coast, forced into the water, and machine-gunned. The rest of the prisoners were marched in the direction of Lauenburg in eastern Germany. Cut off by advancing Soviet forces the Germans forced the surviving prisoners back to Stutthof. Marching in severe winter conditions and brutal treatment by SS guards led to thousands of deaths.  In late April 1945, the remaining prisoners were removed from Stutthof by sea, since the camp was completely encircled by Soviet forces. Again, hundreds of prisoners were forced into the sea and shot. Over 4,000 were sent by small boat to Germany, some to the Neuengamme concentration camp near Hamburg, and some to camps along the Baltic coast. Many drowned along the way.  On 5 May 1945, a barge full of starving prisoners was towed into harbour at Klintholm Havn in Denmark where 351 of the 370 on board were saved. Shortly before the German surrender, some prisoners were transferred to Malmö, Sweden, and released into the care of that neutral country. It has been estimated that around half of the evacuated prisoners, over 25,000, died during the evacuation from Stutthof and its subcamps.  Soviet forces liberated Stutthof on 9 May 1945, rescuing about 100 prisoners who had managed to hide.

Stutthof trials.

The well known Nuremberg Trials were only concerned with concentration camps as evidence for war crimes and crimes against humanity committed by the Third Reich leadership. Several lesser known trials followed against the staff of various concentration camps. Poland held four trials in Gdańsk against former guards and "kapos" of Stutthof, charging them with crimes of war and crimes against humanity.  The first trial was held from April 25 to May 31, 1946 against 30 ex-officials and prisoner-guards of the camp. The Soviet/Polish Special Criminal Court found all of them guilty of the charges. Eleven defendants including the former commander, Johann Pauls, were sentenced to death. The rest were sentenced to various terms of imprisonment.  The second trial was held from October 8 to October 31, 1947, before a Polish Special Criminal Court. Arraigned 24 ex-officials and guards of the Stutthof concentration camp were judged and found guilty. Ten were sentenced to death.  The third trial was held from November 5 to November 10, 1947, before a Polish Special Criminal Court. Arraigned 20 ex-officials and guards were judged; 19 were found guilty, and one was acquitted.  The fourth and final trial was also held before a Polish Special Criminal Court, from November 19 to November 29, 1947. Twenty-seven ex-officials and guards were arraigned and judged; 26 were found guilty, and one was acquitted.  An additional trial was attempted in November 2018, when Johann Rehbogen was accused of being an accessory to murder. There was no evidence to link him to specific killings, and though he admitted to serving at the camp, he said that he was unaware that people were being murdered there. He was charged as a juvenile, as he was under 21 at the time of the offense. Images in the news broadcasts concealed his face for legal reasons. Being tried at the age of 94, court proceedings were limited to no more than two hours per day and two non-consecutive days per week. In February 2019 the trial of a defendant matching this description (whom Reuters reported could not be named for legal reasons) was halted after a medical report was issued stating that the defendant was unfit to stand trial, the trial already having been suspended since the previous December.  Another Nazi camp guard, Bruno Dey, from Hamburg was charged in October 2019 of contributing to the killings of 5,230 prisoners at Stutthof camp between 1944 and 1945. He was tried in a juvenile court due to being about 17 at that time.

"The Game of Tag".

In 1999, Artur Żmijewski filmed a group of nude people playing tag in one of the Stutthof gas chambers, sparking outrage.

Stutthof was a German concentration camp established in a secluded, marshy, and wooded area near the small town of Sztutowo () 34 km (21 mi) east of the city of Danzig in the former territory of the Free City of Danzig. The camp was set up around existing structures after the invasion of Poland in World War II and initially used for the imprisonment of Polish leaders and intelligentsia. The actual barracks were built the following year by prisoners.

Das KZ Stutthof war ein deutsches Konzentrationslager, 37 Kilometer östlich von Danzig bei Stutthof im Landkreis Danziger Niederung auf dem Gebiet der annektierten Freien Stadt Danzig. Das Lager bestand nach vorbereitenden Arbeiten im Juli und August vom 2. September 1939 bis zum 9. Mai 1945. Es war nach dem deutschen Angriff auf die Freie Stadt Danzig und dem Überfall auf Polen zunächst ein "Zivilgefangenenlager". Am 1. Oktober 1941 wurde der Status des Lagers geändert, als "Sonderlager Stutthof" unterstand es fortan der Danziger Gestapo. Am 29. Januar 1942 erhielt Stutthof als "Konzentrationslager der Stufe I" den Status, den es bis Kriegsende behalten sollte.


History.

The term "RAID" was invented by David Patterson, Garth A. Gibson, and Randy Katz at the University of California, Berkeley in 1987. In their June 1988 paper "A Case for Redundant Arrays of Inexpensive Disks (RAID)", presented at the SIGMOD conference, they argued that the top-performing mainframe disk drives of the time could be beaten on performance by an array of the inexpensive drives that had been developed for the growing personal computer market. Although failures would rise in proportion to the number of drives, by configuring for redundancy, the reliability of an array could far exceed that of any large single drive.  Although not yet using that terminology, the technologies of the five levels of RAID named in the June 1988 paper were used in various products prior to the paper's publication, including the following:  Industry manufacturers later redefined the RAID acronym to stand for "Redundant Array of "Independent" Disks".

Overview.

Many RAID levels employ an error protection scheme called "parity", a widely used method in information technology to provide fault tolerance in a given set of data. Most use simple XOR, but RAID 6 uses two separate parities based respectively on addition and multiplication in a particular Galois field or Reed–Solomon error correction.  RAID can also provide data security with solid-state drives (SSDs) without the expense of an all-SSD system. For example, a fast SSD can be mirrored with a mechanical drive. For this configuration to provide a significant speed advantage an appropriate controller is needed that uses the fast SSD for all read operations. Adaptec calls this "hybrid RAID".

Standard levels.

A number of standard schemes have evolved. These are called "levels". Originally, there were five RAID levels, but many variations have evolved, including several nested levels and many non-standard levels (mostly proprietary). RAID levels and their associated data formats are standardized by the Storage Networking Industry Association (SNIA) in the Common RAID Disk Drive Format (DDF) standard:

Nested (hybrid) RAID.

In what was originally termed "hybrid RAID", many storage controllers allow RAID levels to be nested. The elements of a "RAID" may be either individual drives or arrays themselves. Arrays are rarely nested more than one level deep.  The final array is known as the top array. When the top array is RAID 0 (such as in RAID 1+0 and RAID 5+0), most vendors omit the "+" (yielding RAID 10 and RAID 50, respectively).

Non-standard levels.

Many configurations other than the basic numbered RAID levels are possible, and many companies, organizations, and groups have created their own non-standard configurations, in many cases designed to meet the specialized needs of a small niche group. Such configurations include the following:

Implementations.

The distribution of data across multiple drives can be managed either by dedicated computer hardware or by software. A software solution may be part of the operating system, part of the firmware and drivers supplied with a standard drive controller (so-called "hardware-assisted software RAID"), or it may reside entirely within the hardware RAID controller.

Hardware-based.

Configuration of hardware RAID.

Hardware RAID controllers can be configured through card BIOS before an operating system is booted, and after the operating system is booted, proprietary configuration utilities are available from the manufacturer of each controller. Unlike the network interface controllers for Ethernet, which can usually be configured and serviced entirely through the common operating system paradigms like ifconfig in Unix, without a need for any third-party tools, each manufacturer of each RAID controller usually provides their own proprietary software tooling for each operating system that they deem to support, ensuring a vendor lock-in, and contributing to reliability issues.  For example, in FreeBSD, in order to access the configuration of Adaptec RAID controllers, users are required to enable Linux compatibility layer, and use the Linux tooling from Adaptec, potentially compromising the stability, reliability and security of their setup, especially when taking the long term view.  Some other operating systems have implemented their own generic frameworks for interfacing with any RAID controller, and provide tools for monitoring RAID volume status, as well as facilitation of drive identification through LED blinking, alarm management and hot spare disk designations from within the operating system without having to reboot into card BIOS. For example, this was the approach taken by OpenBSD in 2005 with its bio(4) pseudo-device and the bioctl utility, which provide volume status, and allow LED/alarm/hotspare control, as well as the sensors (including the drive sensor) for health monitoring; this approach has subsequently been adopted and extended by NetBSD in 2007 as well.

Software-based.

Software RAID implementations are provided by many modern operating systems. Software RAID can be implemented as:  Some advanced file systems are designed to organize data across multiple storage devices directly, without needing the help of a third-party logical volume manager:  Many operating systems provide RAID implementations, including the following:  If a boot drive fails, the system has to be sophisticated enough to be able to boot from the remaining drive or drives. For instance, consider a computer whose disk is configured as RAID 1 (mirrored drives); if the first drive in the array fails, then a first-stage boot loader might not be sophisticated enough to attempt loading the second-stage boot loader from the second drive as a fallback. The second-stage boot loader for FreeBSD is capable of loading a kernel from such an array.

Firmware- and driver-based.

Software-implemented RAID is not always compatible with the system's boot process, and it is generally impractical for desktop versions of Windows. However, hardware RAID controllers are expensive and proprietary. To fill this gap, inexpensive "RAID controllers" were introduced that do not contain a dedicated RAID controller chip, but simply a standard drive controller chip with proprietary firmware and drivers. During early bootup, the RAID is implemented by the firmware and, once the operating system has been more completely loaded, the drivers take over control. Consequently, such controllers may not work when driver support is not available for the host operating system. An example is Intel Matrix RAID, implemented on many consumer-level motherboards.  Because some minimal hardware support is involved, this implementation is also called "hardware-assisted software RAID", "hybrid model" RAID, or even "fake RAID". If RAID 5 is supported, the hardware may provide a hardware XOR accelerator. An advantage of this model over the pure software RAID is that—if using a redundancy mode—the boot drive is protected from failure (due to the firmware) during the boot process even before the operating systems drivers take over.

Integrity.

Data scrubbing (referred to in some environments as "patrol read") involves periodic reading and checking by the RAID controller of all the blocks in an array, including those not otherwise accessed. This detects bad blocks before use. Data scrubbing checks for bad blocks on each storage device in an array, but also uses the redundancy of the array to recover bad blocks on a single drive and to reassign the recovered data to spare blocks elsewhere on the drive.  Frequently, a RAID controller is configured to "drop" a component drive (that is, to assume a component drive has failed) if the drive has been unresponsive for eight seconds or so; this might cause the array controller to drop a good drive because that drive has not been given enough time to complete its internal error recovery procedure. Consequently, using consumer-marketed drives with RAID can be risky, and so-called "enterprise class" drives limit this error recovery time to reduce risk. Western Digital's desktop drives used to have a specific fix. A utility called WDTLER.exe limited a drive's error recovery time. The utility enabled TLER (time limited error recovery), which limits the error recovery time to seven seconds. Around September 2009, Western Digital disabled this feature in their desktop drives (e.g. the Caviar Black line), making such drives unsuitable for use in RAID configurations. However, Western Digital enterprise class drives are shipped from the factory with TLER enabled. Similar technologies are used by Seagate, Samsung, and Hitachi. For non-RAID usage, an enterprise class drive with a short error recovery timeout that cannot be changed is therefore less suitable than a desktop drive. In late 2010, the Smartmontools program began supporting the configuration of ATA Error Recovery Control, allowing the tool to configure many desktop class hard drives for use in RAID setups.  While RAID may protect against physical drive failure, the data is still exposed to operator, software, hardware, and virus destruction. Many studies cite operator fault as a common source of malfunction, such as a server operator replacing the incorrect drive in a faulty RAID, and disabling the system (even temporarily) in the process.  An array can be overwhelmed by catastrophic failure that exceeds its recovery capacity and the entire array is at risk of physical damage by fire, natural disaster, and human forces, however backups can be stored off site. An array is also vulnerable to controller failure because it is not always possible to migrate it to a new, different controller without data loss.

Weaknesses.

Correlated failures.

In practice, the drives are often the same age (with similar wear) and subject to the same environment. Since many drive failures are due to mechanical issues (which are more likely on older drives), this violates the assumptions of independent, identical rate of failure amongst drives; failures are in fact statistically correlated. In practice, the chances for a second failure before the first has been recovered (causing data loss) are higher than the chances for random failures. In a study of about 100,000 drives, the probability of two drives in the same cluster failing within one hour was four times larger than predicted by the exponential statistical distribution—which characterizes processes in which events occur continuously and independently at a constant average rate. The probability of two failures in the same 10-hour period was twice as large as predicted by an exponential distribution.

Unrecoverable read errors during rebuild.

Unrecoverable read errors (URE) present as sector read failures, also known as latent sector errors (LSE). The associated media assessment measure, unrecoverable bit error (UBE) rate, is typically guaranteed to be less than one bit in 10 for enterprise-class drives (SCSI, FC, SAS or SATA), and less than one bit in 10 for desktop-class drives (IDE/ATA/PATA or SATA). Increasing drive capacities and large RAID 5 instances have led to the maximum error rates being insufficient to guarantee a successful recovery, due to the high likelihood of such an error occurring on one or more remaining drives during a RAID set rebuild. When rebuilding, parity-based schemes such as RAID 5 are particularly prone to the effects of UREs as they affect not only the sector where they occur, but also reconstructed blocks using that sector for parity computation.  Double-protection parity-based schemes, such as RAID 6, attempt to address this issue by providing redundancy that allows double-drive failures; as a downside, such schemes suffer from elevated write penalty—the number of times the storage medium must be accessed during a single write operation. Schemes that duplicate (mirror) data in a drive-to-drive manner, such as RAID 1 and RAID 10, have a lower risk from UREs than those using parity computation or mirroring between striped sets. Data scrubbing, as a background process, can be used to detect and recover from UREs, effectively reducing the risk of them happening during RAID rebuilds and causing double-drive failures. The recovery of UREs involves remapping of affected underlying disk sectors, utilizing the drive's sector remapping pool; in case of UREs detected during background scrubbing, data redundancy provided by a fully operational RAID set allows the missing data to be reconstructed and rewritten to a remapped sector.

Increasing rebuild time and failure probability.

Drive capacity has grown at a much faster rate than transfer speed, and error rates have only fallen a little in comparison. Therefore, larger-capacity drives may take hours if not days to rebuild, during which time other drives may fail or yet undetected read errors may surface. The rebuild time is also limited if the entire array is still in operation at reduced capacity. Given an array with only one redundant drive (which applies to RAID levels 3, 4 and 5, and to "classic" two-drive RAID 1), a second drive failure would cause complete failure of the array. Even though individual drives' mean time between failure (MTBF) have increased over time, this increase has not kept pace with the increased storage capacity of the drives. The time to rebuild the array after a single drive failure, as well as the chance of a second failure during a rebuild, have increased over time.  Some commentators have declared that RAID 6 is only a "band aid" in this respect, because it only kicks the problem a little further down the road. However, according to the 2006 NetApp study of Berriman et al., the chance of failure decreases by a factor of about 3,800 (relative to RAID 5) for a proper implementation of RAID 6, even when using commodity drives. Nevertheless, if the currently observed technology trends remain unchanged, in 2019 a RAID 6 array will have the same chance of failure as its RAID 5 counterpart had in 2010.  Mirroring schemes such as RAID 10 have a bounded recovery time as they require the copy of a single failed drive, compared with parity schemes such as RAID 6, which require the copy of all blocks of the drives in an array set. Triple parity schemes, or triple mirroring, have been suggested as one approach to improve resilience to an additional drive failure during this large rebuild time.

Atomicity: including parity inconsistency due to system crashes.

A system crash or other interruption of a write operation can result in states where the parity is inconsistent with the data due to non-atomicity of the write process, such that the parity cannot be used for recovery in the case of a disk failure (the so-called RAID 5 write hole). The RAID write hole is a known data corruption issue in older and low-end RAIDs, caused by interrupted destaging of writes to disk. The write hole can be addressed with write-ahead logging. Recently mdadm fixed it by introducing a dedicated journaling device (to avoid performance penalty, typically, SSDs and NVMs are preferred) for that purpose.  This is a little understood and rarely mentioned failure mode for redundant storage systems that do not utilize transactional features. Database researcher Jim Gray wrote "Update in Place is a Poison Apple" during the early days of relational database commercialization.

Write-cache reliability.

There are concerns about write-cache reliability, specifically regarding devices equipped with a write-back cache, which is a caching system that reports the data as written as soon as it is written to cache, as opposed to when it is written to the non-volatile medium. If the system experiences a power loss or other major failure, the data may be irrevocably lost from the cache before reaching the non-volatile storage. For this reason good write-back cache implementations include mechanisms, such as redundant battery power, to preserve cache contents across system failures (including power failures) and to flush the cache at system restart time.

RAID ("Redundant Array of Inexpensive Disks" or "Redundant Array of Independent Disks") is a data storage virtualization technology that combines multiple physical disk drive components into one or more logical units for the purposes of data redundancy, performance improvement, or both. This was in contrast to the previous concept of highly reliable mainframe disk drives referred to as "single large expensive disk" (SLED).

Ein RAID-System dient zur Organisation mehrerer physischer Massenspeicher (üblicherweise Festplattenlaufwerke oder Solid-State-Drives) zu einem logischen Laufwerk, das eine höhere Ausfallsicherheit oder einen größeren Datendurchsatz erlaubt als ein einzelnes physisches Speichermedium. Der Begriff ist ein Akronym für, also „redundante Anordnung unabhängiger Festplatten“ (ursprünglich englisch „redundant array of "inexpensive" disks“; deutsch „redundante Anordnung kostengünstiger Festplatten“; was aus Marketinggründen aufgegeben wurde).


Specifications.

File formats often have a published specification describing the encoding method and enabling testing of program intended functionality. Not all formats have freely available specification documents, partly because some developers view their specification documents as trade secrets, and partly because other developers never author a formal specification document, letting precedent set by other already existing programs that use the format define the format via how these existing programs use it.  If the developer of a format doesn't publish free specifications, another developer looking to utilize that kind of file must either reverse engineer the file to find out how to read it or acquire the specification document from the format's developers for a fee and by signing a non-disclosure agreement. The latter approach is possible only when a formal specification document exists. Both strategies require significant time, money, or both; therefore, file formats with publicly available specifications tend to be supported by more programs.

Patents.

Patent law, rather than copyright, is more often used to protect a file format. Although patents for file formats are not directly permitted under US law, some formats encode data using patented algorithms. For example, using compression with the GIF file format requires the use of a patented algorithm, and though the patent owner did not initially enforce their patent, they later began collecting royalty fees. This has resulted in a significant decrease in the use of GIFs, and is partly responsible for the development of the alternative PNG format. However, the GIF patent expired in the US in mid-2003, and worldwide in mid-2004.

Identifying file type.

Different operating systems have traditionally taken different approaches to determining a particular file's format, with each approach having its own advantages and disadvantages. Most modern operating systems and individual applications need to use all of the following approaches to read "foreign" file formats, if not work with them completely.

Filename extension.

One popular method used by many operating systems, including Windows, macOS, CP/M, DOS, VMS and VM/CMS is to determine the format of a file based on the end of its name, more specifically the letters following the final period. This portion of the filename is known as the filename extension. For example, HTML documents are identified by names that end with (or ), and GIF images by. In the original FAT file system, file names were limited to an eight-character identifier and a three-character extension, known as an 8.3 filename. There are only so many three-letter extensions, so, often any given extension might be linked to more than one program. Many formats still use three-character extensions even though modern operating systems and application programs no longer have this limitation. Since there is no standard list of extensions, more than one format can use the same extension, which can confuse both the operating system and users.  One artifact of this approach is that the system can easily be tricked into treating a file as a different format simply by renaming it—an HTML file can, for instance, be easily treated as plain text by renaming it from to. Although this strategy was useful to expert users who could easily understand and manipulate this information, it was often confusing to less technical users, who could accidentally make a file unusable (or "lose" it) by renaming it incorrectly.  This led more recent operating system shells, such as Windows 95 and Mac OS X, to hide the extension when listing files. This prevents the user from accidentally changing the file type, and allows expert users to turn this feature off and display the extensions.  Hiding the extension, however, can create the appearance of two or more identical filenames in the same folder. For example, a company logo may be needed both in format (for publishing) and format (for web sites). With the extensions visible, these would appear as the unique filenames: "" and "". On the other hand, hiding the extensions would make both appear as "", which can lead to confusion.  Hiding extensions can also pose a security risk. For example, a malicious user could create an executable program with an innocent name such as "". The "" would be hidden and an unsuspecting user would see "", which would appear to be a JPEG image, usually unable to harm the machine. However, the operating system would still see the "" extension and run the program, which would then be able to cause harm to the computer. The same is true with files with only one extension: as it is not shown to the user, no information about the file can be deduced without explicitly investigating the file. To further trick users, it is possible to store an icon inside the program, in which case some operating systems' icon assignment for the executable file () would be overridden with an icon commonly used to represent JPEG images, making the program look like an image. Extensions can also be spoofed: some Microsoft Word macro viruses create a Word file in template format and save it with a extension. Since Word generally ignores extensions and looks at the format of the file, these would open as templates, execute, and spread the virus. These issues require users with extensions hidden to be vigilant and never let the operating system choose with what program to open a file not known to be trustworthy (which contradicts the idea of making things easier for the user). This represents a practical problem for Windows systems where extension-hiding is turned on by default.

Internal metadata.

A second way to identify a file format is to "use information" regarding the format stored inside the file itself, either information meant for this purpose or binary strings that happen to always be in specific locations in files of some formats. Since the easiest place to locate them is at the beginning, such area is usually called a "file header" when it is greater than a few bytes, or a "magic number" if it is just a few bytes long.

File header.

The metadata contained in a file header are usually stored at the start of the file, but might be present in other areas too, often including the end, depending on the file format or the type of data contained. Character-based (text) files usually have character-based headers, whereas binary formats usually have binary headers, although this is not a rule. Text-based file headers usually take up more space, but being human-readable, they can easily be examined by using simple software such as a text editor or a hexadecimal editor.  As well as identifying the file format, file headers may contain metadata about the file and its contents. For example, most image files store information about image format, size, resolution and color space, and optionally authoring information such as who made the image, when and where it was made, what camera model and photographic settings were used (Exif), and so on. Such metadata may be used by software reading or interpreting the file during the loading process and afterwards.  File headers may be used by an operating system to quickly gather information about a file without loading it all into memory, but doing so uses more of a computer's resources than reading directly from the directory information. For instance, when a graphic file manager has to display the contents of a folder, it must read the headers of many files before it can display the appropriate icons, but these will be located in different places on the storage medium thus taking longer to access. A folder containing many files with complex metadata such as thumbnail information may require considerable time before it can be displayed.  If a header is binary hard-coded such that the header itself needs complex interpretation in order to be recognized, especially for metadata content protection's sake, there is a risk that the file format can be misinterpreted. It may even have been badly written at the source. This can result in corrupt metadata which, in extremely bad cases, might even render the file unreadable.  A more complex example of file headers are those used for wrapper (or container) file formats.

Magic number.

One way to incorporate file type metadata, often associated with Unix and its derivatives, is just to store a "magic number" inside the file itself. Originally, this term was used for a specific set of 2-byte identifiers at the beginnings of files, but since any binary sequence can be regarded as a number, any feature of a file format which uniquely distinguishes it can be used for identification. GIF images, for instance, always begin with the ASCII representation of either or, depending upon the standard to which they adhere. Many file types, especially plain-text files, are harder to spot by this method. HTML files, for example, might begin with the string (which is not case sensitive), or an appropriate document type definition that starts with, or, for XHTML, the XML identifier, which begins with. The files can also begin with HTML comments, random text, or several empty lines, but still be usable HTML.  The magic number approach offers better guarantees that the format will be identified correctly, and can often determine more precise information about the file. Since reasonably reliable "magic number" tests can be fairly complex, and each file must effectively be tested against every possibility in the magic database, this approach is relatively inefficient, especially for displaying large lists of files (in contrast, file name and metadata-based methods need to check only one piece of data, and match it against a sorted index). Also, data must be read from the file itself, increasing latency as opposed to metadata stored in the directory. Where file types don't lend themselves to recognition in this way, the system must fall back to metadata. It is, however, the best way for a program to check if the file it has been told to process is of the correct format: while the file's name or metadata may be altered independently of its content, failing a well-designed magic number test is a pretty sure sign that the file is either corrupt or of the wrong type. On the other hand, a valid magic number does not guarantee that the file is not corrupt or is of a correct type.  So-called shebang lines in script files are a special case of magic numbers. Here, the magic number is human-readable text that identifies a specific command interpreter and options to be passed to the command interpreter.  Another operating system using magic numbers is AmigaOS, where magic numbers were called "Magic Cookies" and were adopted as a standard system to recognize executables in Hunk executable file format and also to let single programs, tools and utilities deal automatically with their saved data files, or any other kind of file types when saving and loading data. This system was then enhanced with the Amiga standard Datatype recognition system. Another method was the FourCC method, originating in OSType on Macintosh, later adapted by Interchange File Format (IFF) and derivatives.

External metadata.

A final way of storing the format of a file is to explicitly store information about the format in the file system, rather than within the file itself.  This approach keeps the metadata separate from both the main data and the name, but is also less portable than either filename extensions or "magic numbers", since the format has to be converted from filesystem to filesystem. While this is also true to an extent with filename extensions—for instance, for compatibility with MS-DOS's three character limit—most forms of storage have a roughly equivalent definition of a file's data and name, but may have varying or no representation of further metadata.  Note that zip files or archive files solve the problem of handling metadata. A utility program collects multiple files together along with metadata about each file and the folders/directories they came from all within one new file (e.g. a zip file with extension ). The new file is also compressed and possibly encrypted, but now is transmissible as a single file across operating systems by FTP systems or attached to email. At the destination, it must be unzipped by a compatible utility to be useful, but the problems of transmission are solved this way.

Mac OS type-codes.

The Mac OS' Hierarchical File System stores codes for "creator" and "type" as part of the directory entry for each file. These codes are referred to as OSTypes. These codes could be any 4-byte sequence, but were often selected so that the ASCII representation formed a sequence of meaningful characters, such as an abbreviation of the application's name or the developer's initials. For instance a HyperCard "stack" file has a "creator" of (from Hypercard's previous name, "WildCard") and a "type" of. The BBEdit text editor has a creator code of referring to its original programmer, Rich Siegel. The type code specifies the format of the file, while the creator code specifies the default program to open it with when double-clicked by the user. For example, the user could have several text files all with the type code of, but which each open in a different program, due to having differing creator codes. This feature was intended so that, for example, human-readable plain-text files could be opened in a general purpose text editor, while programming or HTML code files would open in a specialized editor or IDE. However, this feature was often the source of user confusion, as which program would launch when the files were double-clicked was often unpredictable. RISC OS uses a similar system, consisting of a 12-bit number which can be looked up in a table of descriptions—e.g. the hexadecimal number is "aliased" to, representing a PostScript file.

Mac OS X uniform type identifiers (UTIs).

A Uniform Type Identifier (UTI) is a method used in macOS for uniquely identifying "typed" classes of entity, such as file formats. It was developed by Apple as a replacement for OSType (type & creator codes).  The UTI is a Core Foundation string, which uses a reverse-DNS string. Some common and standard types use a domain called (e.g. for a Portable Network Graphics image), while other domains can be used for third-party types (e.g. for Portable Document Format). UTIs can be defined within a hierarchical structure, known as a conformance hierarchy. Thus, conforms to a supertype of, which itself conforms to a supertype of. A UTI can exist in multiple hierarchies, which provides great flexibility.  In addition to file formats, UTIs can also be used for other entities which can exist in macOS, including:

OS/2 extended attributes.

The HPFS, FAT12 and FAT16 (but not FAT32) filesystems allow the storage of "extended attributes" with files. These comprise an arbitrary set of triplets with a name, a coded type for the value and a value, where the names are unique and values can be up to 64 KB long. There are standardized meanings for certain types and names (under OS/2). One such is that the ".TYPE" extended attribute is used to determine the file type. Its value comprises a list of one or more file types associated with the file, each of which is a string, such as "Plain Text" or "HTML document". Thus a file may have several types.  The NTFS filesystem also allows storage of OS/2 extended attributes, as one of the file "forks", but this feature is merely present to support the OS/2 subsystem (not present in XP), so the Win32 subsystem treats this information as an opaque block of data and does not use it. Instead, it relies on other file forks to store meta-information in Win32-specific formats. OS/2 extended attributes can still be read and written by Win32 programs, but the data must be entirely parsed by applications.

POSIX extended attributes.

On Unix and Unix-like systems, the ext2, ext3, ReiserFS version 3, XFS, JFS, FFS, and HFS+ filesystems allow the storage of extended attributes with files. These include an arbitrary list of "name=value" strings, where the names are unique and a value can be accessed through its related name.

PRONOM unique identifiers (PUIDs).

The PRONOM Persistent Unique Identifier (PUID) is an extensible scheme of persistent, unique and unambiguous identifiers for file formats, which has been developed by The National Archives of the UK as part of its PRONOM technical registry service. PUIDs can be expressed as Uniform Resource Identifiers using the namespace. Although not yet widely used outside of UK government and some digital preservation programmes, the PUID scheme does provide greater granularity than most alternative schemes.

MIME types.

MIME types are widely used in many Internet-related applications, and increasingly elsewhere, although their usage for on-disc type information is rare. These consist of a standardised system of identifiers (managed by IANA) consisting of a "type" and a "sub-type", separated by a slash—for instance, or. These were originally intended as a way of identifying what type of file was attached to an e-mail, independent of the source and target operating systems. MIME types identify files on BeOS, AmigaOS 4.0 and MorphOS, as well as store unique application signatures for application launching. In AmigaOS and MorphOS the Mime type system works in parallel with Amiga specific Datatype system.  There are problems with the MIME types though; several organisations and people have created their own MIME types without registering them properly with IANA, which makes the use of this standard awkward in some cases.

File format identifiers (FFIDs).

File format identifiers is another, not widely used way to identify file formats according to their origin and their file category. It was created for the Description Explorer suite of software. It is composed of several digits of the form. The first part indicates the organisation origin/maintainer (this number represents a value in a company/standards organisation database), the 2 following digits categorize the type of file in hexadecimal. The final part is composed of the usual filename extension of the file or the international standard number of the file, padded left with zeros. For example, the PNG file specification has the FFID of where indicates an image file, is the standard number and indicates the International Organization for Standardization (ISO).

File content based format identification.

Another but less popular way to identify the file format is to examine the file contents for distinguishable patterns among file types. The contents of a file are a sequence of bytes and a byte has 256 unique permutations (0–255). Thus, counting the occurrence of byte patterns that is often referred as byte frequency distribution gives distinguishable patterns to identify file types. There are many content-based file type identification schemes that use byte frequency distribution to build the representative models for file type and use any statistical and data mining techniques to identify file types

File structure.

There are several types of ways to structure data in a file. The most usual ones are described below.

Unstructured formats (raw memory dumps).

Earlier file formats used raw data formats that consisted of directly dumping the memory images of one or more structures into the file.  This has several drawbacks. Unless the memory images also have reserved spaces for future extensions, extending and improving this type of structured file is very difficult. It also creates files that might be specific to one platform or programming language (for example a structure containing a Pascal string is not recognized as such in C). On the other hand, developing tools for reading and writing these types of files is very simple.  The limitations of the unstructured formats led to the development of other types of file formats that could be easily extended and be backward compatible at the same time.

Chunk-based formats.

In this kind of file structure, each piece of data is embedded in a container that somehow identifies the data. The container's scope can be identified by start- and end-markers of some kind, by an explicit length field somewhere, or by fixed requirements of the file format's definition.  Throughout the 1970s, many programs used formats of this general kind. For example, word-processors such as troff, Script, and Scribe, and database export files such as CSV. Electronic Arts and Commodore-Amiga also used this type of file format in 1985, with their IFF (Interchange File Format) file format.  A container is sometimes called a ""chunk"", although "chunk" may also imply that each piece is small, and/or that chunks do not contain other chunks; many formats do not impose those requirements.  The information that identifies a particular "chunk" may be called many different things, often terms including "field name", "identifier", "label", or "tag". The identifiers are often human-readable, and classify parts of the data: for example, as a "surname", "address", "rectangle", "font name", etc. These are not the same thing as identifiers in the sense of a database key or serial number (although an identifier may well identify its associated data as such a key).  With this type of file structure, tools that do not know certain chunk identifiers simply skip those that they do not understand. Depending on the actual meaning of the skipped data, this may or may not be useful (CSS explicitly defines such behavior).  This concept has been used again and again by RIFF (Microsoft-IBM equivalent of IFF), PNG, JPEG storage, DER (Distinguished Encoding Rules) encoded streams and files (which were originally described in CCITT X.409:1984 and therefore predate IFF), and Structured Data Exchange Format (SDXF).  Indeed, any data format must somehow identify the significance of its component parts, and embedded boundary-markers are an obvious way to do so:

Directory-based formats.

This is another extensible format, that closely resembles a file system (OLE Documents are actual filesystems), where the file is composed of 'directory entries' that contain the location of the data within the file itself as well as its signatures (and in certain cases its type). Good examples of these types of file structures are disk images, OLE documents TIFF, libraries. ODT and DOCX, being PKZIP-based are chunked and also carry a directory.

A file format is a standard way that information is encoded for storage in a computer file. It specifies how bits are used to encode information in a digital storage medium. File formats may be either proprietary or free and may be either unpublished or open.

Ein Dateiformat definiert die Syntax (erlaubte Werte, formaler Aufbau/„Grammatik“) und Semantik (Bedeutung und Interpretation) von Daten innerhalb einer Datei. Es stellt damit eine bidirektionale Abbildung von Information auf einen eindimensionalen binären Speicher dar.


Background.

Book one of "Ars amatoria" was written to show a man how to find a woman. In book two, Ovid shows how to keep her. The third book, written two years after the first books were published, gives women advice on how to win and keep the love of a man ("I have just armed the Greeks against the Amazons; now, Penthesilea, it remains for me to arm thee against the Greeks...")..

Content.

The first two books, aimed at men, contain sections which cover such topics as 'not forgetting her birthday', 'letting her miss you - but not for long' and 'not asking about her age'. The third gives similar advice to women, sample themes include:'making up, but in private', 'being wary of false lovers' and 'trying young and older lovers'. Although the book was finished around 2 AD, much of the advice he gives is applicable to any day and age. His intent is often more profound than the brilliance of the surface suggests. In connection with the revelation that the theatre is a good place to meet girls, for instance, Ovid, the classically educated trickster, refers to the story of the rape of the Sabine women. It has been argued that this passage represents a radical attempt to redefine relationships between men and women in Roman society, advocating a move away from paradigms of force and possession, towards concepts of mutual fulfilment.  The superficial brilliance, however, befuddles even scholars (paradoxically, Ovid consequently tended in the 20th century to be underrated as lacking in seriousness). The standard situations and clichés of the subject are treated in an entertainment-intended way, with details from Greek mythology, everyday Roman life and general human experience. Ovid likens love to military service, supposedly requiring the strictest obedience to the woman. He advises women to make their lovers artificially jealous so that they do not become neglectful through complacency. Perhaps accordingly, a slave should be instructed to interrupt the lovers' tryst with the cry 'Perimus' ('We are lost!'), compelling the young lover to hide in fear in a cupboard. The tension implicit in this uncommitted tone is reminiscent of a flirt, and in fact, the semi-serious, semi-ironic form is ideally suited to Ovid's subject matter.  It is striking that through all his ironic discourse, Ovid never becomes ribald or obscene. Of course 'embarrassing' matters can never be entirely excluded, for 'praecipue nostrum est, quod pudet, inquit, opus' 'what brings a blush... is our especial business here'. Sexual matters in the narrower sense are only dealt with at the end of each book, so here again, form and content converge in a subtly ingenious way. Things, so to speak, always end up in bed. But here, too, Ovid retains his style and his discretion, avoiding any pornographic tinge. The end of the second book deals with the pleasures of simultaneous orgasm. Somewhat atypically for a Roman, the poet confesses, "Odi concubitus, qui non utrumque resolvunt. Hoc est, cur pueri tangar amore minus" ('I don't like intercourse that doesn't make both lovers come. That's why I'm less into the love of boys.').  At the end of the third part, as in the Kama Sutra, the sexual positions are 'declined', and from them women are exhorted to choose the most suitable, taking the proportions of their own bodies into careful consideration. Ovid's tongue is again discovered in his cheek when his recommendation that tall women should not straddle their lovers is exemplified at the expense of the tallest hero of the Trojan Wars: "Quod erat longissima, numquam Thebais Hectoreo nupta resedit equo" ('Since she was very tall, the daughter of Thebes (Andromache) as wife never mounted Hector as horse').  However, the word "ars" in the title is not to be translated coldly as 'technique', or as 'art' in the sense of civilized refinement, but as "textbook", the literal and antique definition of the word.  Appropriately for its subject, the "Ars amatoria" is composed in elegiac couplets, rather than the dactylic hexameters, which are more usually associated with the didactic poem.

Reception.

The work was such a popular success that the poet wrote a sequel, "Remedia Amoris" (Remedies for Love). At an early "recitatio", however, S. Vivianus Rhesus is noted as having walked out in disgust.  The assumption that the 'licentiousness' of the "Ars amatoria" was responsible in part for Ovid's relegation (banishment) by Augustus in 8 AD is dubious, and seems rather to reflect modern sensibilities than historical fact. For one thing, the work had been in circulation for eight years by the time of the relegation, and it postdates the Julian Marriage Laws by eighteen years. Secondly, it is hardly likely that Augustus, after forty years unchallenged in the purple, felt the poetry of Ovid to be a serious threat or even embarrassment to his social policies. Thirdly, Ovid's own statement from his Black Sea exile that his relegation was because of 'carmen et error' ('a song and a mistake') is, for many reasons, hardly admissible.  It is more probable that Ovid was somehow caught up in factional politics connected with the succession: Agrippa Postumus, Augustus' adopted son, and Augustus' granddaughter, Vipsania Julilla, were both relegated at around the same time. This would also explain why Ovid was not reprieved when Augustus was succeeded by Agrippa's rival Tiberius. It is likely, then, that the "Ars amatoria" was used as an excuse for the relegation. This would be neither the first nor the last time a 'crackdown on immorality' disguised an uncomfortable political secret.

Legacy.

The "Ars amatoria" created considerable interest at the time of its publication. On a lesser scale, Martial's epigrams take a similar context of advising readers on love. Modern literature has been continually influenced by the "Ars amatoria", which has presented additional information on the relationship between Ovid's poem and more current writings. The "Ars amatoria" was included in the syllabuses of mediaeval schools from the second half of the 11th century, and its influence on 12th and 13th centuries' European literature was so great that the German mediaevalist and palaeographer Ludwig Traube dubbed the entire age 'aetas Ovidiana' ('the Ovidian epoch').  As in the years immediately following its publication, the "Ars amatoria" has historically been victim of moral outcry. All of Ovid's works were burned by Savonarola in Florence, Italy in 1497; an English translation of the "Ars amatoria" was seized by U.S. Customs in 1930. Despite the actions against the work, it continues to be studied in college courses on Latin literature.  It is possible that Edmond Rostand's fictionalized portrayal of Cyrano de Bergerac makes an allusion to the "Ars amatoria": the theme of the erotic and seductive power of poetry is highly suggestive of Ovid's poem, and Bergerac's nose, a distinguishing feature invented by Rostand, calls to mind Ovid's cognomen, Naso (from "nasus", 'large-nosed').

The Ars amatoria () is an instructional elegy series in three books by the ancient Roman poet Ovid. It was written in 2 AD.

Ars amatoria, auch Ars amandi (lat. "Liebeskunst"), ist ein Lehrgedicht in drei Büchern des römischen Dichters Ovid, entstanden zwischen 1 v. Chr. und 4 n. Chr.


History.

In 1987, AT&T Corporation and Sun announced that they were collaborating on a project to merge the most popular Unix variants on the market at that time: Berkeley Software Distribution, UNIX System V, and Xenix. This became Unix System V Release 4 (SVR4).  On September 4, 1991, Sun announced that it would replace its existing BSD-derived Unix, SunOS 4, with one based on SVR4. This was identified internally as "SunOS 5", but a new marketing name was introduced at the same time: "Solaris 2". The justification for this new overbrand was that it encompassed not only SunOS, but also the OpenWindows graphical user interface and Open Network Computing (ONC) functionality.  Although SunOS 4.1."x" micro releases were retroactively named "Solaris 1" by Sun, the Solaris name is used almost exclusively to refer only to the releases based on SVR4-derived SunOS 5.0 and later.  For releases based on SunOS 5, the SunOS minor version is included in the Solaris release number. For example, Solaris 2.4 incorporates SunOS 5.4. After Solaris 2.6, the "2." was dropped from the release name, so Solaris 7 incorporates SunOS 5.7, and the latest release SunOS 5.11 forms the core of Solaris 11.4.  Although SunSoft stated in its initial Solaris 2 press release their intent to eventually support both SPARC and x86 systems, the first two Solaris 2 releases, 2.0 and 2.1, were SPARC-only. An x86 version of Solaris 2.1 was released in June 1993, about 6 months after the SPARC version, as a desktop and uniprocessor workgroup server operating system. It included the Wabi emulator to support Windows applications. At the time, Sun also offered the Interactive Unix system that it had acquired from Interactive Systems Corporation. In 1994, Sun released Solaris 2.4, supporting both SPARC and x86 systems from a unified source code base.  On September 2, 2017, Simon Phipps, a former Sun Microsystems employee not hired by Oracle in the acquisition, reported on Twitter that Oracle had laid off the Solaris core development staff, which many interpreted as sign that Oracle no longer intended to support future development of the platform. While Oracle did have a large layoff of Solaris development engineering staff, development continues today of which Solaris 11.4 was released in 2018.

Supported architectures.

Solaris uses a common code base for the platforms it supports: SPARC and i86pc (which includes both x86 and x86-64).  Solaris has a reputation for being well-suited to symmetric multiprocessing, supporting a large number of CPUs. It has historically been tightly integrated with Sun's SPARC hardware (including support for 64-bit SPARC applications since Solaris 7), with which it is marketed as a combined package. This has led to more reliable systems, but at a cost premium compared to commodity PC hardware. However, it has supported x86 systems since Solaris 2.1 and 64-bit x86 applications since Solaris 10, allowing Sun to capitalize on the availability of commodity 64-bit CPUs based on the x86-64 architecture. Sun has heavily marketed Solaris for use with both its own "x64" workstations and servers based on AMD Opteron and Intel Xeon processors, as well as x86 systems manufactured by companies such as Dell, Hewlett-Packard, and IBM. As of 2009, the following vendors support Solaris for their x86 server systems: As of July 2010, Dell and HP certify and resell Oracle Solaris, Oracle Enterprise Linux and Oracle VM on their respective x86 platforms, and IBM stopped direct support for Solaris on x64 kit.

Other platforms.

Solaris 2.5.1 included support for the PowerPC platform (PowerPC Reference Platform), but the port was canceled before the Solaris 2.6 release. In January 2006, a community of developers at Blastwave began work on a PowerPC port which they named "Polaris". In October 2006, an OpenSolaris community project based on the Blastwave efforts and Sun Labs' "Project Pulsar", which re-integrated the relevant parts from Solaris 2.5.1 into OpenSolaris, announced its first official source code release.  A port of Solaris to the Intel Itanium architecture was announced in 1997 but never brought to market.  On November 28, 2007, IBM, Sun, and Sine Nomine Associates demonstrated a preview of OpenSolaris for System z running on an IBM System z mainframe under z/VM, called "Sirius" (in analogy to the Polaris project, and also due to the primary developer's Australian nationality: HMS "Sirius" of 1786 was a ship of the First Fleet to Australia). On October 17, 2008, a prototype release of Sirius was made available and on November 19 the same year, IBM authorized the use of Sirius on System z Integrated Facility for Linux (IFL) processors.  Solaris also supports the Linux platform application binary interface (ABI), allowing Solaris to run native Linux binaries on x86 systems. This feature is called "Solaris Containers for Linux Applications" (SCLA), based on the branded zones functionality introduced in Solaris 10 8/07.

Installation and usage options.

Solaris can be installed from various pre-packaged software groups, ranging from a minimalistic "Reduced Network Support" to a complete "Entire Plus OEM". Installation of Solaris is not necessary for an individual to use the system. Additional software, like Apache, MySQL, etc. can be installed as well in a packaged form from "sunfreeware" and OpenCSW. Solaris can be installed from physical media or a network for use on a desktop or server, or be used without installing on a desktop or server.

Desktop environments.

Early releases of Solaris used OpenWindows as the standard desktop environment. In Solaris 2.0 to 2.2, OpenWindows supported both NeWS and X applications, and provided backward compatibility for SunView applications from Sun's older desktop environment. NeWS allowed applications to be built in an object-oriented way using PostScript, a common printing language released in 1982. The X Window System originated from MIT's Project Athena in 1984 and allowed for the display of an application to be disconnected from the machine where the application was running, separated by a network connection. Sun's original bundled SunView application suite was ported to X.  Sun later dropped support for legacy SunView applications and NeWS with OpenWindows 3.3, which shipped with Solaris 2.3, and switched to X11R5 with Display Postscript support. The graphical look and feel remained based upon OPEN LOOK. OpenWindows 3.6.2 was the last release under Solaris 8. The OPEN LOOK Window Manager (olwm) with other OPEN LOOK specific applications were dropped in Solaris 9, but support libraries were still bundled, providing long term binary backwards compatibility with existing applications. The OPEN LOOK Virtual Window Manager (olvwm) can still be downloaded for Solaris from sunfreeware and works on releases as recent as Solaris 10.  Sun and other Unix vendors created an industry alliance to standardize Unix desktops. As a member of the Common Open Software Environment (COSE) initiative, Sun helped co-develop the Common Desktop Environment (CDE). This was an initiative to create a standard Unix desktop environment. Each vendor contributed different components: Hewlett-Packard contributed the window manager, IBM provided the file manager, and Sun provided the e-mail and calendar facilities as well as drag-and-drop support (ToolTalk). This new desktop environment was based upon the Motif look and feel and the old OPEN LOOK desktop environment was considered legacy. CDE unified Unix desktops across multiple open system vendors. CDE was available as an unbundled add-on for Solaris 2.4 and 2.5, and was included in Solaris 2.6 through 10.  In 2001, Sun issued a preview release of the open-source desktop environment GNOME 1.4, based on the GTK+ toolkit, for Solaris 8. Solaris 9 8/03 introduced GNOME 2.0 as an alternative to CDE. Solaris 10 includes Sun's Java Desktop System (JDS), which is based on GNOME and comes with a large set of applications, including StarOffice, Sun's office suite. Sun describes JDS as a "major component" of Solaris 10. The Java Desktop System is not included in Solaris 11 which instead ships with a stock version of GNOME. Likewise, CDE applications are no longer included in Solaris 11, but many libraries remain for binary backwards compatibility.  The open source desktop environments KDE and Xfce, along with numerous other window managers, also compile and run on recent versions of Solaris.  Sun was investing in a new desktop environment called Project Looking Glass since 2003. The project has been inactive since late 2006.

License.

Traditional operating system license (1982 to 2004).

For versions up to 2005 (Solaris 9), Solaris was licensed under a license that permitted a customer to buy licenses in bulk, and install the software on any machine up to a maximum number. The key license grant was:  In addition, the license provided a "License to Develop" granting rights to create derivative works, restricted copying to only a single archival copy, disclaimer of warranties, and the like. The license varied only little through 2004.

Open source (2005 until March 2010).

From 2005–10, Sun began to release the source code for development builds of Solaris under the Common Development and Distribution License (CDDL) via the OpenSolaris project. This code was based on the work being done for the post-Solaris 10 release (code-named "Nevada"; eventually released as Oracle Solaris 11). As the project progressed, it grew to encompass most of the necessary code to compile an entire release, with a few exceptions.

Post-Oracle closed source (March 2010 to present).

When Sun was acquired by Oracle in 2010, the OpenSolaris project was discontinued after the board became unhappy with Oracle's stance on the project. In March 2010, the previously freely available Solaris 10 was placed under a restrictive license that limited the use, modification and redistribution of the operating system. The license allowed the user to download the operating system free of charge, through the Oracle Technology Network, and use it for a 90-day trial period. After that trial period had expired the user would then have to purchase a support contract from Oracle to continue using the operating system.  With the release of Solaris 11 in 2011, the license terms changed again. The new license allows Solaris 10 and Solaris 11 to be downloaded free of charge from the Oracle Technology Network and used without a support contract indefinitely; however, the license only expressly permits the user to use Solaris as a development platform and expressly forbids commercial and "production" use. Educational use is permitted in some circumstances. From the OTN license:  When Solaris is used without a support contract it can be upgraded to each new "point release"; however, a support contract is required for access to patches and updates that are released monthly.

Version history.

Notable features of Solaris include DTrace, Doors, Service Management Facility, Solaris Containers, Solaris Multiplexed I/O, Solaris Volume Manager, ZFS, and Solaris Trusted Extensions.  Updates to Solaris versions are periodically issued. In the past, these were named after the month and year of their release, such as "Solaris 10 1/13"; as of Solaris 11, sequential update numbers are appended to the release name with a period, such as "Oracle Solaris 11.4".  In ascending order, the following versions of Solaris have been released:  A more comprehensive summary of some Solaris versions is also available. Solaris releases are also described in the Solaris 2 FAQ.

Development release.

The underlying Solaris codebase has been under continuous development since work began in the late 1980s on what was eventually released as Solaris 2.0. Each version such as Solaris 10 is based on a snapshot of this development codebase, taken near the time of its release, which is then maintained as a derived project. Updates to that project are built and delivered several times a year until the next official release comes out.  The Solaris version under development by Sun since the release of Solaris 10 in 2005, was codenamed "Nevada", and is derived from what is now the OpenSolaris codebase.  In 2003, an addition to the Solaris development process was initiated. Under the program name "Software Express for Solaris" (or just "Solaris Express"), a binary release based on the current development basis was made available for download on a monthly basis, allowing anyone to try out new features and test the quality and stability of the OS as it progressed to the release of the next official Solaris version. A later change to this program introduced a quarterly release model with support available, renamed "Solaris Express Developer Edition" (SXDE).  In 2007, Sun announced "Project Indiana" with several goals, including providing an open source binary distribution of the OpenSolaris project, replacing SXDE. The first release of this distribution was "OpenSolaris 2008.05". The "Solaris Express Community Edition" (SXCE) was intended specifically for OpenSolaris developers. It was updated every two weeks until it was discontinued in January 2010, with a recommendation that users migrate to the OpenSolaris distribution. Although the download license seen when downloading the image files indicates its use is limited to personal, educational and evaluation purposes, the license acceptance form displayed when the user actually installs from these images lists additional uses including commercial and production environments.  SXCE releases terminated with build 130 and OpenSolaris releases terminated with build 134 a few weeks later. The next release of OpenSolaris based on build 134 was due in March 2010, but it was never fully released, though the packages were made available on the package repository. Instead, Oracle renamed the binary distribution Solaris 11 Express, changed the license terms and released build 151a as 2010.11 in November 2010.

Solaris is a proprietary Unix operating system originally developed by Sun Microsystems. It superseded the company's earlier SunOS in 1993. In 2010, after the Sun acquisition by Oracle, it was renamed Oracle Solaris.

Oracle Solaris ist eine Betriebssystemdistribution auf Basis von SunOS und ein Unix-Betriebssystem. Seit der Übernahme von Sun Microsystems 2010 gehört Solaris dem Unternehmen Oracle.


Occurrence.

The geological type area for labradorite is Paul's Island near the town of Nain in Labrador, Canada. It has also been reported in Norway, Finland and various other locations worldwide, with notable distribution in Madagascar, China, Australia, Slovakia and the USA.  Labradorite occurs in mafic igneous rocks and is the feldspar variety most common in basalt and gabbro. The uncommon anorthosite bodies are composed almost entirely of labradorite. It also is found in metamorphic amphibolites and as a detrital component of some sediments. Common mineral associates in igneous rocks include olivine, pyroxenes, amphiboles and magnetite.

Labradorescence.

Labradorite can display an iridescent optical effect (or "schiller") known as labradorescence. The term "labradorescence" was coined by Ove Balthasar Bøggild, who defined it (labradorization) as follows:  Contributions to the understanding of the origin and cause of the effect were made by Robert Strutt, 4th Baron Rayleigh (1923), and by Bøggild (1924).  The cause of this optical phenomenon is phase exsolution lamellar structure, occurring in the Bøggild miscibility gap. The effect is visible when the lamellar separation is between ; the lamellae are not necessarily parallel; and the lamellar structure is found to lack long range order.  The lamellar separation only occurs in plagioclases of a certain composition; those of calcic labradorite and bytownite (anorthite content of ~60 to 90%) particularly exemplify this. Another requirement for the lamellar separation is very slow cooling of the rock that contains the plagioclase. Slow cooling is required to allow the Ca, Na, Si, and Al ions to diffuse through the plagioclase and produce the lamellar separation. Therefore, not all labradorites exhibit labradorescence (they might not be the correct composition and/or they cooled too quickly), and not all plagioclases that exhibit labradorescence are labradorites (they may be bytownite).  Some gemstone varieties of labradorite exhibiting a high degree of labradorescence are called spectrolite.

Labradorite ((Ca, Na)(Al, Si)O), a feldspar mineral, is an intermediate to calcic member of the plagioclase series. It has an anorthite percentage (%An) of between 50 and 70. The specific gravity ranges from 2.68 to 2.72. The streak is white, like most silicates. The refractive index ranges from 1.559 to 1.573 and twinning is common. As with all plagioclase members, the crystal system is triclinic, and three directions of cleavage are present, two of which are nearly at right angles and are more obvious, being of good to perfect quality. (The third direction is poor.) It occurs as clear, white to gray, blocky to lath shaped grains in common mafic igneous rocks such as basalt and gabbro, as well as in anorthosites.

Labradorit gilt wie Andesin heute nicht mehr als eigenständiges Mineral, sondern ist ein Plagioklas, eine relativ häufig vorkommende Mineralmischung aus Albit und Anorthit aus der Gruppe der Feldspate und der Mineralklasse der Silikate. Sein Anorthitgehalt beträgt definitionsgemäß 50 bis 70 % (An).


Early studies.

At the beginning of the 20th century, Wilhelm von Osten famously, but prematurely, claimed human-like counting abilities in animals on the example of his horse named Hans. His claim is widely rejected today, as it is attributed to a methodological fallacy, which received the name Clever Hans phenomenon after this case. Von Osten claimed that his horse could perform arithmetic operations presented to the horse in writing or verbally, upon which the horse would knock on the ground with its hoof the number of times that corresponded to the answer. This apparent ability was demonstrated numerous times in the presence of the horse's owner and a wider audience, and was also observed when the owner was absent. However, upon a rigorous investigation by Oskar Pfungst in the first decade of 20th century, Hans' ability was shown to be not arithmetic in nature, but to be the ability to interpret minimal unconscious changes in body language of people when the correct answer was approaching. Today, the arithmetic abilities of Clever Hans are commonly rejected and the case serves as a reminder to the scientific community about the necessity of rigorous control for experimenter expectation in experiments.  There were, however, other early and more reliable studies on number sense in animals. A prominent example is the work of Otto Koehler, who conducted a number of studies on number sense in animals between 1920s and 1970s. In one of his studies he showed that a raven named Jacob could reliably distinguish the number 5 across different tasks. This study was remarkable in that Koehler provided a systematic control condition in his experiment, which allowed him to test the number ability of the raven separately from the ability of the raven to encode other features, such as size and location of the objects. However, Koehler's work was largely overlooked in the English-speaking world, due to the limited availability of his publications, which were in German and partially published during World War II.  The experimental setup for the study of numerical cognition in animals was further enriched by the work of Francis and Platt and Johnson. In their experiments, the researchers deprived rats of food and then taught them to press a lever a specific number of times to obtain food. The rats learned to press the lever approximately the number of times specified by the researchers. Additionally, the researchers showed that rats' behavior was dependent on the number of required presses, and not for example on the time of pressing, as they varied the experiment to include faster and slower behavior on the rat's part by controlling how hungry the animal was.

Methodology.

Examining the representation of numerosity in animals is a challenging task, since it is not possible to use language as a medium. Because of this, carefully designed experimental setups are required to differentiate between numerical abilities and other phenomena, such as the Clever Hans phenomenon, memorization of the single objects or perception of object size and time. Also, these abilities are seen only from the past few decades and not from the time of evolution.  One of the ways that numerical ability is thought to be demonstrated is the transfer of the concept of numerosity across modalities. This was for example the case in the experiment of Church and Meck, in which rats learned to "add" the number of light flashes to the number of tones to find out the number of expected lever presses, showing a concept of numerosity independent of visual and auditory modalities.  Modern studies in number sense in animals try to control for other possible explanations of animal behavior by establishing control conditions in which the other explanations are tested. For example, when the number sense is investigated on the example of apple pieces, an alternative explanation is tested that assumes that the animal represents the volume of apple rather than a number of apple pieces. To test this alternative, an additional condition is introduced in which the volume of the apple varies and is occasionally smaller in the condition with a greater number of pieces. If the animal prefers a bigger number of pieces also in this condition, the alternative explanation is rejected, and the claim of numerical ability supported.

Approximate number and parallel individuation systems.

Numerosity is believed to be represented by two separate systems in animals, similarly to humans. The first system is the approximate number system, an imprecise system used for estimations of quantities. This system is distinguished by distance and magnitude effects, which means that a comparison between numbers is easier and more precise when the distance between them is smaller and when the values of the numbers are smaller. The second system for representation of numerosity is the parallel individuation system which supports the exact representation of numbers from 1 to 4. In addition, humans can represent numbers through symbolic systems, such as language.  The distinction between the approximate number system and the parallel individuation system is, however, still disputed, and some experiments record behavior that can be fully explained with the approximate number system, without the need to assume another separate system for smaller numbers. For example, New Zealand robins repeatedly selected larger quantities of cached food with a precision that correlated with the total number of cache pieces. However, there was no significant discontinuity in their performance between small (1 to 4) and larger (above 4) sets, which would be predicted by the parallel individuation system. On the other hand, other experiments only report knowledge of numbers up to 4, supporting the existence of the parallel individuation system and not the approximate number system.

Number sense by species.

Fish.

An approximate number system has been found in a number of fish species, such as guppies, green swordtails and mosquitofish. For example, preference for a bigger social group in mosquitofish was exploited to test the ability of the fish to discriminate numerosity. The fish successfully discriminated between different amounts up to three, after which they could discriminate groups if the difference between them also increased so that the ratio of the two groups was 1:2. Similarly, guppies discriminated between values up to 4, after which they only detected differences when the ratio between the two quantities was 1:2.

Rats.

Rats have demonstrated behavior consistent with an approximate number system in experiments where they had to learn to press a lever a specified number of times to obtain food. While they did learn to press the lever the amount specified by the researchers, between 4 and 16, their behavior was approximate, proportional to the number of lever presses expected from them. This means that for the target number of 4, the rats' responses varied from 3 to 7, and for the target number of 16 the responses varied from 12 to 24, showing a much greater interval. This is compatible with the approximate number system and magnitude and distance effects.

Birds.

Birds were one of the first animal species tested on their number sense. A raven named Jacob was able to distinguish the number 5 across different tasks in the experiments by Otto Koehler. Later experiments supported the claim of existence of a number sense in birds, with Alex, a grey parrot, able to label and comprehend labels for sets with up to six elements. Other studies suggest that pigeons can also represent numbers up to 6 after an extensive training.

Dogs.

A sense of number has also been found in dogs. For example, dogs were able to perform simple additions of two objects, as revealed by their surprise when the result was incorrect. It is however argued that wolves perform better on quantity discrimination tasks than dogs and that this could be a result of a less demanding natural selection for number sense in dogs.

Monkeys.

Rhesus monkeys seem to have an innate understanding of numbers up to 4. This is shown by the study on semi-free-ranging rhesus monkeys in their natural environment in which the monkeys spontaneously discriminated numbers from 1 to 3 but did not demonstrate a numerical ability beyond this number. In another study that included training, rhesus monkeys showed the ability to generalize this knowledge to numerosities up to nine.

Chimpanzees.

Chimpanzees are believed to have a sense of number, albeit an imprecise one. While they can correctly compare numbers such as 6 and 7 by choosing a tray with more pieces of reward, their performance is more error-free when the difference between the numbers is bigger and when the numbers are smaller; that is when the distance and magnitude effects take place. Chimpanzees also seem to have knowledge of proportions. In an experiment by Woodroof and Premack an adult chimpanzee correctly identified and performed operations on exemplars of numbers and proportions presented on a variety of objects, such as apples, wood disks and water containers. For example, when presented with of an apple and full water container, the chimpanzee chose of a wooden disk, suggesting an addition-like ability. The ability to add fractions has only been demonstrated in primates so far.

Ants.

Ants were shown to be able to count up to 20 and add and subtract numbers within 5. In highly social species such as red wood ants scouting individuals can transfer to foragers the information about the number of branches of a special “counting maze” they had to go to in order to obtain syrup. The findings concerning number sense in ants are based on comparisons of duration of information contacts between scouts and foragers which preceded successful trips by the foraging teams. Similar to some archaic human languages, the length of the code of a given number in ants’ communication is proportional to its value. In experiments in which the bait appeared on different branches with different frequencies, the ants used simple additions and subtractions to optimize their messages.

Wild rodents.

Striped field mice Apodemus agrarius demonstrated a sense of number consistent with precise relative-quantity judgment: some of these mice exhibit high accuracy in discriminating between quantities that differ only by one. The latter include both small (such as 2 versus 3) and relatively large (such as 5 versus 6, and 8 versus 9) quantities of elements.

Number sense in animals is the ability of creatures to represent and discriminate quantities of relative sizes by number sense. It has been observed in various species, from fish to primates. Animals are believed to have an approximate number system, the same system for number representation demonstrated by humans, which is more precise for smaller quantities and less so for larger values. An exact representation of numbers higher than 3 has not been attested in wild animals, but can be demonstrated after a period of training in captive animals.

Die Unterscheidung von Mengen bei Tieren (engl.: "numerosity") sowie die Generalisierung von Anzahlen (engl.: "number estimation") wurde in zahlreichen, voneinander unabhängigen verhaltensbiologischen Experimenten nachgewiesen. Insbesondere einige in Japan und in den USA mit Schimpansen – den nächsten Verwandten des Menschen – durchgeführte Studien lassen den Schluss zu, dass einfache mathematische Fähigkeiten nicht auf den Menschen beschränkt sind. Der Nachweis, dass Tiere unterschiedlicher Arten fähig sind, Anzahlen (und einige von ihnen auch Zahlen) zu unterscheiden, könnte, wenn eines Tages hinreichend viele Studien vorliegen sollten, einen Hinweis darauf geben, wie sich die Fähigkeit zum Rechnen im Verlauf der Stammesgeschichte der Arten entwickelt hat.


History.

Württemberg-Baden consisted of the northern halves of the former states of Württemberg and Baden. The southern border of this part of the US-administered zone was set so that the autobahn connecting Karlsruhe and Munich (today the A8) was completely contained within the American zone. The three major subdivisions of the American zone (Greater Hesse, Bavaria and Württemberg-Baden) were declared on 19 September 1945.  On 24 November 1946, a new constitution was enacted and Württemberg-Baden's first parliament was elected. On 23 May 1949, the state became a founding member of the Federal Republic of Germany. A straw poll was held on 24 September 1950 in Württemberg-Baden, Württemberg-Hohenzollern and Baden regarding a merger of the three states, followed by a public referendum on 16 December 1951. On both occasions, voters in Württemberg-Baden returned a clear majority in favour of a merger. All three states were merged and the modern German state of Baden-Württemberg was founded on 25 April 1952.

Politics.

The only minister-president of Württemberg-Baden was Reinhold Maier (DVP, then FDP; 1946–1952). Maier went on to become the first minister-president of Baden-Württemberg upon its formation in 1952.  Württemberg-Baden was subdivided into two administrative districts, known as "Landesbezirke". The boundaries for these two districts were taken from two former state sections that comprised Württemberg-Baden. These two districts remain largely unchanged today as the Regierungsbezirke of Stuttgart (Württemberg) and Karlsruhe (Baden) within Baden-Württemberg.

Flag and coat of arms.

The flag of Württemberg-Baden, adopted in 1947, was the black-red-gold tricolour flag of Germany which was later also adopted again by the new German states founded in 1949, the Federal Republic of Germany and the German Democratic Republic.  The coat of arms merges elements from the two predecessor states: the red stripe on a golden field of the coat of arms of Baden and the three deer antlers of the coat of arms of Württemberg.

Württemberg-Baden was a state of the Federal Republic of Germany. It was created in 1945 by the United States occupation forces, after the previous states of Baden and Württemberg had been split up between the US and French occupation zones. Its capital was Stuttgart. In 1952, Württemberg-Baden merged with Württemberg-Hohenzollern and Baden into the present state of Baden-Württemberg.

Das Land Württemberg-Baden wurde 1945 von der US-amerikanischen Militärregierung gegründet und war ab 1949 ein Land der Bundesrepublik Deutschland. Das Land umfasste den nördlichen Teil der ehemaligen Republik Baden und den nördlichen Teil des ehemaligen Volksstaates Württemberg. Es ging 1952 im neugeschaffenen Land Baden-Württemberg auf.