FUN

UNIX

The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to developing small yet capable software based on the experience of leading developers of the Unix operating system. Early Unix developers were important in bringing the concepts of modularity and reusability into software engineering practice, spawning a "software tools" movement. Over time, the leading developers of Unix (and programs that ran on it) established a set of cultural norms for developing software, norms which became as important and influential as the technology of Unix itself; this has been termed the "Unix philosophy."

The Unix philosophy emphasizes building short, simple, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design.

Contents  

1 Origin

2 The UNIX Programming Environment

3 Program Design in the UNIX Environment

4 Doug McIlroy on Unix programming

5 Do One Thing and Do It Well

6 Eric Raymond’s 17 Unix Rules

7 Mike Gancarz: The UNIX Philosophy

8 "Worse is better"

Origin

Doug McIlroy attributes the philosophy of combining "small, sharp tools" to accomplish larger tasks to Ken Thompson, one of the creators of Unix. The development of pipes formalized the existing principle of stdin-stdout into a philosophy in Version 3 Unix, with older software rewritten to comply. Previously visible in early utilities such as wc, cat, and uniq, McIlroy cites Thompson's grep as what "ingrained the tools outlook irrevocably" in the operating system, with later tools like tr, m4, and sed imitating how grep transforms the input stream.

The UNIX Programming Environment

Rob Pike, co-author of The UNIX Programming Environment

In their preface to the 1984 book, The UNIX Programming Environment, Brian Kernighan and Rob Pike, both from Bell Labs, give a brief description of the Unix design and the Unix philosophy:

Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools.

The authors further write that their goal for this book is "to communicate the UNIX programming philosophy."

Program Design in the UNIX Environment

Brian Kernighan has written at length about the Unix philosophy

In October 1984, Brian Kernighan and Rob Pike published a paper called Program Design in the UNIX Environment. In this paper, they criticize the accretion of program options and features found in some newer Unix systems such as 4.2BSD and System V, and explain the Unix philosophy of software tools, each performing one general function:

Much of the power of the UNIX operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools, and depends more on how the programs fit into the programming environment and how they can be used with other programs than on how they are designed internally. This style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs.

The authors contrast Unix tools such as cat, with larger program suites used by other systems.

The design of cat is typical of most UNIX programs: it implements one simple but general function that can be used in many different applications (including many not envisioned by the original author). Other commands are used for other functions. For example, there are separate commands for file system tasks like renaming files, deleting them, or telling how big they are. Other systems instead lump these into a single "file system" command with an internal structure and command language of its own. (The PIP file copy program found on operating systems like CP/M or RSX-11 is an example.) That approach is not necessarily worse or better, but it is certainly against the UNIX philosophy.

Doug McIlroy on Unix programming

Doug McIlroy (left) with Dennis Ritchie

McIlroy, then head of the Bell Labs CSRC (Computing Sciences Research Center), and inventor of the Unix pipe,summarized the Unix philosophy as follows:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Beyond these statements, he has also emphasized simplicity and minimalism in Unix programming:

The notion of "intricate and beautiful complexities" is almost an oxymoron. Unix programmers vie with each other for "simple and beautiful" honors — a point that's implicit in these rules, but is well worth making overt.

Conversely, McIlroy has criticized modern Linux as having software bloat, remarking that, "adoring admirers have fed Linux goodies into a disheartening state of obesity." He contrasts this with earlier approach taken at Bell Labs when developing and revising Research Unix:

Everything was small... and my heart sinks for Linux when I see the size of it. The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option.

Do One Thing and Do It Well

As stated by McIlroy, and generally accepted throughout the Unix community, Unix has always been expected to follow the concept of "dotadiw," or "Do One Thing and Do It Well." Sources for the acronym "dotadiw" are limited throughout the internet, but is discussed in length during the development and packaging of new operating systems, especially in the Linux community. There has been a point of great contention during the Linux systemd debates of 2014/2015, and especially in the Debian community.

