text:
This chapter provides a foundation for later chapters. Background and simple definitions are followed by an overview of the STREAMS mechanisms. Because the application developer is concerned with a different subset of STREAMS interfaces than the kernel-level developer, application and kernel levels are described separately.
STREAMS is a general, flexible programming model for UNIX system communication services. STREAMS defines standard interfaces for character input/output (I/O) within the kernel, and between the kernel and the rest of the UNIX system. The mechanism consists of a set of system calls, kernel resources, and kernel routines.
STREAMS enables you to create modules to provide standard data communications services and then manipulate the modules on a stream. From the application level, modules can be dynamically selected and interconnected. No kernel programming, compiling, and link editing are required to create the interconnection.
STREAMS provides an effective environment for kernel services and drivers requiring modularity. STREAMS parallels the layering model found in networking protocols. For example, STREAMS is suitable for:
Implementing network protocols
Developing character device drivers
Developing network controllers (for example, for an Ethernet card)
I/O terminal services
The fundamental STREAMS unit is the stream. A stream is a full-duplex bidirectional data-transfer path between a process in user space and a STREAMS driver in kernel space. A stream has three parts: a stream head, zero or more modules, and a driver.
The capitalized word "STREAMS" refers to the STREAMS programming model and facilities. The word "stream" refers to an instance of a full-duplex path using the model and facilities between a user application and a driver.
A stream is a data path that passes data in both directions between a STREAMS driver in kernel space, and a process in user space. An application creates a stream by opening a STREAMS device (see Figure 1–1).
A stream head is the end of the stream nearest the user process. It is the interface between the stream and the user process. When a STREAMS device is first opened, the stream consists of only a stream head and a STREAMS driver.
A STREAMS module is a defined set of kernel-level routines and data structures. A module does "black-box" processing on data that passes through it. For example, a module converts lowercase characters to uppercase, or adds network routing information. A STREAMS module is dynamically pushed on the stream from the user level by an application. Full details on modules and their operation are covered in Chapter 10, STREAMS Modules.
A STREAMS device driver is a character device driver that implements the STREAMS interface. A STREAMS device driver exists below the stream head and any modules. It can act on an external I/O device, or it can be an internal software driver, called a pseudo-device driver. The driver transfers data between the kernel and the device. The interfaces between the driver and kernel are known collectively as the Solaris operating environment Device Driver Interface/Driver Kernel Interface (Solaris operating environment DDI/DKI). The relationship between the driver and the rest of the UNIX kernel is explained in Writing Device Drivers. Details of device drivers are explained in Chapter 9, STREAMS Drivers.
Data on a stream is passed in the form of messages. Messages are the means by which all I/O is done under STREAMS. Each stream head, STREAMS module, and driver has a read sideand a write side. When messages go from one module's read side to the next module's read side, they are said to be traveling upstream. Messages passing from one module's write side to the next module's write side are said to be traveling downstream. Kernel-level operation of messages is discussed in Message Components.
Each stream head, driver, and module has its own pair of queues, one queue for the read side and one queue for the write side. Messages are ordered into queues, generally on a first-in, first-out basis (FIFO), according to priorities associated with them. Kernel-level details of queues are covered in Structure of a Message Queue.
To communicate with a STREAMS device, an application's process uses read(2), write(2), getmsg(2), getpmsg(2), putmsg(2), putpmsg(2), and ioctl(2) to transmit or receive data on a stream.
From the command line, configure a stream with autopush(1M). From within an application, configure a stream with ioctl(2) as described in streamio(7I).
The ioctl(2) interface performs control operations on and through device drivers that cannot be done through the read(2) and write(2) interfaces. ioctl(2) operations include pushing and popping modules on and off the stream, flushing the stream, and manipulating signals and options. Certain ioctl(2) commands for STREAMS operate on the whole stream, not just the module or driver. The streamio(7I) manual page describes STREAMS ioctl(2) commands. Chapter 4, Application Access to the STREAMS Driver and Module Interfaces details interstream communications.
The modularity of STREAMS allows one or more upper streams to route data into one or more lower streams. This process is defined as multiplexing (mux). Example configurations of multiplexers are described in Configuring Multiplexed Streams.
Polling within STREAMS enables a user process to detect events occurring at the stream head, specifying the event to look for and the amount of time to wait for it to happen. An application might need to interact with multiple streams. The poll(2) system call enables applications to detect events that occur at the head of one or more streams. Chapter 3, STREAMS Application-Level Mechanisms describes polling.
Flow control regulates the rate of message transfer between the user process, stream head, modules, and driver. With flow control, a module that cannot process data at the rate being sent can queue the data to avoid flooding modules upstream. Flow control is local to each module or driver, and is voluntary. Chapter 8, STREAMS Kernel-Level Mechanisms describes flow control.
The STREAMS framework is most useful when modularity and configurability are issues. For instance, network drivers, terminal drivers, and graphics I/O device drivers benefit from using STREAMS. Modules can be pushed (added) and popped (removed) to create desired program behavior.
STREAMS is general enough to provide modularity between a range of protocols. It is a major component in networking support utilities for UNIX System V because it facilitates communication between network protocols.
An application opens a STREAMS device, which creates the stream head to access the device driver. The stream head packages the data from the user process into STREAMS messages, and passes it downstream into kernel space. One or more cooperating modules can be pushed on a stream between the stream head and driver to customize the stream and perform any of a range of tasks on the data before passing it on. On the other hand, a stream might consist solely of the stream head and driver, with no module at all.
To a user application, a STREAMS device resembles an ordinary character I/O device, as it has one or more nodes associated with it in the file system, and is opened by calling open(2).
The file system represents each device as a special file. There is an entry in the file for the major device number, identifying the actual device driver that will activate the device. There are corresponding separate minor device numbers for each instance of a particular device, for example, for a particular port on a serial card, or a specific pseudo-terminal such as those used by a windowing application.
Different minor devices of a driver cause a separate stream to be connected between a user process and the driver. The first open call creates the stream; subsequent open calls respond with a file descriptor referencing that stream. If the same minor device is opened more than once, only one stream is created.
However, drivers can support a user process getting a dedicated stream without the application distinguishing which minor device is used. In this case, the driver selects any unused minor device to be used by the application. This special use of a minor device is called cloning. Chapter 9, STREAMS Drivers describes properties and behavior of clone devices.
Once a device is opened, a user process can send data to the device by calling write(2), and receive data from the device by calling read(2). Access to STREAMS drivers using read and write is compatible with the traditional character I/O mechanism. STREAMS-specific applications also can call getmsg(2), getpmsg(2), putmsg(2), and putpmsg(2) to pass data to and from the stream.
The close(2) interface closes a device and dismantles the associated stream when the last open reference to the stream is closed. The exit(2) interface terminates the user process and closes all open files.
If the stream exerts flow control, the write(2) call blocks until flow control has been relieved, unless the file has been specifically advised not to. open(2) or fcntl(2) can be used to control this nonblocking behavior.
Example 1–1 shows how an application might use a simple stream. Here, the user program interacts with a communications device that provides point-to-point data transfer between two computers. Data written to the device is transmitted over the communications line, and data arriving on the line is retrieved by reading from the device.
#include <sys/fcntl.h> #include <stdio.h> main() { char buf[1024]; int fd, count; if ((fd = open("/dev/ttya", O_RDWR)) < 0) { perror("open failed"); exit(1); } while ((count = read(fd, buf, sizeof(buf))) > 0) { if (write(fd, buf, count) != count) { perror("write failed"); break; } } exit(0); }
In this example, /dev/ttya identifies an instance of a serial communications device driver. When this file is opened, the system recognizes the device as a STREAMS device and connects a stream to the driver. Figure 1–3 shows the state of the stream following the call to open(2).
This example illustrates a simple loop, with the application reading data from the communications device, then writing the input back to the same device, echoing all input back over the communications line. The program reads up to 1024 bytes at a time, and then writes the number of bytes just read.
read(2) returns the available data, which can contain fewer than 1024 bytes. If no data is currently available at the stream head, read(2) blocks until data arrives.
The application program must loop on read(2) until the desired number of bytes are read. The responsibility for the application getting all the bytes it needs is that of the application developer, not the STREAMS facilities.
Similarly, the write(2) call attempts to send the specified number of bytes to /dev/ttya. The driver can implement a flow-control mechanism that prevents a user from exhausting system resources by flooding a device driver with data.
Developers implementing STREAMS device drivers and STREAMS modules use a set of STREAMS-specific functions and data structures. This section describes some basic kernel-level STREAMS concepts.
The stream head is created when a user process opens a STREAMS device. It translates the interface calls of the user process into STREAMS messages, which it sends to the stream. The stream head also translates messages originating from the stream into a form that the application can process. The stream head contains a pair of queues; one queue passes messages upstream from the driver, and the other passes messages to the driver. The queues are the pipelines of the stream, passing data between the stream head, modules, and driver.
A STREAMS module does processing operations on messages passing from a stream head to a driver or from a driver to a stream head. For example, a TCP module might add header information to the front of data passing downstream through it. Not every stream requires a module. There can be zero or more modules in a stream.
Modules are stacked (pushed) onto and unstacked (popped) from a stream. Each module must provide open(), close(), and put() entries and provides a service() entry if the module supports flow control.
Like the stream head, each module contains a pair of queue structures, although a module only queues data if it is implementing flow control. Figure 1–4 shows the queue structures Au/Ad associated with Module A ("u" for upstream "d" for downstream) and Bu/Bd associated with Module B.
The two queues operate completely independently. Messages and data can be shared between upstream and downstream queues only if the module functions are specifically programed to share data.
Within a module, one queue can refer to the messages and data of the opposing queue. A queue can directly refer to the queue of the successor module (adjacent in the direction of message flow). For example, in Figure 1–4, Au (the upstream queue from Module A) can reference Bu (the upstream queue from Module B). Similarly Queue Bd can reference Queue Ad.
Both queues in a module contain messages, processing procedures, and private data.
Blocks of data that pass through, and can be operated on by, a module.
Individual put and service routines on the read and write queues process messages. The put procedure passes messages from one queue to the next in a stream and is required for each queue. It can do additional message processing. The service procedure is optional and does deferred processing of messages. These procedures can send messages either upstream or downstream. Both procedures can also modify the private data in their module.
Data private to the module (for example, state information and translation tables).
Entry points must be provided. The open routine is invoked when the module is pushed onto the stream or the stream is reopened. The close is invoked when the module is popped or the stream is closed.
A module is initialized by either an I_PUSH ioctl(2), or pushed automatically during an open if a stream has been configured by the autopush(1M) mechanism, or if that stream is reopened.
A module is disengaged by close or the I_POP ioctl(2).
STREAMS device drivers are structurally similar to STREAMS modules and character device drivers. The STREAMS interfaces to driver routines are identical to the interfaces used for modules. For instance they must both declare open, close, put, and service entry points.
There are some significant differences between modules and drivers.
A driver:
Must be able to handle interrupts from the device.
Is represented in file system by a character-special file.
Is initialized and disengaged using open(2) and close(2). open(2) is called when the device is first opened and for each reopen of the device. close(2) is only called when the last reference to the stream is closed.
Both drivers and modules can pass signals, error codes, and return values to processes using message types provided for that purpose.
All kernel-level input and output under STREAMS is based on messages. STREAMS messages are built in sets of three:
a message header structure (msgb(9S)) that identifies the message instance.
a data block structure (datab(9S)) points to the data of the message.
the data itself
Each data block and data pair can be referenced by one or more message headers. The objects passed between STREAMS modules are pointers to messages. Messages are sent through a stream by successive calls to the put procedure of each module or driver in the stream. Messages can exist as independent units, or on a linked list of messages called a message queue. STREAMS utility routines enable developers to manipulate messages and message queues.
All STREAMS messages are assigned message types to indicate how they will be used by modules and drivers and how they will be handled by the stream head. Message types are assigned by the stream head, driver, or module when the message is created. The stream head converts the system calls read, write, putmsg, and putpmsg into specified message types, and sends them downstream. It responds to other calls by copying the contents of certain message types that were sent upstream.
Sometimes messages with urgent information, such as a break or alarm conditions, must pass through the stream quickly. To accommodate them, STREAMS uses message queuing priority, and high-priority message types. All messages have an associated priority field. Normal (ordinary) messages have a priority of zero, while priority messages have a priority band greater than zero. High-priority messages have a high priority by virtue of their message type, are not blocked by STREAMS flow control, and are processed ahead of all ordinary messages on the queue.
Nonpriority, ordinary messages are placed at the end of the queue following all other messages that can be waiting. Priority messages can be either high priority or priority band messages. High-priority messages are placed at the head of the queue but after any other high-priority messages already in the queue. Priority band messages enable support of urgent, expedited data. Priority band messages are placed in the queue in the following order:
after high-priority messages but before ordinary messages.
below all messages that have a priority greater than or equal to their own.
above any messages with a lesser priority.
Figure 1–5 shows the message queueing priorities.
High-priority message types cannot be changed into normal or priority band message types. Certain message types come in equivalent high-priority or ordinary pairs (for example, M_PCPROTO and M_PROTO), so that a module or device driver can choose between the two priorities when sending information.
A queue is an interface between a STREAMS driver or module and the rest of the stream (see queue(9S)). The queue structure holds the messages, and points to the STREAMS processing routines that should be applied to a message as it travels through a module. STREAMS modules and drivers must explicitly place messages on a queue, for example, when flow control is used.
Each open driver or pushed module has a pair of queues allocated, one for the read side and one for the write side. Queues are always allocated in pairs. Kernel routines are available to access each queue's mate. The queue's put or service procedure can add a message to the current queue. If a module does not need to queue messages, its put procedure can call the neighboring queue's put procedure.
The queue's service procedure deals with messages on the queue, usually by removing successive messages from the queue, processing them, and calling the put procedure of the next module in the stream to pass the message to the next queue. Chapter 7, STREAMS Framework – Kernel Level discusses the service and put procedures in more detail.
Each queue also has a pointer to an open and close routine. The open routine of a driver is called when the driver is first opened and on every successive open of the stream. The open routine of a module is called when the module is first pushed on the stream and on every successive open of the stream. The close routine of the module is called when the module is popped (removed) off the stream, or at the time of the final close. The close routine of the driver is called when the last reference to the stream is closed and the stream is dismantled.
Previously, streams were described as stacks of modules, with each module (except the head) connected to one upstream module and one downstream module. While this can be suitable for many applications, others need the ability to multiplex streams in a variety of configurations. Typical examples are terminal window facilities, and internetworking protocols (that might route data over several subnetworks).
An example of a multiplexer is a module that multiplexes data from several upper streams to a single lower stream. An upper stream is one that is upstream from the multiplexer, and a lower stream is one that is downstream from the multiplexer. A terminal windowing facility might be implemented in this fashion, where each upper stream is associated with a separate window.
A second type of multiplexer might route data from a single upper stream to one of several lower streams. An internetworking protocol could take this form, where each lower stream links the protocol to a different physical network.
A third type of multiplexer might route data from one of many upper streams to one of many lower streams.
The STREAMS mechanism supports the multiplexing of streams through special pseudo-device drivers. A user can activate a linking facility mechanism within the STREAMS framework to dynamically build, maintain, and dismantle multiplexed stream configurations. Simple configurations like those shown previously can be combined to form complex, multilevel multiplexed stream configurations.
STREAMS multiplexing configurations are created in the kernel by interconnecting multiple streams. Conceptually, a multiplexer can be divided into two components—the upper multiplexer and the lower multiplexer. The lower multiplexer acts as a stream head for one or more lower streams. The upper multiplexer acts as a device for one or more upper streams. How data is passed between the upper and lower multiplexer is up to the implementation. Chapter 13, STREAMS Multiplex Drivers covers implementing multiplexers.
The Solaris operating environment kernel is multithreaded to make effective use of symmetric shared-memory multiprocessor computers. All parts of the kernel, including STREAMS modules and drivers, must ensure data integrity in a multiprocessing environment. For the most part, developers must ensure that concurrently running kernel threads do not attempt to manipulate the same data at the same time. The STREAMS framework provides multithreaded (MT) STREAMS perimeters, which provides the developer with control over the level of concurrency allowed in a module. The DDI/DKI provides several advisory locks for protecting data. See Chapter 12, Multithreaded STREAMS for more information.
Using STREAMS, you can create modules that present a service interface to any neighboring module or device driver, or between the top module and a user application. A service interface is defined in the boundary between two neighbors.
In STREAMS, a service interface is a set of messages and the rules that allow these messages to pass across the boundary. A module using a service interface, for example, receives a message from a neighbor and responds with an appropriate action (perhaps sending back a request to retransmit) depending on the circumstances.
You can stack a module anywhere in a stream, but connecting sequences of modules with compatible protocol service interfaces is better. For example, a module that implements an X.25 protocol layer, as shown in Figure 1–6, presents a protocol service interface at its input and output sides. In this case, other modules should be connected to the input and output side if they have the compatible X.25 service interface only.
With STREAMS, you can manipulate modules from the user application level, interchange modules with common service interfaces, and change the service interface to a STREAMS user process. These capabilities yield further benefits when working with networking services and protocols:
User-level programs can be independent of underlying protocols and physical communication media.
Network architectures and higher-level protocols can be independent of underlying protocols, drivers, and physical communication media.
Higher-level services can be created by selecting and connecting lower-level services and protocols.
The following examples show the benefits of STREAMS capabilities for creating service interfaces and manipulating modules. These examples are only illustrations and do not necessarily reflect real situations.
Figure 1–6 shows how an X.25 protocol module can work with different drivers on different machines by using compatible service interfaces. The X.25 protocol module interfaces are Connection Oriented Network Service (CONS) and Link Access Protocol – Balanced (LAPB).
You can alternate protocol modules and device drivers on a system if the alternates are implemented to an equivalent service interface.
Figure 1–7 shows how STREAMS can move functions between kernel software and front-end firmware. A common downstream service interface lets the transport protocol module be independent of the number or type of modules below it. The same transport module will connect without modification to either an X.25 module or X.25 driver that has the same service interface.
By shifting functions between software and firmware, you can produce cost-effective, functionally equivalent systems over a wide range of configurations. This means you can swiftly incorporate technological advances. The same transport protocol module can be used on a lower-capacity machine, where economics preclude the use of front-end hardware, and also on a larger scale system where a front-end is economically justified.
Figure 1–8 shows the same canonical module (for example, one that provides delete and kill processing on character strings) reused in two different streams. This module would typically be implemented as a filter, with no service interface. In both cases, a TTY interface is presented to the stream's user process because the module is nearest the stream head.


