Når kjernen passerer sin oppstartperiode, så starter den opp den aller første prosessen, init. Prosess #1 er svært sjelden nyttig på egen hånd, og Unix-lignende systemer kjører med mange prosesser i tillegg.

Først av alt kan en prosess klone seg selv (dette er kjent som en forgrening/fork). Kjernen tildeler et nytt (men identisk) prosessminne, og en annen prosess for å bruke det. På denne tiden er den eneste forskjellen mellom disse to prosessene deres pid. Den nye prosessen kalles vanligvis en barneprosess, og den opprinnelige prosessen, hvis pid ikke forandres, kalles foreldreprosessen.

Noen ganger fortsetter barneprosessen å leve sitt eget liv uavhengig av foreldreprosessen, med sine egne data kopiert fra den overordnede prosessen. I mange tilfeller kjører denne barneprosessen et annet program. Med noen få unntak, er minnet dens bare erstattet av det nye programmet, og gjennomføringen av dette nye programmet starter. Dette er mekanismen som brukes av init-prosessen (med prosess nummer 1) for å starte tilleggstjenester og gjennomføre hele oppstartssekvensen. På et tidspunkt starter en prosess blant inits avkom et grafisk grensesnitt som brukerne kan logge seg på (det faktiske hendelsesforløpet er beskrevet mer i detalj i Seksjon 9.1, «Systemoppstart»).

Når en prosessen har fullført oppgaven den ble startet for å utføre, så avslutter den. Kjernen tar deretter tilbake minnet som er tilordnet denne prosessen, og slutter å dele ut tidsressurser den kan bruke til å kjøre. Foreldreprosessen blir fortalt at barneprosessen er avsluttet, noe som tillater en prosess å vente på fullføringen av en oppgave den delegerte til en barneprosess. Denne oppførselen vises tydelig i kommandolinjetolker (kjent som skall). Når en kommando er skrevet inn i et skall, kommer ledeteksten først tilbake når kommandoen er ferdig utført. De fleste skall lar en kjøre en kommando i bakgrunnen, som er bare å legge til & på slutten av kommandoen. Ledeteksten vises igjen med en gang, noe som kan føre til problemer hvis kommandoen må skrive ut sitt eget resultat.

En «bakgrunnsprosess» er en prosess som startet automatisk ved oppstartssekvensen. Den fortsetter å kjøre (i bakgrunnen) for å utføre vedlikeholdsoppgaver, eller yte tjenester til andre prosesser. Denne «bakgrunnsoppgaven» er faktisk tilfeldig, og samsvarer ikke med noe bestemt fra systemets synspunkt. De er bare prosesser, ganske lik andre prosesser, som går igjen når deres tidskvote kommer. Forskjellen er bare i menneskelig språk: En prosess som går uten interaksjon med brukeren (særlig uten grafisk grensesnitt) sies å være kjørt «i bakgrunnen», eller «som en bakgrunnsprosess».

Forskjellige slike bakgrunnsprosesser er beskrevet i detalj i Kapittel 9, Unix-tjenester.

En isolert prosess, enten en bakgrunnsprosess eller et interaktivt program, er sjelden nyttig i seg selv, noe som er grunnen til at det er flere metoder som lar separate prosesser kommunisere sammen, enten for å utveksle data, eller for å kontrollere hverandre. Det generiske begrepet for dette er inter-process communication, eller i kortform IPC.

Det enkleste IPC-systemet er å bruke filer. Prosessen som ønsker å sende data, skriver den inn i en fil (med et navn kjent på forhånd), mens mottakeren bare har å åpne filen, og lese innholdet.

I tilfeller der du ikke ønsker å lagre data på disken, kan du bruke en kanal som rett og slett er et objekt med to ender; byte skrevet i den ene enden er lesbar i den andre. Dersom endene er styrt med separate prosesser, fører dette til en enkel og praktisk kommunikasjon mellom prosesser. Kanaler kan deles inn i to kategorier: Navngitte kanaler, og anonyme kanaler. En navngitt kanal er representert ved en oppføring i filsystemet (selv om de overførte data ikke er lagret der), slik at begge prosessene kan åpne det uavhengig om plasseringen av den navngitte kanalen er kjent på forhånd. I tilfeller hvor de kommuniserende prosessene er relatert (for eksempel en foreldre- og dens barneprosess), den overordnede prosessen kan også opprette en anonym kanal før forgreninger, og barnet arver det. Begge prosesser vil da være i stand til å utveksle data gjennom kanalen uten filsystemet.

Ikke all inter-prosesskommunikasjon brukes til å flytte data rundt. I mange situasjoner er den eneste informasjonen som må overføres, kontrollmeldinger som «pause kjøring» eller «gjenoppta kjøring». Unix (og Linux) tilbyr en mekanisme som kalles signaler, som lar en prosess sende et bestemt signal (valgt fra en forhåndsdefinert liste av signaler) til en annen prosess. Det eneste kravet er å kjenne til mottakerens pid.

For mer komplekse kommunikasjoner er det også mekanismer som tillater at en prosess åpner tilgang, eller deler, en del av sitt tildelte minne til andre prosesser. Minnet, som nå er delt mellom dem, kan brukes til å flytte data mellom prosessene.

Endelig, nettverkstilkoblinger kan også hjelpe prosesser å kommunisere; disse prosessene kan også kjøres på forskjellige datamaskiner, muligens tusenvis av kilometer fra hverandre.

Det er ganske standard for et typisk Unix-lignende system i ulik grad å gjøre bruk av alle disse mekanismene.

Funksjonsbibliotekene spiller en avgjørende rolle i et Unix-lignende operativsystem. De er ikke egentlig programmer, da de ikke kan kjøres på egen hånd, men er samlinger av kodefragmenter som kan brukes av standardprogrammer. Blant de vanligste biblioteker, kan du finne:

Takket være disse bibliotekene kan programmer gjenbruke eksisterende kode. Programutvikling forenkles fordi mange programmer kan bruke de samme funksjonene. Med bibliotekene, ofte utviklet av forskjellige personer, så er den globale utviklingen av systemet nærmere Unixs historiske filosofi.

Dessuten er disse bibliotekene ofte referert til som «felles biblioteker», ettersom kjernen bare er i stand til å laste dem inn i minnet én gang, selv om flere prosesser benytter samme bibliotek samtidig. Dette tillater å spare lagringsminne, sammenlignet med den motsatte (hypotetisk) situasjonen, hvor koden for et bibliotek ville være lastet like mange ganger som det er prosesser som benytter den.