Eric Raymond’s 17 Unix Rules

In his book The Art of Unix Programming that was first published in 2003,Eric S. Raymond, an American programmer and open source advocate, summarizes the Unix philosophy as KISS Principle of "Keep it Simple, Stupid." He provides a series of design rules:

Rule of Modularity

Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.

Rule of Clarity

Developers should write programs as if the most important communication is to the developer, including themself, who will read and maintain the program rather than the computer. This rule aims to make code readable and comprehensible for whoever works on the code in future.

Rule of Composition

Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.

Rule of Separation

Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and back-end engine that interface communicates with. This rule aims to let policies be changed without destabilizing mechanisms and consequently reducing the number of bugs.

Rule of Simplicity

Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.

Rule of Parsimony

Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program’s reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to optimize and maintain; they are easier to delete when deprecated.

Rule of Transparency

Developers should design for visibility and discoverability by writing in a way that their thought process can lucidly be seen by future developers working on the project and using input and output formats that make it easy to identify valid input and correct output. This rule aims to reduce debugging time and extend the lifespan of programs.

Rule of Robustness

Developers should design robust programs by designing for transparency and discoverability, because code that is easy to understand is easier to stress test for unexpected conditions that may not be foreseeable in complex programs. This rule aims to help developers build robust, reliable products.

Rule of Representation

Developers should choose to make data more complicated rather than the procedural logic of the program when faced with the choice, because it is easier for humans to understand complex data compared with complex logic. This rule aims to make programs more readable for any developer working on the project, which allows the program to be maintained.

Rule of Least Surprise

Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ should always mean addition in a calculator program. This rule aims to encourage developers to build intuitive products that are easy to use.

Rule of Silence

Developers should design programs so that they do not print unnecessary output. This rule aims to allow other programs and developers to pick out the information they need from a program's output without having to parse verbosity.

Rule of Repair

Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.

Rule of Economy

Developers should value developer time over machine time, because machine cycles today are relatively inexpensive compared to prices in the 1970s. This rule aims to reduce development costs of projects.

Rule of Generation

Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce human errors and save time.

Rule of Optimization

Developers should prototype software before polishing it. This rule aims to prevent developers from spending too much time for marginal gains.

Rule of Diversity

Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended.

Rule of Extensibility

Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes.

Mike Gancarz: The UNIX Philosophy

In 1994, Mike Gancarz (a member of the team that designed the X Window System), drew on his own experience with Unix, as well as discussions with fellow programmers and people in other fields who depended on Unix, to produce The UNIX Philosophy which sums it up in 9 paramount precepts:

Small is beautiful.

Make each program do one thing well.

Build a prototype as soon as possible.

Choose portability over efficiency.

Store data in flat text files.

Use software leverage to your advantage.

Use shell scripts to increase leverage and portability.

Avoid captive user interfaces.

Make every program a filter.

"Worse is better"

Main article: Worse is better

Richard P. Gabriel suggests that a key advantage of Unix was that it embodied a design philosophy he termed "worse is better", in which simplicity of both the interface and the implementation are more important than any other attributes of the system—including correctness, consistency, and completeness. Gabriel argues that this design style has key evolutionary advantages, though he questions the quality of some results.

For example, in the early days Unix was a monolithic kernel (which means that user processes carried out kernel system calls all on the user stack). If a signal was delivered to a process while it was blocked on a long-term I/O in the kernel, then what should be done? Should the signal be delayed, possibly for a long time (maybe indefinitely) while the I/O completed? The signal handler could not be executed when the process was in kernel mode, with sensitive kernel data on the stack. Should the kernel back-out the system call, and store it, for replay and restart later, assuming that the signal handler completes successfully?