text:
Yesterday we made a paper chain as part of our "holiday decorating with what we have." I want my kids to know that this time of year shouldn't just be about receiving cool gifts but is also about helping others, so written inside each chain is a small service they can help with.
- Spend the morning at the local old folks home
- Give the dog a bath
- Write Great-Grandma a letter
- Donate toys to children who need them more than we do
- Bring food to the local food pantry
- Help with dishes

subset: commoncrawl


text:
Books, Movies, Music
JCPL Catalog
Reading programs and Book Groups
Kids & Teens
Kids Zone
Teens Only
For Parents and Teachers
Student Portal
Main Content
Teen literature is brilliant
Butter by Erin Jade Lange
April 14-20 is National Library Week. You may wonder to yourself what the big deal is. Well I'll tell you why it's a big deal. Libraries are awesome!
Your local library is a Mecca that leads you to culture, knowledge and just a place to hang out in general. You can find just about anything at the library whether it be books, movies, music, and stuff to do.
National Library Week also has an entire day devoted to celebrating teen literature: Thursday April 18th. Not adult literature. Not children's literature. TEEN literature. That is how important teens are to the library; they get their own special day to celebrate and honor the brilliance that is teen literature.
Simply put…. teen literature is brilliant. It's more than brilliant it is absorbing, deep, compassionate, eye-opening….it's life changing. Teen literature today, for the most part, is meant to strike a chord. It is meant to grab your attention. It is supposed to make you think; to look at yourself and discover who you are.
There are so many great teen books out there just waiting to be read, talked about and celebrated. Thus a whole day devoted solely to teen literature.
Here are some teen titles that I have read….yes I am 26 years old and still read teen books…..teen literature is awesome.
Butter by Erin Jade Lange
Stoner & Spaz by Ron Koertge
Boy Toy by Barry Lyga
Also read anything written by John Green and Ellen Hopkins. You cannot go wrong!


