När kärnan kommer förbi sin initieringsfas startar den den allra första processen, init. Process #1 är ensam sällan särskilt användbar, och Unix-liknande system kör med många flera processer.

För det första kan en process klona sig själv (detta är känt som fork). Kärnan allokerar ett nytt (men identiskt) minnesområde för processen, och en ny process som kan använda den. Vid denna tidpunkt är den enda skillnaden mellan dessa två processer deras pid. Den nya processen kallas vanligen en barnprocess, och originalprocessen vars pid inte ändras, kallas för föräldraprocessen.

Ibland fortsätter barnprocessen att leva sitt eget liv, oberoende från sin förälder, med sin egen data kopierad från föräldraprocessen. I många fall exekverar dock denna barnprocess ett annat program. Med ett fåtal undantag ersätts dess minne helt enkelt med det för det nya programmet och exekvering av detta nya program påbörjas. Detta är mekanismen som används av initprocessen (med processnummer 1) för att starta ytterligare tjänster och exekvera hela uppstartssekvensen. Vid en tidpunkt kommer en process bland inits barn att starta ett grafiskt gränssnitt genom vilket användare kan logga in (den faktiska sekvensen av händelser beskrivs i ytterligare detalj i Avsnitt 9.1, ”Systemstart”).

När en process avslutar uppgiften som var anledningen till att den startades så avslutas den. Kärnan återhämtar sedan minne som tilldelats till denna process och slutar ge den körtidsintervall. Föräldraprocessen informeras om att dess barnprocess avslutats, vilket låter en process vänta på att en uppgift som delegerats till en barnprocess slutförts. Detta beteende syns tydligt i kommandotolkar (kända som skal). När ett kommando matas in i ett skal, handlar det helt enkelt om att lägga till ett & på slutet av kommandot. Prompten visas igen inom kort vilket kan leda till problem om kommandot själv behöver skriva ut data.

En ”demon” är en process som startats automatiskt av uppstartssekvensen. Den fortsätter köra (i bakgrunden) för att utföra underhållsuppgifter eller tillhandahålla tjänster till andra processer. Denna ”bakgrundsuppgift” är faktiskt slumpmässig och matchar inte någon särskild typ ur systemets synvinkel. De är helt enkelt processer, liknande andra processer, som kör i turordning när deras tidsintervall kommer. Skillnaden är endast i hur man talar om den: en process som kör utan interaktion med en användare (i synnerhet utan ett grafiskt gränssnitt) kallas för att den kör ”i bakgrunden” eller ”som en demon”.

Flera sådana demoner beskrivs i detalj i Kapitel 9, Unixtjänster.

En isolerad process, vare sig det är en demon eller ett interaktivt program, är sällan användbar på egen hand, vilket är anledning till att det finns flera sätt att låta separata processer kommunicera med varandra, antingen för att utbyta data eller för att styra varandra. Den generella termen för att referera till detta är interprocesskommunikation, eller IPC (efter engelskans Inter-Process Communication).

Det enklaste IPC-systemet är ett använda filer. Processen som önskar skicka data skriver denna till en fil (med ett förutbestämt namn), medan mottagaren endast behöver öppna filen och läsa dess innehåll.

I fallet där du inte önskar spara data på disk kan du använda en rörledning, vilket helt enkelt är ett objekt med två ändar; byte skrivs i en ände och kan läsas i den andra. Om ändarna styrs av olika processer leder detta till en enkel och behändig kanal för interprocesskommunikation. Rörledningar kan klassificeras i två kategorier: namngivna rörledningar och anonyma rörledningar. En namngiven rörledning representeras av en post i filsystemet (även om den överförda datan inte lagras där), så att båda processerna kan öppna den oberoende av varandra så länge platsen för den namngivna rörledningen är förutbestämd. I fall när kommunicerande processer är relaterade (till exempel en föräldraprocess och dess barnprocess) kan föräldraprocessen också skapa en anonym rörledning innan forkning, och därför kommer barnet att ärva den. Båda processerna kommer sedan kunna utbyta data via rörledningen utan att behöva involvera filsystemet.

Inte all interprocesskommunikation används för att flytta runt data, dock. I många situationer är den enda information som måste överföras kontrollmeddelanden så som ”pausa körning”, eller ”återuppta körning”. Unix (och Linux) tillhandahåller en mekanism känd som signaler genom vilka en process enkelt kan skicka en specifik signal (vald från en fördefinierad lista av signaler) till en annan process. Det enda kravet är att veta målets pid.

För mer komplex kommunikation finns det också mekanismer för att låta en process göra tillgängligt, eller dela, en del av sitt allokerade minne till andra processer. Minne som nu delas mellan dem kan användas för att flytta data mellan processerna.

Avslutningsvis kan nätverksanslutningar också hjälpa processer att kommunicera; dessa processer kan till och med köras på olika datorer, tusentals kilometer från varandra.

Det är ganska vanligt för ett typiskt Unix-liknande system att använda alla dessa mekanismer i olika utsträckning.

Funktionsbibliotek spelar en väsentlig roll i ett Unix-liknande operativsystem. Det är inte egentliga program, då de inte kan köras för sig, utan är samlingar av kodfragment som kan användas av standardprogram. Bland de vanliga biblioteken hittar du:

Tack vare dessa bibliotek, kan program återanvända kod. Programutveckling förenklas då många program kan återanvända samma funktioner. Med bibliotek som utvecklats av olika personer tas den globala utvecklingen av systemet närmre Unix historiska filosofi.

Därutöver refereras dessa bibliotek ofta till som ”delade bibliotek” då kärnan kan läsa in dem i minne endast en gång även om flera processer använder samma bibliotek samtidigt. Detta möjliggör sparande av minne, när det jämförs med den motsatta (hypotetiska) situationen där koden för ett bibliotek måste läsas in lika många gånger som det finns processor som använder det.