In these cases Ken Thompson and Dennis Ritchie favored simplicity over perfection. The Unix system would occasionally return early from a system call with an error stating that it had done nothing—the "Interrupted System Call", or an error number 4 (EINTR) in today's systems. Of course the call had been aborted in order to call the signal handler. This could only happen for a handful of long-running system calls such as read(), write(), open(), and select(). On the plus side, this made the I/O system many times simpler to design and understand. The vast majority of user programs were never affected because they didn't handle or experience signals other than SIGINT and would die right away if one was raised. For the few other programs—things like shells or text editors that respond to job control key presses—small wrappers could be added to system calls so as to retry the call right away if this EINTR error was raised. Thus, the problem was solved in a simple manner.


======================================================================

WIRELESS USB

Wireless USB is a short-range, high-bandwidth wireless radio communication protocol created by the Wireless USB Promoter Group. Wireless USB is sometimes abbreviated as "WUSB", although the USB Implementers Forum discouraged this practice and instead prefers to call the technology Certified Wireless USB to distinguish it from the competing UWB standard.

Wireless USB was based on the (now defunct) WiMedia Alliance's ultra-wideband (UWB) common radio platform, which is capable of sending 480 Mbit/s at distances up to 3 metres (9.8 ft) and 110 Mbit/s at up to 10 metres (33 ft). It was designed to operate in the 3.1 to 10.6 GHz frequency range, although local regulatory policies may restrict the legal operating range for any given country.

Contents  

1 Uses

2 Development

3 Compatibility options for older hardware

4 Relation to ultra-wideband

5 Wireless USB vs. 60 GHz

6 Comparison of digital RF systems

7 Competitors

Uses

Wireless USB protocols

Wireless USB is used in game controllers, printers, scanners, digital cameras, portable media players, hard disk drives and USB flash drives. It is also suitable for transferring parallel video streams, using USB over ultra-wideband protocols.

Development

The Wireless USB Promoter Group was formed in February 2004 to define the Wireless USB protocol. The group consists of Agere Systems (now merged with LSI Corporation), Hewlett-Packard, Intel, Microsoft, NEC Corporation, Philips, Staccato Communications, Alereon, Wisair and Samsung.

In May 2005, the Wireless USB Promoter Group announced version 1.0 of the Wireless USB specification.

In June 2006, five companies showed the first multi-vendor interoperability demonstration of Wireless USB. A laptop with an Intel host adapter using an Alereon PHY was used to transfer high definition video from a Philips wireless semiconductor solution with a Staccato Communications PHY, all using Microsoft Windows XP drivers developed for Wireless USB.

In October 2006 the U.S. Federal Communications Commission (FCC) approved a Host Wire Adapter (HWA) and Device Wire Adapter (DWA) wireless USB products from WiQuest Communications for both outdoor and indoor use. The first retail product was shipped by IOGEAR using Alereon, Intel and NEC silicon in mid-2007. Around the same time, Belkin, Dell, Lenovo and D-Link began shipping products that incorporated WiQuest technology. These products included embedded cards in the notebook PCs or Hub/Adapter solutions for those PCs that do not currently include Wireless USB. In 2008, a new Wireless USB Docking Station from Kensington was made available through Dell. This product was unique as it was the first product on the market to support video and graphics over a USB connection, by using DisplayLink USB graphics technology. Kensington released a Wireless USB universal docking station in August, 2008 for wireless connectivity between a notebook PC and an external monitor, speakers, and existing wired USB peripherals. Imation announced Q408 availability of a new external Wireless HDD.

On March 16, 2009, the WiMedia Alliance announced transfer agreements for the WiMedia ultra-wideband (UWB) specifications. WiMedia transferred specifications, to the Bluetooth Special Interest Group (SIG), Wireless USB Promoter Group and the USB Implementers Forum. After the technology transfer the WiMedia Alliance ceased operations.In October 2009, the Bluetooth Special Interest Group has dropped development of UWB as part of the alternative MAC/PHY, Bluetooth 3.0/High Speed solution. A small, but significant, number of former WiMedia members had not and would not sign up to the necessary agreements for the intellectual property transfer. The Bluetooth group is now turning its attention from UWB to 60 GHz.

