Standard streams

In computer programming, standard streams are interconnected input and output communication channels between a computer program and its environment when it begins execution. The three input/output (I/O) connections are called standard input (stdin), standard output (stdout) and standard error (stderr). Originally I/O happened via a physically connected system console (input via keyboard, output via monitor), but standard streams abstract this. When a command is executed via an interactive shell, the streams are typically connected to the text terminal on which the shell is running, but can be changed with redirection or a pipeline. More generally, a child process inherits the standard streams of its parent process.
Application.
Users generally know standard streams as input and output channels that handle data coming from an input device, or that write data from the application. The data may be text with any encoding, or binary data.
In many modern systems, the standard error stream of a program is redirected into a log file, typically for error analysis purposes.
Streams may be used to chain applications, meaning that the output stream of one program can be redirected to be the input stream to another application. In many operating systems this is expressed by listing the application names, separated by the vertical bar character, for this reason often called the pipeline character. A well-known example is the use of a pagination application, such as more, providing the user control over the display of the output stream on the display.
Background.
In most operating systems predating Unix, programs had to explicitly connect to the appropriate input and output devices. OS-specific intricacies caused this to be a tedious programming task. On many systems it was necessary to obtain control of environment settings, access a local file table, determine the intended data set, and handle hardware correctly in the case of a punch card reader, magnetic tape drive, disk drive, line printer, card punch, or interactive terminal.
One of Unix's several groundbreaking advances was "abstract devices", which removed the need for a program to know or care what kind of devices it was communicating with. Older operating systems forced upon the programmer a record structure and frequently non-orthogonal data semantics and device control. Unix eliminated this complexity with the concept of a data stream: an ordered sequence of data bytes which can be read until the end of file. A program may also write bytes as desired and need not, and cannot easily declare their count or grouping.
Another Unix breakthrough was to automatically associate input and output to terminal keyboard and terminal display, respectively, by default — the program (and programmer) did absolutely nothing to establish input and output for a typical input-process-output program (unless it chose a different paradigm). In contrast, previous operating systems usually required some—often complex—job control language to establish connections, or the equivalent burden had to be orchestrated by the program.
Since Unix provided standard streams, the Unix C runtime environment was obliged to support it as well. As a result, most C runtime environments (and C's descendants), regardless of the operating system, provide equivalent functionality.
Standard input (stdin).
Standard input is a stream from which a program reads its input data. The program requests data transfers by use of the "read" operation. Not all programs require stream input. For example, the "dir" and "ls" programs (which display file names contained in a directory) may take command-line arguments, but perform their operations without any stream data input.
Unless redirected, standard input is inherited from the parent process. In the case of an interactive shell, that is usually associated with the keyboard.
The file descriptor for standard input is 0 (zero); the POSIX "<unistd.h>" definition is codice_1; the corresponding C "<stdio.h>" variable is codice_2; similarly, the C++ "<iostream>" variable is codice_3.
Standard output (stdout).
Standard output is a stream to which a program writes its output data. The program requests data transfer with the "write" operation. Not all programs generate output. For example, the "file rename" command (variously called "mv", "move", or "ren") is silent on success.
Unless redirected, standard output is inherited from the parent process. In the case of an interactive shell, that is usually the text terminal which initiated the program.
The file descriptor for standard output is 1 (one); the POSIX "<unistd.h>" definition is codice_4; the corresponding C "<stdio.h>" variable is codice_5; similarly, the C++ "<iostream>" variable is codice_6.
Standard error (stderr).
Standard error is another output stream typically used by programs to output error messages or diagnostics. It is a stream independent of standard output and can be redirected separately. This solves the semi-predicate problem, allowing output and errors to be distinguished, and is analogous to a function returning a pair of values – see Semi-predicate problem: Multi valued return. The usual destination is the text terminal which started the program to provide the best chance of being seen even if "standard output" is redirected (so not readily observed). For example, output of a program in a pipeline is redirected to input of the next program, but errors from each program still go directly to the text terminal.
It is acceptable and normal to direct "standard output" and "standard error" to the same destination, such as the text terminal. Messages appear in the same order as the program writes them, unless buffering is involved. For example, in common situations the standard error stream is unbuffered but the standard output stream is line-buffered; in this case, text written to standard error later may appear on the terminal earlier, if the standard output stream buffer is not yet full.
The file descriptor for standard error is defined by POSIX as 2 (two); the "<unistd.h>" header file provides the symbol codice_7; the corresponding C "<stdio.h>" variable is codice_8. The C++ "<iostream>" standard header provides two variables associated with this stream: codice_9 and codice_10, the former being unbuffered and the latter using the same buffering mechanism as all other C++ streams.
Bourne-style shells allow "standard error" to be redirected to the same destination that standard output is directed to using
 2>&1
csh-style shells allow "standard error" to be redirected to the same destination that standard output is directed to using
Standard error was added to Unix in the 1970s after several wasted phototypesetting runs ended with error messages being typeset instead of displayed on the user's terminal.
Timeline.
1950s: Fortran.
Fortran has the equivalent of Unix file descriptors: By convention, many Fortran implementations use unit numbers codice_11 for stdin, codice_12 for stdout and codice_13 for stderr. In Fortran-2003, the intrinsic codice_14 module was standardized to include the named constants codice_15, codice_16, and codice_17 to portably specify the unit numbers.
! FORTRAN 77 example
 PROGRAM MAIN
 INTEGER NUMBER
 READ(UNIT=5,*) NUMBER
 WRITE(UNIT=6,'(A,I3)') ' NUMBER IS: ',NUMBER
 END
! Fortran 2003 example
program main
 use iso_fortran_env
 implicit none
 integer :: number
 read (unit=INPUT_UNIT,*) number
 write (unit=OUTPUT_UNIT,'(a,i3)') 'Number is: ', number
end program
1960: ALGOL 60.
ALGOL 60 was criticized for having no standard file access.
1968: ALGOL 68.
ALGOL 68's input and output facilities were collectively referred to as the transput. Koster coordinated the definition of the "transput" standard. The model included three standard channels: codice_18, codice_19, and codice_20.
1970s: C and Unix.
In the C programming language, the standard input, output, and error streams are attached to the existing Unix file descriptors 0, 1 and 2 respectively. In a POSIX environment the "<unistd.h>" definitions "STDIN_FILENO", "STDOUT_FILENO" or "STDERR_FILENO" should be used instead rather than magic numbers. File pointers "stdin", "stdout", and "stderr" are also provided.
Ken Thompson (designer and implementer of the original Unix operating system) modified sort in Version 5 Unix to accept "-" as representing standard input, which spread to other utilities and became a part of the operating system as a special file in Version 8. Diagnostics were part of standard output through Version 6, after which Dennis M. Ritchie created the concept of standard error.
1995: Java.
In Java, the standard streams are referred to by (for stdin), (for stdout), and (for stderr).
public static void main(String args[]) {
 try {
 BufferedReader br =
 new BufferedReader(new InputStreamReader(System.in));
 String s = br.readLine();
 double number = Double.parseDouble(s);
 System.out.println("Number is:" + number);
 } catch (Exception e) {
 System.err.println("Error:" + e.getMessage());
2000s: .NET.
In C# and other .NET languages, the standard streams are referred to by codice_21 (for stdin), codice_22 (for stdout) and codice_23 (for stderr). Basic read and write capabilities for the stdin and stdout streams are also accessible directly through the class codice_24 (e.g. codice_25 can be used instead of codice_26).
codice_21, codice_22 and codice_23 are codice_30 (stdin) and codice_31 (stdout, stderr) objects, which only allow access to the underlying standard streams on a text basis. Full binary access to the standard streams must be performed through the codice_32 objects returned by codice_33, codice_34 and codice_35 respectively.
// C# example
public static int Main(string[] args)
 try {
 string s = System.Console.In.ReadLine();
 double number = double.Parse(s);
 System.Console.Out.WriteLine("Number is: {0:F3}", number);
 return 0;
 // If Parse() threw an exception
 } catch (ArgumentNullException) {
 System.Console.Error.WriteLine("No number was entered!");
 } catch (FormatException) {
 System.Console.Error.WriteLine("The specified value is not a valid number!");
 } catch (OverflowException) {
 System.Console.Error.WriteLine("The specified number is too big!");
 return -1;
' Visual Basic .NET example
Public Function Main() As Integer
 Try
 Dim s As String = System.Console.[In].ReadLine()
 Dim number As Double = Double.Parse(s)
 System.Console.Out.WriteLine("Number is: {0:F3}", number)
 Return 0
 ' If Parse() threw an exception
 Catch ex As System.ArgumentNullException
 System.Console.[Error].WriteLine("No number was entered!")
 Catch ex2 As System.FormatException
 System.Console.[Error].WriteLine("The specified value is not a valid number!")
 Catch ex3 As System.OverflowException
 System.Console.[Error].WriteLine("The specified number is too big!")
 End Try
 Return -1
End Function
When applying the codice_36 class one can use the instance properties codice_37, codice_38, and codice_39 of that class to access the standard streams of the process.
Python.
Python provides file-like objects that represent stdin, stdout, and stderr. We can show how we could use these objects to work with the input and output of our program.
sys.stdin.
Python's sys module provides us with all three file objects for stdin, stdout, and stderr. For the input file object, we use sys.stdin. This is similar to a file, where you can open and close it, just like any other file.
here a basic example:
program stdin.py
import sys
stdin_fileno = sys.stdin
for line in stdin_fileno:
 # Remove trailing newline characters using strip()
 if "exit" == line.strip():
 print("Found exit. Terminating the program")
 exit(0)
 else:
 print("Message from sys.stdin: ---> {} <---".format(line))
Usage:
$ printf "these \n are different \n words" | python stdin.py
Message from sys.stdin: ---> these <---

Message from sys.stdin: ---> are different <---

Message from sys.stdin: ---> words <---

The above snippet keeps reading input from stdin and prints the message to the Console (stdout) until the word exit is encountered.
NOTE: We do not normally close the default stdin file object, although it is allowed. So stdin_fileno.close() is valid Python code.
Now that we know a little bit about stdin, let us move to stdout.
sys.stdout.
For the output file object, we use sys.stdout. It is similar to sys.stdin, but it directly displays anything written to it to the Console.
The below snippet shows that we get the Output to the Console if we write to sys.stdout.
program stdout.py
import sys
stdout_fileno = sys.stdout
sample_input = ["Hi", "Hello from Python", "exit"]
for ip in sample_input:
 # Prints to stdout
 stdout_fileno.write(ip + "\n")
To execute:

python stdout.py
Output:

Hi

Hello from Python

exit
sys.stderr.
This is similar to sys.stdout because it also prints directly to the Console. But the difference is that can be used to print Exceptions and Error messages and also info/debugging comments. (Which is why it is called Standard Error). This can be very useful when the stdout is used to write data instead.
Here an example.
program stderr.py
import sys
stdout_fileno = sys.stdout
stderr_fileno = sys.stderr
sample_input = ["Hi", "Hello from Python", "exit"]
for ip in sample_input:
 # Prints to stdout
 # Tries to add an Integer with string. Raises an exception
 try:
 stdout_fileno.write(ip + "\n")
 # Catch exceptions
 except:
 stderr_fileno.write("Exception Occurred!\n ")
 stderr_fileno.write("ip = " + ip)
 try:
 ip = ip + 100
 # Catch all exceptions
 except:
 stderr_fileno.write("Exception Occurred! ip = " + ip + "\n")
To execute:
python stderr.py
Output:

Hi

Exception Occurred! ip = Hi

Hello from Python

Exception Occurred! ip = Hello from Python

exit

Exception Occurred! ip = exit
As you can observe, for all the input strings, we try to add to an Integer, which will raise an Exception. We catch all such exceptions and print another debug message using sys.stderr.
Redirection to a file
We can redirect the stdout and also stderr file handles to any other file (file-handle). This may be useful if you want to log events to a file without using any other module such as Logging.
The below snippet redirects output(stdout) to a file called Output.txt.
So, we will not see anything printed to the Console, because it is now being printed to the file itself! This is the essence of Output redirection. You ‘redirect’ the Output to some other place. (This time, to Output.txt, instead of the Console)
import sys
stdout_fileno = sys.stdout
sample_input = ["Hi", "Hello from Python", "exit"]
sys.stdout = open("Output.txt", "w")
for ip in sample_input:
 # Prints to the redirected stdout (Output.txt)
 sys.stdout.write(ip + '\n')
 # Prints to the actual saved stdout handler
 stdout_fileno.write(ip + '\n')
sys.stdout.close()
sys.stdout = stdout_fileno
Output:
$ root@ubuntu:~# python3 output_redirection.py
Hi
Hello from Python
exit
$ root@ubuntu:~# cat Output.txt
Hi
Hello from Python
exit
As you can see, we have printed the output to both the Console, as well as to Output.txt.
We first save the original sys.stdout file handler object to another Variable. We not only need this to restore sys.stdout to the old handler (pointing to the Console), but we can also print to the console using this Variable!
Note that after writing to the file, we close it, similar to how we close a file because that file was still open.
We finally restore the handler of sys.stdout to the Console, using the variable stdout_fileno.
A similar process can be followed for Input and Error redirection, replacing sys.stdout with sys.stdin or sys.stderr and working with Inputs and Exceptions instead of Output.
Here was described about using stdin, stdout and stderr in Python, using the sys module. And also how to manipulate the corresponding file handlers for redirection to/from a file.
GUIs.
Graphical user interfaces (GUIs) don't always make use of the standard streams; they do when GUIs are wrappers of underlying scripts and/or console programs, for instance the Synaptic package manager GUI, which wraps apt commands in Debian and/or Ubuntu. GUIs created with scripting tools like Zenity and KDialog by KDE project make use of stdin, stdout, and stderr, and are based on simple scripts rather than a complete GUI programmed and compiled in C/C++ using Qt, GTK, or other equivalent proprietary widget framework.
The Services menu, as implemented on NeXTSTEP and Mac OS X, is also analogous to standard streams. On these operating systems, graphical applications can provide functionality through a system-wide menu that operates on the current selection in the GUI, no matter in what application.
Some GUI programs, primarily on Unix, still write debug information to standard error. Others (such as many Unix media players) may read files from standard input. Popular Windows programs that open a separate console window in addition to their GUI windows are the emulators pSX and DOSBox.
GTK-server can use stdin as a communication interface with an interpreted program to realize a GUI.
The Common Lisp Interface Manager paradigm "presents" GUI elements sent to an extended output stream.


BitFAT


Nokia X6-00

The Nokia X6 is a music-oriented capacitive touchscreen semi smartphone and portable entertainment device by Nokia. It was announced in early September 2009 during Nokia World 2009 in Germany.
The X6 replaces the Nokia 5800 as Nokia's flagship music-centred model. Both still slot below some high-end touchscreen models like Nokia N97.
The X6 and the Nokia X3-00 are the first devices in newly installed Nokia Xseries. Before the Xseries, Nokia's music-centred devices were branded XpressMusic. With the X6 (and the X3 introduced same day), Nokia launched its new simpler naming strategy with just one number after the series letter.
The original X6 includes the Comes With Music program and a licence for unlimited free downloads from the Nokia Music Store. The Comes With Music version shipped in late 2009 for an estimated retail price of £529.99 or €605.
The name is later reused by HMD global for a new Android smartphone, the Nokia X6 (2018)
Hardware revisions.
A version without Comes With Music support at €200 less was released on 23 February 2010. This version has 16 GB of on-board storage. Another cheaper variation of the X6 also without Comes With Music support was released by Nokia in mid-2010. This version has 8 GB of on-board storage and was released in Asia and North America. The 32 GB version was not released in India instead the 8 GB and 16 GB versions were provided with Ovi Music Unlimited offer.
Appearance.
The X6 is notable for its slimmer body than the 5800 (13.8 mm) and 35 hours of continuous music playback and its fast 3g network. For social networking, it supports easy access to Facebook, MySpace, Ovi, Yahoo IM, YouTube, VK, Windows Live and more.
Firmware updates.
A new software update has been released for Nokia X6-00, version 40.0.002, which brings a new version of Ovi Maps and Ovi Store, improved browser and improved chat in Ovi Contacts.
However the updates are not possible via the phone and require a Windows computer to perform. Nokia was willing to update the devices by mail for those that did not have a Windows PC.
Unofficial.
Hobbyists have provided unofficial Symbian Anna firmware releases.
In 2014, enthusiast of Symbian^1 generation Nokia smartphones release last update of his firmware modification for 10 different models of Nokia smartphones.


Little Implementation Language

LIL, the Little Implementation Language, was a system programming language during the early days of Unix history on PDP-11 machines. It was written by P. J. Plauger of Bell Labs.
LIL attempted to fill the gap between assemblers and machine-independent system implementation languages (such as the C programming language), by basically adding structured programming to the PDP-11 assembly language. LIL resembled PL360 with C-like flow control syntax.
The LIL compiler "lc" was part of Fifth Edition Unix (1974), but was dropped by Sixth Edition Unix (1975). Plauger left Bell Labs in the same year.
Plauger explains why LIL was abandoned in Bell Labs in favor of C:


PhyreEngine

PhyreEngine is a free to use game engine from Sony Interactive Entertainment, compatible with PlayStation 4, PlayStation 3, PlayStation VR, PlayStation Vita, PlayStation Portable, Microsoft Windows (for OpenGL and DirectX 11), Google Android and Apple iOS. PhyreEngine has been adopted by several game studios and has been used in over 200 published titles.
Features.
PhyreEngine is distributed as an installable package that includes both full source code and Microsoft Windows tools, provided under its own flexible use license that allows any PlayStation 3 game developer, publisher or tools and middleware company to create software based partly or fully on PhyreEngine on any platform. The engine uses sophisticated parallel processing techniques that are optimized for the Synergistic Processor Unit (SPU) of the Cell Broadband Engine of PS3, but can be easily ported to other multi-core architectures.
PhyreEngine supports OpenGL and Direct3D, in addition to the low level PS3 LibGCM library. It provides fully functional “game templates” as source code, including support for Havok Complete XS, NVIDIA PhysX and Bullet for physics.
History.
The development of PhyreEngine was started in 2003, to create a graphics engine for PlayStation 3. The first public demonstration occurred in 2006.
PhyreEngine was launched during GDC 2008. PhyreEngine was a finalist in the European Develop Industry Excellence Awards in 2008 (in the "Technical Innovation" category) and 2009 (in the "Game Engine" category).
New features (including Deferred rendering) were showcased during GDC 2009. Version 2.40, released in March 2009, included a new “foliage rendering” system that provides tools and technology to render ultra-realistic trees and plants to be easily integrated into games.
A PSP version of the engine was announced by Sony at GDC 2010.
Version 3.0, released in 2011, has a new and powerful asset pipeline, combining enhanced versions of the already robust exporters, with a powerful processing tool to generate optimized assets for each platform. Also new is the rewritten level editor, which permits a far more data-driven approach to authoring games using PhyreEngine. Version 3.0 of the PhyreEngine adds support for the PlayStation Vita.


BIOS parameter block

In computing, the BIOS parameter block, often shortened to BPB, is a data structure in the volume boot record (VBR) describing the physical layout of a data storage volume. On partitioned devices, such as hard disks, the BPB describes the volume partition, whereas, on unpartitioned devices, such as floppy disks, it describes the entire medium. A basic BPB can appear and be used on any partition, including floppy disks where its presence is often necessary; however, certain filesystems also make use of it in describing basic filesystem structures. Filesystems making use of a BIOS parameter block include FAT12 (except for in DOS 1.x), FAT16, FAT32, HPFS, and NTFS. Due to different types of fields and the amount of data they contain, the length of the BPB is different for FAT16, FAT32, and NTFS boot sectors. (A detailed discussion of the various FAT BPB versions and their entries can be found in the FAT article.) Combined with the 11-byte data structure at the very start of volume boot records immediately preceding the BPB or EBPB, this is also called FDC descriptor or extended FDC descriptor in ECMA-107 or ISO/IEC 9293 (which describes FAT as for flexible/floppy and optical disk cartridges).
FAT12 / FAT16.
DOS 2.0 BPB.
Format of standard DOS 2.0 BPB for FAT12 (13 bytes):
DOS 3.0 BPB.
Format of standard DOS 3.0 BPB for FAT12 and FAT16 (19 bytes), already supported by some versions of MS-DOS 2.11:
DOS 3.2 BPB.
Format of standard DOS 3.2 BPB for FAT12 and FAT16 (21 bytes):
DOS 3.31 BPB.
Format of standard DOS 3.31 BPB for FAT12, FAT16 and FAT16B (25 bytes):
DOS 3.4 EBPB.
Format of PC DOS 3.4 and OS/2 1.0-1.1 Extended BPB for FAT12, FAT16 and FAT16B (32 bytes):
FAT12 / FAT16 / HPFS.
DOS 4.0 EBPB.
Format of DOS 4.0 and OS/2 1.2 Extended BPB for FAT12, FAT16, FAT16B and HPFS (51 bytes):
FAT32.
DOS 7.1 EBPB.
Format of short DOS 7.1 Extended BIOS Parameter Block (60 bytes) for FAT32:
Format of full DOS 7.1 Extended BIOS Parameter Block (79 bytes) for FAT32:
NTFS.
Format of Extended BPB for NTFS (73 bytes):


AMD FX

AMD FX was a series of high-end AMD microprocessors for personal computers debuted in 2011, claimed as AMD's first native 8-core desktop processor. The line was introduced with the Bulldozer microarchitecture at launch (CPU codename Zambezi), and was then succeeded by its derivative Piledriver in 2012 (codename Vishera).
The line aimed at competing with the Intel Core line of desktop processors, and in particular the Sandy Bridge and Ivy Bridge architectures.
AMD's successor architecture, Zen, was released in 2017 under the Ryzen brand, replacing the FX series and competing with Intel's Skylake architecture.
History.
Prior to FX Launch.
In the years prior to the AMD FX range of processors, the AMD Phenom II and Athlon II lineup of processors, while not beating Intel's Core lineup in raw performance, were generally competitive when price was taken into account. By the end of the Phenom's lifespan, however, Intel's Sandy Bridge architecture could provide performance that Phenom II could not compete with. Rumors suggested that the FX line would change that as leaked information suggested improved performance of the upcoming bulldozer architecture that AMD FX was based on.
FX Launch.
The FX series launched on October 12, 2011, on the bulldozer architecture. The launch lineup included the 4 core FX 4100 at $115, the 6 core FX 6100 at $165, and the 8 core FX 8120 at $205 and FX 8150 at $185. The FX refresh on the piledriver architecture launched on October 23, 2012. The launch lineup included the refreshed 4 core FX 4300 at $122, 6 core FX 6300 at $132, and 8 core FX 8320 at $169 and FX 8350 at $195.
Features.
One notable feature of the AMD FX microprocessors is that they are all unlocked and overclockable, a feature reserved for the high-end "K" suffix SKUs from Intel. This allows users to increase the clock speed of their CPU and to gain extra performance out of their product. The personal world record for highest overclock was achieved on an FX-8350, which is clocked up to 8794.33 MHz. The record was beaten again, although unofficially by a Russian tech YouTuber, known as “RX4D”, reaching his FX-8320e up to 10.2GHz.
Unlike the majority of their Intel counterparts, FX chips offer no integrated graphics, a feature reserved to AMD's APU line of processors.
Both Zambezi and Vishera use a module design containing two cores on one module.
Reception.
Upon launch, the FX series was met with criticism from reviewers. Due to multiple cores sharing common resources, most tasks were substantially slower on the FX lineup than the Intel Sandy Bridge equivalent. In many single-threaded applications, it was worse than the previous generation of Phenom II microprocessors. The power consumption of the lineup, while not as poor as the Phenom II generation, was also worse than what Intel was providing at the time. The refresh to the processors that were brought about by the piledriver architecture in 2012 generally improved performance across the board by increasing clock speeds at similar power consumption levels, but by then Intel's Ivy Bridge architecture was available and provided much better performance per watt and total performance to consumers. With AMD only being responsible for 20% of consumer CPU sales in 2016, Intel continued to gain market share in the industry during the lifespan of the FX series.
Performance.
The AMD FX line-up was generally worse performing than its Intel competitors during the lifespan of the range. The floating-point performance was relatively poor due to a single shared FPU per module and most games could not take advantage of the high core counts that the series provided. In processes that thrived in multithreaded applications, AMD SKUs typically pulled ahead. This came at a great cost, however, as thermal efficiency was often worse than the previous generation of processors. Updates to the architecture that came with the Piledriver revision allowed for higher clock speeds. This led to better performance, but that came with the cost of even higher thermal output on the high end, which can be seen with the FX 9590, which outputs 220 Watts.
Controversy.
In 2015 AMD was accused of falsely advertising the core count of its FX lineup. The claim stated that because the FX series' cores shared common resources such as the FPU, AMD was falsely advertising its high core counts. The company had to pay out $12.1 million to California residents who bought a high-end FX chip.


PowerBook Duo 230

The PowerBook Duo 230 is a subnotebook personal computer introduced on October 19, 1992 by Apple Computer, Inc. Priced at US $2,610, the PowerBook Duo 230 was the high end model of the two simultaneously released PowerBook Duos, the lower end being the US $2,250 PowerBook Duo 210. With a 33 MHz Motorola 68030 microprocessor, 4 MB of RAM and an 80 or 120 MB SCSI hard disk drive, the PowerBook Duo 230 was nearly identical to the simultaneously released PowerBook 180 except for the smaller 9.1 inch greyscale "supertwist" passive-matrix LCD and the lack of a 68882 floating-point unit.
With the October 1993 introduction of the PowerBook Duo 250 and 270c, the 230 replaced the 210 in the entry level, eventually being discontinued entirely on July 27, 1994 shortly after the introduction of the 68040-based PowerBook Duo 280 and 280c.


Intel Mobile Communications

Intel Mobile Communications (IMC), is the mobile research and development division of Intel. It was formed when Intel completed the acquisition of the Wireless Solutions (WLS) division of Infineon early in 2011 for US$1.4 billion. The Infineon subsidiary Comneon was also acquired by Intel and is now integrated into Intel Mobile Communications.
IMC develops, manufactures and markets semiconductor products and solutions for wireless communications. It targets the fast-growing market segments of smart phones, connected devices (e.g. tablets, USB dongles, mobile PCs, M2M), and ultra-low-cost/entry phones. Its roadmap is focused on providing cost-effective 2G/3G single-chip platforms for ULC phones up to entry-level smart phones and 3G/4G slim modem and RF solutions for mid-to high-end smart phones and connected devices.
In 2013 due to re-organization, a new organization was formed, named WPRD (Wireless Products Research & Development), which included the former IMC teams, and also the former MWG (Intel legacy Mobile and Wireless Group). This organization was managed by Aicha Evans. In 2016 the name was changed to iCDG (Intel Communications Devices Group). In 2017 Aicha Evans moved and became the chief strategy officer of Intel.
On April 16, 2019, Apple and Qualcomm reached a settlement which included Apple paying an unspecified amount, entering into a six-year patent licensing agreement, and a multi-year agreement for Qualcomm to provide hardware to Apple. Shortly after Intel announced they will exit the 5G smartphone modem business to focus 5G efforts on network infrastructure.
On July 25, 2019, Apple and Intel announced an agreement for Apple to acquire Intel Mobile Communications' smartphone modem business for US$1 billion. Intel will continue to develop modems for non-smartphones such as PCs, Internet of things and autonomous vehicles.
Products.
Intel Mobile Communications develops 2G, 3G, 4G and 5G Modems under the Intel XMM modems brand.
Intel Mobile Communications developed the Intel Atom Z2000, Z2460, Z2580 system on a chip (SoC) processors.
In 2017, external publications (not confirmed by Intel or Apple) indicated that Apple iPhone 7 & 8 LTE modems, in most of the units shipped, were based on Intel chips (developed in IMC or iCDG).


Korora (operating system)

Korora (previously "Kororaa") was a remix of the Fedora Linux distribution. Originally Kororaa was a binary installation method for Gentoo Linux which aimed for easy installation of a Gentoo system by using install scripts instead of manual configuration. The name derives from the Māori word – the little penguin.
History.
Korora was started by Christopher Smart as a method to quickly reproduce a Gentoo Linux installation on multiple desktop machines. Chris also intended that Korora be used to quickly demonstrate the power of Gentoo Linux to users critical of 'compile times.' On November 7, 2007, Chris announced that he was discontinuing his work on the project, and that there would be no new versions of Korora.
The introduction of the Korora XGL Live CD was intended to demonstrate the capabilities of Novell’s Xgl and Compiz.
On December 23, 2010, Chris Smart has announced rebirth of Kororas Fedora Remix.
On , Korora 18 was released, featuring a revised name spelled with only one A and a new logo.
On May 16, 2018, Korora stopped its development.
Kororaa XGL Live CD.
In March 2006, a Kororaa based Live CD was released, preconfigured with Xgl capabilities. The live CD supports NVIDIA, ATI and Intel graphics cards, and the latest version (0.3) comes with both K Desktop Environment 3 and GNOME.
Development hiatus and restart.
On November 7, 2007, Smart announced that development on Korora would be ended, and no further versions would be released; the reasons given were that:
On December 23, 2010, Smart announced the restart of Korora with a release of the Fedora-based version of the distro:
I know that you'll be looking for something Linux related to do over your Christmas holidays and New Year, so I've just released the first installable live DVD beta for testing. The final release will be Korora 14 (derived from Fedora 14), code-named 'Nemo'. As with the original Korora, it's based on KDE. Essentially, Korora has been reborn as a Fedora remix, inspired by Rahul Sundaram's Omega GNOME remix. It aims to provide all general computing uses out of the box and it aims to include software packages that most users will want.


SuperNova (operating system)


Double Clutch (video game)

Double Clutch is a racing video game developed by BGS Development for the Mega Drive. It was published by Sega in the PAL region in 1993.
Gameplay.
"Double Clutch" is a racing video game from an overhead perspective, in which players race against other opponents around a track. It is played in either one or two players. The main objective for the player is to qualify for the next race by finishing in the top three in a three-lap race. The game ends if the player finishes in fourth place; in a two-player game, the game continues for both players as long as one of them is in the top three. At the beginning of the game, players can choose one of the drivers, each has their own driving type. The game also features various weather conditions, such as rain and snow.
If the player finishes in the top three after each race, they can earn the amount of money depending on the driver's position. Earnings can be used for players to buy parts and make improvements to their vehicle. Players can change one of three difficulty levels, which determine the speed of the opponent racers and a number of laps; on a hardest setting, players race on five laps. In practice mode, players can race on any of the first four tracks.
Reception.
The game received mixed reviews upon release. "Mean Machines" gave it a generally positive review, saying it is fast, smooth, and playable, but comparing it unfavourably with "Micro Machines". "Mega" were harshly critical of the game, calling it "extremely dull", before recommending "Micro Machines" instead.


List of OpenCL applications

The following list contains a list of computer programs that are built to take advantage of the OpenCL or WebCL heterogeneous compute framework.


FMA instruction set

The FMA instruction set is an extension to the 128 and 256-bit Streaming SIMD Extensions instructions in the x86 microprocessor instruction set to perform fused multiply–add (FMA) operations. There are two variants:
Instructions.
FMA3 and FMA4 instructions have almost identical functionality, but are not compatible. Both contain fused multiply–add (FMA) instructions for floating-point scalar and SIMD operations, but FMA3 instructions have three operands, while FMA4 ones have four. The FMA operation has the form "d" = round("a" · "b" + "c"), where the round function performs a rounding to allow the result to fit within the destination register if there are too many significant bits to fit within the destination.
The four-operand form (FMA4) allows "a", "b", "c" and "d" to be four different registers, while the three-operand form (FMA3) requires that "d" be the same register as "a", "b" or "c". The three-operand form makes the code shorter and the hardware implementation slightly simpler, while the four-operand form provides more programming flexibility.
See XOP instruction set for more discussion of compatibility issues between Intel and AMD.
FMA3 instruction set.
Excerpt from FMA3.
Supported commands include VFMADD, VFMADDSUB, VFMSUBADD, VFMSUB, VFNMADD, VFNMSUB. Explicit order of operands is included in the mnemonic using numbers "132", "213", and "231", as well as operand format (packed or scalar) and size (single or double).
History.
The incompatibility between Intel's FMA3 and AMD's FMA4 is due to both companies changing plans without coordinating coding details with each other. AMD changed their plans from FMA3 to FMA4 while Intel changed their plans from FMA4 to FMA3 almost at the same time. The history can be summarized as follows:
Compiler and assembler support.
Different compilers provide different levels of support for FMA:


GeForce 400 series

Serving as the introduction of Fermi, the GeForce 400 series is a series of graphics processing units developed by Nvidia. Its release was originally slated in November 2009; however, after delays, it was released on March 26, 2010 with availability following in April 2010.
Architecture.
Nvidia described the Fermi (microarchitecture) as the next major step in its line of GPUs following the Tesla (microarchitecture) used since the G80. The GF100, the first Fermi-architecture product, is large: 512 stream processors, in sixteen groups of 32, and 3.0 billion transistors, manufactured by TSMC in a 40 nm process. It is Nvidia's first chip to support OpenGL 4.0 and Direct3D 11. No products with a fully enabled GF100 GPU were ever sold. The GTX 480 had one streaming multiprocessor disabled. The GTX 470 had two streaming multiprocessors and one memory controller disabled. The GTX 465 had five streaming multiprocessors and two memory controllers disabled. Consumer GeForce cards came with 256MB attached to each of the enabled GDDR5 memory controllers, for a total of 1.5, 1.25 or 1.0GB; the Tesla C2050 had 512MB on each of six controllers, and the Tesla C2070 had 1024MB per controller. Both the Tesla cards had fourteen active groups of stream processors.
The chips found in the high performance Tesla branding feature memory with optional ECC and the ability to perform one double-precision floating-point operation per cycle per core; the consumer GeForce cards are artificially driver restricted to one DP operation per four cycles. With these features, combined with support for Visual Studio and C++, Nvidia targeted professional and commercial markets, as well as use in high performance computing.
Fermi is named after Italian physicist Enrico Fermi.
Current limitations and trade-offs.
The quantity of on-board SRAM per ALU actually decreased proportionally compared to the previous G200 generation, despite the increase of the L2 cache from 256kB per 240 ALUs to 768kB per 512 ALUs, since Fermi has only 32768 registers per 32 ALUs (vs. 16384 per 8 ALUs), only 48kB of shared memory per 32 ALUs (vs. 16kB per 8 ALUs), and only 16kB of cache per 32 ALUs (vs. 8kB constant cache per 8 ALUs + 24kB texture cache per 24 ALUs). Parameters such as the number of registers can be found in the CUDA Compute Capability Comparison Table in the reference manual.
History.
On September 30, 2009, Nvidia released a white paper describing the architecture: the chip features 16 'Streaming Multiprocessors' each with 32 'CUDA Cores' capable of one single-precision operation per cycle or one double-precision operation every other cycle, a 40-bit virtual address space which allows the host's memory to be mapped into the chip's address space, meaning that there is only one kind of pointer and making C++ support significantly easier, and a 384-bit wide GDDR5 memory interface. As with the G80 and GT200, threads are scheduled in 'warps', sets of 32 threads each running on a single shader core. While the GT200 had 16 KB 'shared memory' associated with each shader cluster, and required data to be read through the texturing units if a cache was needed, GF100 has 64 KB of memory associated with each cluster, which can be used either as a 48 KB cache plus 16 KB of shared memory, or as a 16 KB cache plus 48 KB of shared memory, along with a 768 KB L2 cache shared by all 16 clusters.
The white paper describes the chip much more as a general purpose processor for workloads encompassing tens of thousands of threads - reminiscent of the Tera MTA architecture, though without that machine's support for very efficient random memory access - than as a graphics processor.
Products.
SP - Shader Processor (Unified Shader, CUDA Core), SFU - Special Function Unit, SM - Streaming Multiprocessor.
All products are produced on a 40 nm fabrication process. All products support Direct X 12.0, OpenGL 4.6 and OpenCL 1.1. The only exception is the Geforce 405 which is based on the GT218 core only supporting DirectX 10.1, OpenGL 3.3 and no OpenCL Support
On November 8, 2010, Nvidia released the GF110 chip, along with the GTX580 (480's replacement). It is a redesigned GF100 chip, which uses significantly less power. This allowed Nvidia to enable all 16 SMs (all 16 cores), which was previously impossible on the GF100 Various features of the GF100 architecture were only available on the more expensive Quadro and Tesla series of cards. For the GeForce consumer products, double precision performance is a quarter of that of the "full" Fermi architecture. Error checking and correcting memory (ECC) also does not operate on consumer cards. The GF100 cards provide Compute Capability 2.0, while the GF104/106/108 cards provide Compute Capability 2.1.
Discontinued support.
Nvidia announced that after Release 390 drivers, it will no longer release 32-bit drivers for 32-bit operating systems.
Nvidia announced in April 2018 that Fermi will move to legacy driver support status and be maintained until January 2019.


Spin-up

Spin-up refers to the process of a hard disk drive or optical disc drive accelerating its platters or inserted optical disc from a stopped state to an operational speed. The period of time taken by the drive to perform this process is referred to as its spin-up time, the average of which is reported by hard disks as a S.M.A.R.T. attribute. The required operational speed depends on the design of the disk drive. Typical speeds of hard disks have been 2400, 3600, 4200, 5400, 7200, 10000 and 15000 revolutions per minute (RPM). Achieving such speeds can require a significant portion of the available power budget of a computer system, and so application of power to the disks must be carefully controlled. Operational speed of optical disc drives may vary depending on type of disc and mode of operation (see Constant linear velocity).
Spin-up of hard disks generally occurs at the very beginning of the computer boot process. However, most modern computers have the ability to stop a drive while the machine is already running as a means of energy conservation or noise reduction. If a machine is running and requires access to a stopped drive, then a delay is incurred while the drive is spun up. It also depends on the type of mechanism used within.
A drive in the process of being spun up needs more energy input than a drive that is already spinning at operation speeds, since more effort is required for the electric motor to accelerate the platters, as opposed to maintaining their speed.
Staggered spin-up.
In computers with multiple hard drives, a method called staggered spin-up can be employed to prevent the excessive power-consumption of spin-up, which may result in a power shortage. Power consumption during spin-up is often the highest power draw of all of the different operating states of a hard disk drive. Staggered spin-up typically starts one drive at a time, either waiting for the drive to signal it is ready or allowing a predefined period of time to pass before starting the next drive. If the power supply is able to supply sufficient current to start multiple drives at a time, that, too, is common.
Staggered Spin-up (SSU) and Power-Up In Standby (PUIS) are different features that can help control spin-up of multiple drives within a computer system or a disk subsystem. Both are defined in the ATA Specifications Standards. See Serial ATA for more information.
One feature, called Power-up in standby (PUIS) (also called PM2) is used on some Serial ATA (SATA) and Parallel ATA (sometimes called PATA or IDE) hard disk drives. PUIS requires BIOS and/or driver support to use. When power is applied to the hard disk drive, the drive will not spin-up until a PUIS Spin-Up command is issued. The computer system BIOS or RAID controller must issue the command to tell the drive(s) to spin-up before they can be accessed. PUIS can be enabled by tools such as hdparm for drives which support this feature.
Another feature, called Staggered Spin-up (SSU) is used on most Serial ATA (SATA) hard disk drives. This is more common than Power-Up In Standby (PUIS) because it does not require any special commands to get the drive to spin-up. The drive electronics waits for the SATA Data Phy (Physical I/F) to activate to spin-up the drive. The computer system BIOS and/or RAID controller or RAID driver set can delay and control when the different drives will spin-up.
With Western Digital hard disk drives, Pin 11 of the SATA Power Interface controls whether Staggered Spin-Up (SSU) is enabled or not. Pin 11 is also used as an activity LED connection. When the drive is initially powered on, the drive senses whether Pin 11 is left floating (high or '1' logic state) or grounded (low or '0' logic state). SSU is disabled when Pin 11 is grounded. When disabled, the drive will spin-up as soon as power is applied to it. SSU is enabled when Pin 11 is left floating or driven high (high or '1' logic state). The drive will not spin-up until the SATA Phy Interface becomes active with a connection to a SATA controller or SATA RAID controller. The SATA or SATA RAID controller can control when and how many drives can be spun-up. SSU and PUIS are features that are configured in software or firmware by the manufacturer.
Information from the Fujitsu Serial ATA Interface for Mobile Hard Disk Drives whitepaper:
Note that staggered spin-up of disks is a feature of many multi-drive systems using SATA and RAID. It is not typically used on mobile platforms.


Safe mode

Safe mode is a diagnostic mode of a computer operating system (OS). It can also refer to a mode of operation by application software. "Safe mode" is intended to help fix most, if not all, problems within an operating system. It is also widely used for removing rogue security software.
Background.
Microsoft Windows, macOS, Android and Linux distributions such as Ubuntu and Linux Mint are examples of contemporary operating systems that implement a safe mode (called "Safe Boot" in macOS) as well as other complex electronic devices.
In safe mode, an operating system has reduced functionality, but the task of isolating problems is easier since many non-core components are disabled, such as sound. An installation that will only boot into safe mode typically has a major problem, such as disk corruption or the installation of poorly-configured software that prevents the operating system from successfully booting into its normal operating mode.
Though it varies by operating system, safe mode typically loads only essential executable modules and disables devices except for those necessary to display information and accept input. It can also take the form of a parallel "miniature" operating system that has no configuration information shared with the normal operating system. For example, on Microsoft Windows, the user can also choose to boot to the Recovery Console, a small text-based troubleshooting mode kept separate from the main operating system (which can also be accessed by booting the install CD) or to various "safe mode" options that run the dysfunctional OS but with features, such as video drivers, audio, and networking, disabled.
Safe mode typically provides access to utility and diagnostic programs so a user can troubleshoot what is preventing the operating system from working normally. Safe mode is intended for maintenance, not functionality, and it provides minimal access to features.
Operating systems.
Windows.
Microsoft Windows' safe mode (for 7/Vista /XP /2000/ME/98/95) is accessed by pressing the F8 key as the operating system boots. Also, in a multi-boot environment with multiple versions of Windows installed side by side, the F8 key can be pressed at the OS selector prompt to get to safe mode. However, under Windows 8 (released in 2012), the traditional press-F8-for-safe-mode-options UI convention no longer works, and either Shift-F8 or a special GUI-based workaround is necessary.
Unix.
An equivalently minimal setting in Unix-like operating systems is single-user mode, in which daemons and the X Window System are not started, and only the root user can log in. It can do emergency repairs or maintenance, including resetting users' passwords on the machine without the need to know the old one.
macOS.
In macOS holding the shift key after powering up activates Safe Boot that has background maintenance features (Besides the mode selection, it runs a file system repair, and in Mac OS 10.4, it disables all fonts other than those in /System/Library/Fonts, moves to the Trash all font caches normally stored in /Library/Caches/com.apple.ATS/(uid)/, where (uid) is a user ID number such as 501, and disables all startup items and any Login Items). Unlike in Windows where safe mode with networking is disabled by default and requires using a safe mode with networking enabled, in the macOS Safe Boot always includes networking.
On the Classic Mac OS versions 6, 7, 8, and 9, a similar mode to the Unix root is achieved by holding down the shift key while booting, which starts the system without extensions.
Application software safe mode.
Application software sometimes offers a safe mode as well. In the PHP interpreter, prior to version 5.4, safe mode offers stricter security measures.
The Glasgow Haskell Compiler from version 7.2 offers "Safe Haskell" mode, restricting usage of functions such as unsafePerformIO. Mozilla Firefox's safe mode allows the user to remove extensions which may be preventing the browser from loading. Internet Explorer can run in "No Add-Ons" mode and Protected Mode. Cydia's MobileSubstrate also has a safe mode that allows the user to uninstall tweaks and extensions that may crash the SpringBoard.


Cub Linux

Cub Linux was a computer operating system designed to mimic the desktop appearance and functionality of Chrome OS. It was based on Ubuntu Linux LTS 14.04 "Trusty Tahir". It used Openbox as the window manager and tools taken from LXDE, Gnome, XFCE as well as a number of other utilities. It was a cloud-centric operating system that was heavily focused on the Chromium Browser. Cub Linux's tagline was "Cub = Chromium + Ubuntu".
History.
Cub Linux was originally called Chromixium OS. The developer, RichJack, initially announced the project on the Ubuntu user forums on September 19, 2014. Since then, the project released the first stable version, Chromixium 1.0 as a 32 bit live ISO on April 26, 2015. This was followed by a service pack to address a number of issues such as screen tearing and slow menu generation. In July 2015, a number of updates were rolled into a new release, version 1.5. This was initially 32 bit only, but was followed by a 64 bit release in November 2015.
At some point towards the end of 2015, Google, who owns the rights to the Chrome OS and Chromium trademarks, requested that RichJack cease use of the Chromixium mark and related websites and social media presences. On January 17, 2016, RichJack announced that Chromixium would be changing name to Cub Linux with immediate effect and that the Chromixium name would be completely dropped by 31 March 2016.
Towards the end of 2016, the Cub Linux website mysteriously disappeared. Their GitHub page is still open. User d4zzy, who was involved in Cub Linux's development had this to say about its sudden end: "Cub was killed due to private life restrictions - that was all and there was no one at the time to pick it up."
On July 19, 2017, the developer of Feren OS announced that he would be "bringing back Cub" in the form of Phoenix Linux. The page has not been updated since the release of Alpha 2 in March 2018.
Receptions.
Jesse Smith from DistroWatch Weekly reviewed Chromixium OS 1.0:


Samsung Wave S8500

The Samsung Wave (or Samsung Wave GT-S8500) is a smartphone developed and produced by Samsung Electronics. It is the first smartphone to run the Bada operating system developed by Samsung Electronics, which was commercially released on May 24, 2010. The Wave is a touchscreen phone powered by Samsung's "Hummingbird" CPU (S5PC110), which includes 1 GHz ARM Cortex-A8 CPU and a built-in PowerVR SGX 540 graphics engine. It also has a "Super AMOLED" screen and 720p high-definition video capture capabilities. Due to shortage of Super AMOLED screens, Samsung released a successor to the device called Wave II and ceased production of the original S8500 model.
Specifications.
Screen.
The screen is a capacitive touchscreen Super AMOLED with an anti-smudge oleophobic coating on top of the scratch-resistant tempered-glass ( Gorilla Glass Display ). The screen resolution is 800x480 WVGA with 283 PPI.
Processor.
The phone features a 1 GHz SoC, which internally contains an ARM Cortex A8 CPU core, the same model as Apple's A4 processor. The graphics engine of the device is a PowerVR SGX 540 GPU which is said to be capable of generating 90 million triangles per second (same as the SoC used on the Samsung Galaxy S).
Camera.
The phone features a 5 megapixel EDOF camera which supports 2560 x 1920 pixels, along with autofocus, LED flash, Geo-tagging, face and blink detection, image stabilization, touch focus,etc. Shooting modes include beauty shot, smile shot, continuous, panorama and vintage shot. As a camcorder it is able to shoot HD recording (1280x720) at 30 FPS with flash. As well as this, it is also able to record slow motion video (320x240) at 120 FPS with flash.
Operating system.
The Wave was the first phone with Samsung's own Linux based Operating System, Bada, meaning "Ocean". Samsung worked on the later versions of Bada 1.2 and later 2.0. Bada 1.2 was released to the world in a phased manner as it was designed to improve stability.
In January 2012, Samsung declared that it was planning to merge Bada with the Linux-based Tizen operating system that was developed in collaboration with Intel. Despite the collaboration, was not supported by the Wave.
Unofficial ports of Android were made due to the restrictions and the eventual cease in development of Bada. Versions ported include Android Froyo, Gingerbread, Ice Cream Sandwich, Jellybean, KitKat, Lollipop and Marshmallow.
Other features.
Other features include A-GPS, 2 GB/8 GB of internal storage with a microSDHC slot for an additional 32 GB. It also has a magnetometer (compass), a proximity sensor, an accelerometer, 5.1-channel surround sound Mobile Theater, music recognition, a fake call service, smart search, Social Hub and it is the first phone to support Bluetooth version 3.0.
Radio connectivity includes Bluetooth 3.0, Wi-Fi 802.11 b/g/n and HSDPA 3.6 Mbit/s.
This phone is available with both European/Asian 3G bandings and the North American 3G bandings. The North American 3G bandings version of the phone is a limited availability and is not available in the US.
Software features.
User interface.
The phone is the first smartphone to feature the Samsung Bada operating system platform. The UI is Samsung's own Touch-wiz 3.0. Touch-wiz 3.0, like the two predecessors (Touch-wiz 2.0 and Touch-wiz), utilizes widgets. The three most notable widgets pre-installed in Touch-wiz 3.0 are Daily Briefing (which includes all essential information such as weather, finance, AP mobile news and schedule), Feeds and Updates and Buddies now (which allows users to call, send texts to and read Facebook/Twitter feeds off their favorite contacts). Users are allowed to have up to 10 home screens to add widgets.
Applications.
For Internet browsing the Samsung Wave has the Dolphin Browser v2.0 (based on WebKit) (or 3.0 depends by the firmware version). This browser supports Flash, but it is disabled by default to improve page loading speed.
By default, the phone comes with Picsel Viewer which is capable of reading .PDF and Microsoft Office file formats. Users from selected countries can buy and download Picsel Office Editor from Samsung Apps.
As for Samsung Apps, users can also download applications, games and widgets from the application store.
Other software includes the GPS software that comes with this phone (LBS Route 66), Facebook, Twitter, social hub, mini diary, daily briefing, memo, video player, FM radio, media browser, voice recorder, e-mail and pre-installed Asphalt 5.
Media support.
The Samsung Wave supports MP3, AAC, AAC+, e-AAC+, WMA, AMR, WAV, MP4, MPEG4, H.263, H.264, WMV, FLV, DivX, XviD, MKV and FLAC file formats. It also supports subtitles.
Bada 2.0 support.
In many countries at the end of December 2011, the operating system was gradually updated to Bada 2.0. The first official Bada 2.0 version was LA1.
With Bada 2.0, the TouchWiz UI reached version 4.0, the GUI was completely redone, and included many new features, such as full multitasking, WAC, voice commands, text-to-speech, speech-to-text, ChatON, Caster, a new version of DLNA, social apps and the new Dolphin 3.0 browser with a download manager.
Android porting
Due to many owners of the phone disliking the Bada software many people have worked on porting the popular Android O.S to the Wave. The ported versions known are Froyo, Gingerbread, Ice Cream Sandwich, Jelly Bean and Kitkat. However they are still being developed and some features, such as GPS, may be limited or not function as intended.
External links.
Reviews:
Forums:


Monolithic kernel

A monolithic kernel is an operating system architecture where the entire operating system is working in kernel space. The monolithic model differs from other operating system architectures (such as the microkernel architecture) in that it alone defines a high-level virtual interface over computer hardware. A set of primitives or system calls implement all operating system services such as process management, concurrency, and memory management. Device drivers can be added to the kernel as modules.
Loadable modules.
Modular operating systems such as OS-9 and most modern monolithic operating systems such as OpenVMS, Linux, BSD, SunOS, AIX, and MULTICS can dynamically load (and unload) executable modules at runtime.
This modularity of the operating system is at the binary (image) level and not at the architecture level. Modular monolithic operating systems are not to be confused with the architectural level of modularity inherent in server-client operating systems (and its derivatives sometimes marketed as hybrid kernel) which use microkernels and servers (not to be mistaken for modules or daemons).
Practically speaking, dynamically loading modules is simply a more flexible way of handling the operating system image at runtime—as opposed to rebooting with a different operating system image. The modules allow easy extension of the operating systems' capabilities as required. Dynamically loadable modules incur a small overhead when compared to building the module into the operating system image.
However, in some cases, loading modules dynamically (as-needed) helps to keep the amount of code running in kernel space to a minimum; for example, to minimize operating system footprint for embedded devices or those with limited hardware resources. Namely, an unloaded module need not be stored in scarce random access memory.


Logical sectoring


Getopts

codice_1 is a built-in Unix shell command for parsing command-line arguments. It is designed to process command line arguments that follow the POSIX Utility Syntax Guidelines, based on the C interface of getopt.
The predecessor to was the external program by Unix System Laboratories.
History.
The original had several problems: it could not handle whitespace or shell metacharacters in arguments, and there was no ability to disable the output of error messages.
codice_1 was first introduced in 1986 in the Bourne shell shipped with Unix SVR3. It uses the shell's own variables to track the position of current and argument positions, and , and returns the option name in a shell variable. Earlier versions of the Bourne shell did not have "getopts".
In 1995, codice_1 was included in the Single UNIX Specification version 1 / X/Open Portability Guidelines Issue 4. As a result, codice_1 is now available in shells including the Bourne shell, KornShell, Almquist shell, Bash and Zsh.
The command has also been ported to the IBM i operating system.
The modern usage of was partially revived mainly due to an enhanced implementation in util-linux. This version, based on the BSD , not only fixed the two complaints around the old , but also introduced the capability for parsing GNU-style long options and optional arguments for options, features that lacks. The various BSD distributions, however, stuck to the old implementation.
Usage.
The usage synopsis of getopt and getopts is similar to its C sibling:
 getopt "optstring" "[parameters]"
 getopts "optstring" "varname" "[parameters]"
The way one uses the commands however varies a lot:
Enhancements.
In various getopts.
In spring 2004 (Solaris 10 beta development), the libc implementation for was enhanced to support long options. As a result, this new feature was also available in the built-in command codice_1 of the Bourne Shell. This is triggered by parenthesized suffixes in the "optstring" specifying long aliases.
KornShell and Zsh both have an extension for long arguments. The former is defined as in Solaris, while the latter is implemented via a separate command.
KornShell additionally implements "optstring" extensions for options beginning with instead of .
In Linux getopt.
An alternative to codice_1 is the Linux enhanced version of codice_7, the external command line program.
The Linux enhanced version of codice_7 has the extra safety of codice_1 plus more advanced features. It supports long option names (e.g. codice_10) and the options do not have to appear before all the operands (e.g. codice_11 is permitted by the Linux enhanced version of codice_7 but does not work with codice_1). It also supports escaping metacharacters for shells (like tcsh and POSIX sh) and optional arguments.
Examples.
Suppose we are building a Wikipedia downloader in bash that takes three options and zero extra arguments:
 wpdown -a "article name" -l "[language]" -v
When possible, we allow the following long arguments:
 -a --article
 -l --language, --lang
 -v --verbose
For clarity, no help text is included, and we assume there is a program that downloads any webpage. In addition, all programs are of the form:
VERBOSE=0
ARTICLE="
LANG=en
if ((VERBOSE > 2)); then
 printf '%s\n' 'Non-option arguments:'
 printf '%q ' "${remaining[@]]}"
fi
if ((VERBOSE > 1)); then
 printf 'Downloading %s:%s\n' "$LANG" "$ARTICLE"
fi
if ! $ARTICLE ; then
 printf '%s\n' "No articles!">&2
 exit 1
fi
save_webpage "https://${LANG}.wikipedia.org/wiki/${ARTICLE}"
Using old getopt.
The old getopt does not support optional arguments:
args=`getopt 'a:l:v' $*` || exit
set -- $args
while true; do
 case $1 in
 (-v) ((VERBOSE++)); shift;;
 (-a) ARTICLE=$2; shift 2;;
 (-l) LANG=$2; shift 2;;
 (--) shift; break;;
 (*) exit 1;; # error
 esac
done
remaining=("$@")
This script will also break with any article title with a space or a shell metacharacter (like ? or *) in it.
Using getopts.
Getopts give the script the look and feel of the C interface, although in POSIX optional arguments are still absent:
while getopts ':a:l:v' opt; do
 case $opt in
 (v) ((VERBOSE++));;
 (a) ARTICLE=$OPTARG;;
 (l) LANG=$OPTARG;;
 (:) # "optional arguments" (missing option-argument handling)
 case $OPTARG in
 (a) exit 1;; # error, according to our syntax
 (l) :;; # acceptable but does nothing
 esac;;
 esac
done
shift "$OPTIND"
Since we are no longer operating on shell options directly, we no longer need to shift them. However, a slicing operating is required to get the remaining arguments now.
It is possible, but tedious to emulate long argument support by treating as an argument to an option .
Using Linux getopt.
Linux getopt escapes its output and an "eval" command is needed to have the shell interpret it. The rest is unchanged:
ARGS=$(getopt -o 'a:l::v' --long 'article:,language::,lang::,verbose' -- "$@") || exit
eval "set -- $ARGS"
while true; do
 case $1 in
 (-v|--verbose)
 ((VERBOSE++)); shift;;
 (-a|--article)
 ARTICLE=$2; shift 2;;
 (-l|--lang|--language)
 # handle optional: getopt normalizes it into an empty string
 if [ -n "$2" ]; then
 LANG=$2; shift;
 fi
 shift;;
 (--) shift; break;;
 (*) exit 1;; # error
 esac
done
remaining=("$@")


PS/2 CL57SX