text:
Jim Nielsen
Jim Nielsen currently lives in NYC working as the lead designer for an enterprise software startup. As much as he loves the city, he misses the red rocks of his boyhood home and the beauty of the desert southwest. He loves to ski, golf, fish, read, eat street tacos, learn new things (currently he's into calligraphy), and take road trips immersed in the music of Bob Dylan. However, his true passion is to analyze complexity and transform it into simplicity.
Connecting an API-Driven Web App with Javascript
Building an API-Driven Web App With HTML and CSS
Designing an API-Driven Web App in Sketch
Planning a Basic API-Driven Web App
Undress to Impress; Check Your Websites Without CSS
Getting the Hang of Hanging Punctuation
Implementing the Float Label Form Pattern
Quick Tip: Name Your SASS Variables Modularly
Filler Content: Tools, Tips and a Dynamic Example
Build a Responsive, Single Page Portfolio with Sass and Compass
Bring Your Forms Up to Date With CSS3 and HTML5 Validation
Quick Tip: Don't Forget the "optgroup" Element


text:
"What makes 'good tape'? That is the question that has consumed my life for the past 20 years, and I have an answer for you…"
– Alex Blumberg
How do you create a blockbuster podcast? This episode explores the tips, tricks, and best practices of a master.
My guest is Alex Blumberg, who cut his teeth on the king of all radio shows (This American Life) and recently co-founded Gimlet Media. Gimlet swiftly conquered the iTunes rankings with two blockbuster podcasts: Reply All and StartUp.
Podcasters everywhere asked: how the hell does he do it?
This episode provides some answers. Part 2 also includes a sample of my upcoming episode with Arnold Schwarzenegger (!!!).
You can find the transcript of Part 1 (Episode 58) here. You can find the transcript of Part 2 (Episode 59) here. Transcripts of all episodes can be found here.
This discussion is split into two parts, and we cover a ton. Please listen to both parts, as they work together. We discuss what Alex learned from Ira Glass, his field recording gear, the nuts and bolts of producing world-class audio narrative, and much more.
Part 1 is my interview and conversation with Alex.
Part 2 is ~40 minutes of an amazing masterclass Alex taught on creativeLIVE, including the art of the interview, the power of the right question, and more (Get all 21 videos here).
- Listen to them on iTunes.
- Stream by clicking here: Part 1 and Part 2.
- Download both as MP3s by right-clicking here (Part 1, Part 2) and choosing "save as".
This episode is sponsored by Onnit. I have used Onnit products for years. If you look in my kitchen or in my garage you will find Alpha BRAIN, chewable melatonin (for resetting my clock while traveling), kettlebells, maces, battle ropes, and steel clubs. It sounds like a torture chamber, and it basically is. A torture chamber for self-improvement! Ah, the lovely pain. To see a list of my favorite pills, potions, and heavy tools, click here.
This podcast is also brought to you by 99Designs, the world's largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results. Click this link and get a free $99 upgrade. Give it a test run.
QUESTION(S) OF THE DAY: What are your 2-3 favorite podcasts and why? What makes them unique? Please let me know in the comments!
If you like this episode, you'll also love my episode with Neil Strauss, 7x New York Times bestselling author. He's cray-cray like me.
Scroll below for links and show notes…
Selected Links from the Episode
- Learn more and listen to Gimlet Media
- Learn more about Pro Tools
- Pick up Alex's recommended equipment for field recording:
AT8035 Microphone | Tascam DR-100KII Recorder
Sony MDR 7506 HeadPhones | XLR Cable
- Learn more about Chart Beat analytics software
- Hiroshima by John Hersey
- The Fog of War directed by Errol Morris (Watch it)
- Man on Wire, the story of Philippe Petit
- On the Run by Alice Gotham
- Want to master the art of storytelling? Check out Alex's full creativeLIVE course, which is absolute gold.
Show Notes
- On the 4-5-month startup burnout phase [3:24]
- Defining tracking and work flow. What makes something worthy of being included in the show? [4:14]
- What makes good tape? [6:14]
- What makes a world-class editor? Acknowledging Ira Glass and his time at This American Life [12:15]
- Defining the role of a "producer" [22:17]
- The nitty gritty of producing high-level narrative podcasts. Includes: editing software, planning timelines, and much more [25:00]
- Tools for capturing tape in the field [30:00]
- The nuts and bolts of recording in the field, as well as tips for capturing the 'vivid moments' [31:14]
- Microphone tips: directional vs. omnidirectional? [34:20]
- Metrics used to define progress at Gimlet Media [36:00]
- The story of acquiring a position as a top radio producer [37:29]
- Transitioning from This American Life to Planet Money [49:12]
- Why good radio doesn't apply to television shows [51:00]
- On the value of perfectionism [55:45]
- Good and bad habits picked up from This American Life and Ira Glass [58:20]
- Turning a bad situation into a good one – Deconstructing We Made a Mistake [1:12:20]
- Rapid fire questions: most gifted books, favorite documentary films, and more [1:21:10]
People Mentioned
Posted on: January 29, 2015.
Please check out Tribe of Mentors, my newest book, which shares short, tactical life advice from 100+ world-class performers. Many of the world's most famous entrepreneurs, athletes, investors, poker players, and artists are part of the book. The tips and strategies in Tribe of Mentors have already changed my life, and I hope the same for you. Click here for a sample chapter and full details. Roughly 90% of the guests have never appeared on my podcast.
Who was interviewed? Here's a very partial list: tech icons (founders of Facebook, Twitter, LinkedIn, Craigslist, Pinterest, Spotify, Salesforce, Dropbox, and more), Jimmy Fallon, Arianna Huffington, Brandon Stanton (Humans of New York), Lord Rabbi Jonathan Sacks, Ayaan Hirsi Ali, Ben Stiller, Maurice Ashley (first African-American Grandmaster of chess), Brené Brown (researcher and bestselling author), Rick Rubin (legendary music producer), Temple Grandin (animal behavior expert and autism activist), Franklin Leonard (The Black List), Dara Torres (12-time Olympic medalist in swimming), David Lynch (director), Kelly Slater (surfing legend), Bozoma Saint John (Beats/Apple/Uber), Lewis Cantley (famed cancer researcher), Maria Sharapova, Chris Anderson (curator of TED), Terry Crews, Greg Norman (golf icon), Vitalik Buterin (creator of Ethereum), and nearly 100 more. Check it all out by clicking here.


text:
Sean Hayes, best known for his role as the outlandish Jack on "Will & Grace" is finally getting candid about his personal life and addressing critics who say he remained in the closet about his sexuality.
The actor gave an in-depth interview with The Advocate, in which he acknowledged that he's gay.
"I am who I am," he told the mag. "I was never in, as they say. Never."
During his run on the hit NBC sitcom, Sean was coyer about his sexuality, previously telling the Detroit Free Press, "When I play a gay character I want to be as believable as possible. And when I'm playing a straight character I also want to be as believable as possible. So the less that people know about my personal life, the more believable I can be as a character."
Sean told the mag he doesn't feel the need to explain anything to the public.
"Nobody owes anything to anybody. You are your authentic self to whom and when you choose to be, and if you don't know somebody, then why would you explain to them how you live your life?" he told the mag, adding that he's willing to take on critics who might say otherwise.
"I feel like I've contributed monumentally to the success of the gay movement in America," he continued. "And if anyone wants to argue that, I'm open to it."
As for his dating life, Sean remained mum on the details, but revealed "I spend time with a special someone in my life…That's it. That's all I need… I don't need events. I don't do a lot. I live my life like an 85-year-old man. I'm just quiet. It's fantastic."
Related Content from AccessHollywood.com:
VIEW THE PHOTOS: Primetime Hunks
VIEW THE PHOTOS: Celebrity Gays & Their Gal Pals
PLAY IT NOW: Sean Hayes & Jane Krakowski Talk 'Damn Yankees '
PLAY IT NOW: 'The Bucket List' Hollywood Premiere
MORE ACCESS ON THESE TOPICS: TV - NBC - Broadway - Movies - LGBT


text:
Q&A with Head Coach Brad Kreutzkamp
Related Links
In early September, Brad Kreutzkamp, then associate head coach of the UC San Diego men's water polo team, was tabbed as the new head coach of the Triton women's water polo squad. The UCSD men were 181-93 during Kreutzkamp's tenure with the program. Prior to arriving in La Jolla, he was head boys' and girls' coach at both Grossmont and Patrick Henry High Schools locally.
Since his appointment, the 39-year-old Kreutzkamp, who has logged more than 10 years at UCSD, has brought in Jenna Murphy as his assistant coach, put his club through its fall practice season, signed his first recruit and currently has the Tritons training for their 2010 opener, Jan. 23, at the Michigan Invitational. With "The Kreutzkamp Era" of UCSD women's water polo set to commence, he spent some time recently talking about his new position, the transition from men's to women's polo and what he envisions for the future.
Q: What went through your mind when you were offered the head coaching position with the UCSD women's water polo team?
KREUTZKAMP: "Wow. What have I done?" Seriously, though, I had such a great relationship with the men's team here and we were certainly successful at a level that I found myself thinking and rethinking my decision during the whole process. However, not many people know that once upon a time I had a lot of success coaching women and it just felt right to take what I had learned on the men's side and get back into to the women's game.
Q: Why did you decide to pursue the women's water polo position and what was the toughest part of that decision-making process?
KREUTZKAMP: I ultimately decided that it was time to take the next step in my career. I had a lot of autonomy with the men's team so it wasn't a control thing. But when you decide that coaching is going to be a career move for you, being a head coach is the pinnacle in this profession. Hands down the hardest part of the decision was the relationships that I will be giving up with the men's team. Being so involved with that program for the past 11 years made it very hard to walk away.
Q: What type of learning curve have you had since officially taking over the reins?
KREUTZKAMP: It actually has gone surprising smooth. I credit that to student athletes that I inherited and the effort of my assistant coach Jenna Murphy. She has a wealth of knowledge and so much enthusiasm that the transition has gone pretty well I think.
Q: What's been the most pleasant surprise so far?
KREUTZKAMP: Without a doubt the talent level of the team. We have some very talented athletes on this squad. You never really know what you're going to get when you step on the deck for the first time. But after practicing with them for the past four months I have total faith in these gals. They know what they're doing.
Q: You've been coaching men pretty much exclusively for the last 10 years. Are there any differences in your approach to coaching collegiate women?
KREUTZKAMP: Not really. It's all in the communication. The skills we practice, game plans, intensity are all the same. They deserve nothing less.
Q: Tell us what we can expect to see out of a Brad Kreutzkamp-coached team in the pool?
KREUTZKAMP: Well, you can count on a team that is disciplined, plays solid defense and understands their individual roles. They'll be prepared for every opponent and hopefully be having some fun along the way.
Q: How heavily will this team rely on its seniors?
KREUTZKAMP: I can tell that I have relied on them a great deal. I needed them to know that this was their team, not mine. They have given so much to UCSD these past three or four years that they have earned that. In the pool, they will be the nucleus we build around. That being said, we have some very talented underclassmen as well.
Q: What were your thoughts when you saw that San Diego State, Michigan, San Jose State and UCLA-top 10 teams all last year-would be your four opponents in the season-opening Michigan Tournament?
KREUTZKAMP: At first I was a little deflated knowing how good those opponents are, but after it settled a bit and I announced it to the team we just went back to work. I mean, the little number next to your team ranking really means nothing once the game starts. This is a UCSD team that will build to playing its best ball once our conference championship gets here, and these opponents will just help us get to that point.
Q: You've been quoted as saying your team could challenge for the WWPA Championship this year. Was that said in the excitement of the moment or do you think it's truly a possibility?
KREUTZKAMP: I hate to lose more than anybody I know. I think there is something defective in my genes or something. So once I got the job I definitely was setting some goals not knowing what our talent level really was. However, after coaching this squad these past few months I now believe it more than ever. We have the talent in the cage, on defense, and some real threats on offense. We just have to believe in ourselves.
Q: You have spent 11 years coaching with Denny Harper. What do you consider the most valuable coaching insights you've learned from him?
KREUTZKAMP: I have learned so much it's tough to narrow it down to the "most valuable". With that being said, Denny's ability to bring a team together and believe in themselves is uncanny. UCSD beats D-I teams every year and to battle the resources and admission standards that they have, you have to get a team to believe in itself. You see it all the time in March Madness. Some team no one ever gave a chance steps up and has a great run because of their attitudes. Denny nurtures that characteristic better than anyone I've ever met.
Q: With his office literally across the pool, will you try to utilize his experience with your program? If so, how?
KREUTZKAMP: I'd be a fool not to. So much so, in fact, that he has assumed an assistant coaching role with us. It's a lot like when we were together these past 11 years. We would sit around for hours bouncing ideas off each other. We don't always see eye-to-eye, but how can you argue with the success that he's had in his nearly three decades of coaching at UCSD?
Q: In an earlier era, the UCSD women's water polo team won five national titles. As a new head coach, is that history intimidating?
KREUTZKAMP: Not intimidating at all. It's motivating. With all the talented players to have passed though here the current team feels a sense of history and hopefully uses that to drive themselves when things get tough.
Q: What are your goals in the recruiting arena?
KREUTZKAMP: We are really focusing on getting student athletes from winning high schools and junior colleges. When you have athletes who know what it takes to win a championship, you have won half the battle. Winning attitudes are everything. Oh yeah...big, fast athletes never hurt either.
Q: What are the three most important qualities your ideal recruit should possess?
KREUTZKAMP: Attitude, strength, and speed.
Q: You've spent a good part of your career at UCSD. What are some tips you've picked up from your non-water polo colleagues?
KREUTZKAMP: My office for the past seven years was up at RIMAC and I worked side-by-side with most of UCSD's coaching staff. I can say unequivocally that this is an amazing staff. I remember sitting down with one of the most successful women's coaches in San Diego history, Brian McManus [women's soccer], and asking him how he would coach his women differently than some his men's club teams. He looked me right in the eye with all seriousness and said that he coaches them no different. "They deserve nothing less." I'm going to keep that with me for a long time.
Q: You're a big sports fan. What sports and what teams do you follow and why?
KREUTZKAMP: I'm all about San Diego. I've lived here for over 20 years now and I'm a huge Charger and Padre fan. Sometimes I have to ask myself why I torture myself so much. But in all seriousness, it's a great release from coaching to just go and watch sports for pleasure as opposed to having a vested interest in your own team.
Q: You and your wife Victoria have two young sons, Jake and Ryan. When you want to get completely away from the coaching world, what do you enjoy doing with your family?
KREUTZKAMP: We go to Big Bear a lot. We are fortunate to have a family cabin up there and I've been going there since I was nine. It's really neat to see my young boys enjoying the mountain as I have for so long.
Q: In five years, where do you see the UCSD women's water polo team? What would you consider success within that time frame?
KREUTZKAMP: Our stated goal is to win our conference every year. If that takes one year, great. If it takes five, we'll do it that way too, but it will happen. It can sometimes come across as a cop out when teams don't win to say that as long as everyone tried their best then we're all winners. But in all the years of coaching the UCSD student-athletes, I have become a huge believer in what this university is all about. The young men and women that go through this athletic department are some of the most well-rounded, successful young people you will ever meet. I'm fortunate to be working with them.
Previous Q & A Articles
Tyler Acevedo (Men's Basketball) January 4, 2010
Dr. Cliff Kubiak (UCSD's Faculty Athletic Rep) December 18, 2009
Chelsea Carlisle (Women's Basketball) December 9, 2009
Carianne Cunningham (Women's Swimming) November 23, 2009
Elena Inouye (Cross Country) November 6, 2009
David Morton (Men's Water Polo) October 28, 2009
Juan Pablo Carillo (Men's Swimming) October 19, 2009
Sara Spaventa (Women's Soccer) October 10, 2009
Karen Reis (Women's Volleyball) October 2, 2009
Daniel Pavitt (Men's Soccer) September 23, 2009
Daniel Anderson (Cross Country) September 11, 2009
Peter Gresham (Men's Water Polo) September 2, 2009
Alexia Zatarain (Women's Soccer) August 24, 2009
Elaine Chen (Women's Volleyball) August 12, 2009
Jared Kukura (Men's Soccer) July 30, 2009
Dawn Lee (Former Women's Soccer Standout) July 8, 2009
Rob Mamula (Director of Athletic Performance) June 18, 2009
Garrett Imeson (Baseball) June 8, 2009
Leon Baham (Men's Track & Field) May 21, 2009
Kristyn Lesovsky (Softball) May 8, 2009
Kazumi Negishi (Men's Tennis) May 5, 2009
Laiah Blue (Women's Track & Field) April 16, 2009
Ryan Andre (Men's Crew) April 2, 2009
Josh Tanner (Baseball) March 24, 2009
Anju Shimura (Women's Swimming) March 7, 2009
Stephanie Bocian (Women's Water Polo) February 20, 2009
Lauren Chastain (Softball) February 5, 2009
A.J. Maulhardt (Men's Basketball) January 28, 2009
Annette Ilg (Women's Basketball) January 22, 2009
Steven Hardy (Men's Swimming) January 13, 2009
Frank Fritsch (Men's Volleyball) January 5, 2009
Kendall Bohn (Women's Swimming) December 22, 2008
Kelvin Kim (Men's Basketball) December 15, 2008
Michelle Osier (Women's Basketball) December 5, 2008
Sylvia Schmidt (Women's Volleyball) November 7, 2008
Denny Harper (Men's Water Polo Head Coach) October 17, 2008
Ron Larsen (USA Volleyball Assistant Coach) October 13, 2008
Jessica McGovern (Women's Soccer) October 6, 2008
Bre Schofield (Cross Country) September 26, 2008
Tony Fernandez (Men's Soccer) September 18,2008
Kimberly Carpenter (Women's Volleyball) September 12, 2008
A.J. Kotanjian (Men's Water Polo) September 2, 2008
Peter Akman (Men's Soccer) August 21, 2008
Natasha Belak-Berger (Women's Soccer) August 15, 2008
Jake LaVieux (Men's Cross Country) August 8, 2008
Dr. Penny Rue (Vice Chancellor of Student Affairs) July 30, 2008
Michelle Torres (Women's Volleyball) July 15, 2008
Jon Pascale (Men's Soccer Head Coach) July 1, 2008
Julie Ertel (Athletics) June 16, 2008
Clint Allard (Men's Basketball) June 9, 2008
Jen Myers (Women's Crew) May 27, 2008
Casey Ryan (Men's Track and Field and Men's Basketball) May 21, 2008


text:
White light.
The home is slowly coming together. We picked up sheer shades for the room with our kitchen table.
I love the diffused white light through it.
I sit enveloped in a quiet space.
I write. I make lists.
Savoring the few moments before I set out to translate the words into actions.
We celebrated our first Halloween.
Strangers offered warm smiles and hot cider.
I delighted in the act of giving handful of candies.
The twinkling lights are coming home soon.
Our first Diwali in a new land.


text:
Organizers of new social networking site The Tea Party Community have taken Facebook, eliminated the supposed liberal bullying, tossed in tens of thousands of conservatives and mixed it all together with a dash of conspiracy theory to create a new online hub, set to launch officially on Saturday.
The Tea Party Community co-founder Ken Crow tells Fox News, he wants to make it the Facebook alternative for conservatives and the Tea Party movement.
So far, it has drawn upward of 50,000 members, attracted to what Crow calls a "safe haven for the conservative movement where we can share ideas and thoughts and express ourselves without fear of retribution."
Crow claims that he and other conservatives have been targeted by Facebook and its liberal users simply for attempting to express their political point of view.
"Most of us are subjected to censorship on Facebook," Crow told Fox News. "I've been suspended there as have many of my friends. You also absorb a lot of abuse from liberals."
While there have been high-profile examples of Facebook removing or threatening to remove conservative-leaning content, Facebook claims to not be involved in any intentional censorship of content.
Some Tea Party activists might be all too familiar with the content Facebook allows.
In Virginia, the Mecklenburg Tea Party drew statewide backlash last year when it refused to remove a series of Facebook photos depicting President Barack Obama as a witch doctor, neanderthal and thug. In that case, the pressure came from the Virginia GOP, not Facebook.
And in 2011, a failed Tea Party candidate unleashed a racial epithet-laden Facebook post that called for the assassination of Obama and his family. The poster later took down the message under his own accord and replaced it with an apology.
As for The Tea Party Community, the website could draw some scrutiny from a design perspective. The basic page layout looks remarkably similar to Facebook's, with a little more in-your-face patriotism sprinkled around the frills.
Read more from Fox News here, or click over to The Tea Party Community and have a look for yourself.


text:
Privacy Policy
This privacy statement provides information about the personal information that Sol Alliance collects, and the ways in which Sol Alliance uses that personal information.
Personal information collection
Sol Alliance may collect and use the following kinds of personal information: [any other information that you send to Sol Alliance.]
Using personal information
Sol Alliance may use your personal information to: [enable your access to and use of the website services.]
Where Sol Alliance discloses your personal information to its agents or sub-contractors for these purposes, the agent or sub-contractor in question will be obligated to use that personal information in accordance with the terms of this privacy statement.
In addition to the disclosures reasonably necessary for the purposes identified elsewhere above, Sol Alliance may disclose your personal information to the extent that it is required to do so by law, in connection with any legal proceedings or prospective legal proceedings, and in order to establish, exercise or defend its legal rights.
Securing your data
Sol Alliance will take reasonable technical and organizational precautions to prevent the loss, misuse or alteration of your personal information. Sol Alliance will store all the personal information you provide on its secure servers. Information relating to electronic transactions entered into via this website will be protected by encryption technology.
Cross-border data transfers
Information that Sol Alliance collects may be stored and processed in and transferred between any of the countries in which Sol Alliance operates to enable the use of the information in accordance with this privacy policy.
In addition, personal information that you submit for publication on the website will be published on the internet and may be available around the world. You agree to such cross-border transfers of personal information.
Updating this statement
Sol Alliance may update this privacy policy by posting a new version on this website. You should check this page occasionally to ensure you are familiar with any changes.
Other websites
This website may contain links to other websites.
Sol Alliance is not responsible for the privacy policies or practices of any third party.
Contact Sol Alliance
If you have any questions about this privacy policy or Sol Alliance´s treatment of your personal information, please write to: admin [at] solalliance.com


text:
Bold Italian Taste Minus the Jitters
by Julia Mason
Many decaf drinkers miss the taste of "real" coffee. Luckily, these decaf Italian Roast K-Cups from Barista Prima Coffeehouse have a satisfying, full-bodied flavor gratifying enough to fool even the most nostalgic decaf drinker into feeling they're sipping the real McCoy. Made from high-quality Arabica beans, this dark roast has a pleasant aroma and a smoky flavor that's bold without being bitter. Continue reading "Barista Prima Decaf Coffee, Italian Roast K-Cup Review" »


text:
What's New
Don Morris studies tax cheating
University of Illinois Springfield Associate Professor of Accountancy Donald Morris studies tax cheating in the United States. He explores the topic from a moral and policy standpoint in his new book "Tax Cheating: Illegal–But is it Immoral?"
The Association to Advance Collegiate Schools of Business (AACSB) Accreditation
The College of Business and Management at the University of Illinois Springfield is accredited by AACSB International, the premier accrediting agency for collegiate schools of business worldwide. With this achievement, the College of Business and Management joins an elite group that makes up less than ten percent of the world's business schools that have achieved accreditation from AACSB International.