On September 29, 2010, version 1.1 of the Wireless USB Specification was announced.It delivers several backwards-compatible improvements: UWB upper band support for frequencies 6 GHz and above, improved power management and consumption, and support for NFC and proximity based association.

Compatibility options for older hardware

The WUSB architecture allows up to 127 devices to connect directly to a host. Because there are no wires or ports, there is no longer a need for hubs.

However, to facilitate migration from wired to wireless, WUSB introduced a new Device Wire Adapter (DWA) class. Sometimes referred to as a "WUSB hub", a DWA allows existing USB 2.0 devices to be used wirelessly with a WUSB host.

WUSB host capability can be added to existing PCs through the use of a Host Wire Adapter (HWA). The HWA is a USB 2.0 device that attaches externally to a desktop or laptop's USB port or internally to a laptop's MiniCard interface.

WUSB also supports dual-role devices (DRDs), which in addition to being a WUSB device, can function as a host with limited capabilities. For example, a digital camera could act as a device when connected to a computer and as a host when transferring pictures directly to a printer.

Relation to ultra-wideband

UWB is a general term for radio communication using pulses of energy which spread emitted Radio Frequency energy over 500 MHz+ of spectrum or exceeding 20% fractional bandwidth within the frequency range of 3.1 GHz to 10.6 GHz as defined by the FCC ruling issued for UWB in Feb. 2002. UWB is not specific to WiMedia or any other company or group and there are in fact a number of groups and companies developing UWB technology totally unrelated to WiMedia. Some companies use UWB for ground penetrating radar, through wall radar and yet another company Pulse~LINK used it as part of a whole home entertainment network using UWB for transmission over both wired and wireless media. WUSB is a protocol promulgated by the USB Implementers Forum that uses WiMedia's UWB radio platform. Other protocols that have announced their intention to use WiMedia's UWB radio platform include Bluetooth and the WiMedia Logical Link Control Protocol.

Wireless USB vs. 60 GHz

A few issues differentiate Wireless USB from the use of the 60 GHz band as promoted by the Wireless Gigabit Alliance:

Line of sight

At 60 GHz, radio communication is blocked by any intervening object, which implies the need for open line of sight. Wireless USB is based on the Ultra-WideBand (UWB) platform, which operates in the 3.1 to 10.6 GHz frequency range, and thus can pass through intervening bodies.

Mobility

The 60 GHz technology is appealing to the wireless video market because it is supposed to deliver multi-gigabit-speed wireless communications.In order to support such heavy demands, the underlying MAC layer should be able to process this huge amount of data. For these requirements, the 60 GHz-based products need higher power consumption, and more electronics, which are less suitable for mobile units or devices.

Comparison of digital RF systems

Wireless USB vs. 802.11a/b/g and Bluetooth

Specification Wireless USB Specification Rev. 1.1 Bluetooth 4.0 Wi-Fi (IEEE 802.11n) Wi-Fi (IEEE 802.11ac) Bluetooth 2.1 + EDR

Frequency band 3.1 GHz–10.6 GHz 2.4 GHz 2.4 GHz and/or 5 GHz 5 GHz 2.4 GHz

Bandwidth 53-480 Mbit/s 24 Mbit/s Max. 600 Mbit/s per band Max. 6.93 Gbit/s per band Max. 3 Mbit/s

Distance 3–10 m        unknown distance 100 m unknown 1–100 m depending on output

Modulation MB-OFDM MB-OFDM DSSS, DBPSK, DQPSK, CCK, OFDM OFDM GFSK

Standardization September 2010 June 2010 September 2009 December 2013 July 2007

Competitors

Other forms of USB over wireless exist, such as those based on the competing direct sequence ultra-wideband technology by Cable-Free USB.The same is also true for other radio frequency based wire replacement systems which can carry USB. The result is that the name Certified Wireless USB was adopted to allow consumers to identify which products would be adherent to the standard and would support the correct protocol and data rates.

There is also USB over IP, which may use any IP-based networking solution to transfer USB traffic wirelessly. For example, with proper drivers the host side may use 802.11a/b/g/n/ac Wi-Fi (or wired Ethernet) to communicate with the device side

======================================================================

Pyaar karo toh dhokha mat dena,
Pyar ko aansu ka tohfa mat dena
Dil se roye koi tumhe yaad kar ke
Aisa kabhi kisi ko moka mat dena

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Pyar jab milta nahi toh hota hi kyun hain…………
Wife: Woh admi jo drink kar raha hai, Usko maine 10 saal pehle shadi ke liye inkaar kia tha. Dekho who aaj tak sharab pee raha hai!
Husband: Wow! itni lambi celebration!

==============================================

Ek gora aadmi tha. Jab uska ladka paida hua toh woh kala tha.

Tabhi woh apni patni ke paas jata hai aur poochta hai, “Yaar main bhi gora tha tum bhi gori thi to bachcha kaise kala paida ho gaya”

Aur phir uski biwi ne jawab diya, “Darling main bhi hot tum bhi hot sayad bachcha jal gaya hoga.”

==============================================

Ek ladki apny boy friend ke saath nayi garri main long drive per jaa rahi thi achanak raastey mein larki kehnay lagi…..“suno ! kya tum aik haath se garri chala saktay ho?”
Kyu nahi.. ladke ne bade fakher se garden akraaii…

Aur phir larki ne aahista se kaha, “Toh phir doosray haath se apni naak saaf karlo”

=================================================

Officer: Dekho, humme aisa chaukidaar chahiye jo sehatmand ho, chust, chalak aur chaukanna ho, jarurat parne par jisse hum daat bhi saake…
Yadi tumhare andar yeh saare guun shamil hai to tumhe yeh naukri mil sakti hai.

Umeedwaar : Saheb yeh saare gun meri biwi mein hai, usse bulau?

==================================================

Patni: Suno ji mere saath tumhare dus saal kaise beete?

Pati: Ek second ki tarah.

Patni: Agar main tumse 10000 rs mangu toh kaisa lagega?

Pati: Chavnni ki tarah.
Patni: Jara 10000 rs dena toh

Pati: Abhi deta hu ek second mein

================================================

Customer: Ek kilo gaay(cow) ka doodh dena.
Shopkeper: Lekin tumhara bartan toh bahut chhota hai.

Customer: Theek hai toh phir bakri ka de de.

================================================

Ek aadmi apne dost ki kabar par phool daal raha hota hai.

Aur samne wale kabar mein bhi, ek aadmi apne dost ki kabar par chawal daal raha hota hai.

Pehla aadmi doosre se kehta hai, “Ye tumhara dost phool sunghne kab uthega?”

Doosra aadmi, “Jab tumhara dost chawal khane uthe ga.”

_________________________________________________________
_________________________________________________________

Agar khwab such nahi hote to insaan sota kyu h
Jb yahi pyar aankho ke samne kisi or ka ho jaye
Toh phir yeh pagal dil itnaa rotaa kyun hain…….

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Zubaan khamosh ankhon me nami hogi
Yahi bas meri ek dastan-e-zindagi hogi
Bharne ko toh har zakham bhar jayega
Kese bharegi wo jagah jaha teri kami hogi

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 
Dukh me khusi ki wajah banti h mohabbat,
Dard me yaado ki wajah banti h mohabbat
Jab kuch b acha nai lagta hume duniya me
Tab humare jine ki wajah banti h Mohabbat

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Lag ja gale ki phir ye haseen raat ho na ho

Shayd fir es janam me mulaaqaat ho na ho

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''