Linux /usr-directory: het neveneffect van een hardwarefout 50 jaar geleden

Is de Linux /usr-directory niet een afkorting voor User?

Een neveneffect van een hardwarefout 50 jaar geleden

Als je Linux of Unix gebruikt, heb je misschien ooit deze vraag gesteld.

"Wat is /usr eigenlijk een afkorting voor?"

Op het eerste gezicht lijkt het alsof het simpelweg "User" minus de letter "e" is. Maar als dat zo was, waarom gebruiken we dan niet gewoon "/user"? Waarom is het "/usr"?

• Moeite met typen?
• Was er een limiet aan het aantal tekens?
• Maar directories zoals "/boot", "/home", "/proc" bestaan nog steeds, elk met vier letters.

Als het echt "user" was, had het waarschijnlijk "/user" genoemd. Het feit dat we het "/usr" noemen, verbergt een stukje geschiedenis dat we niet kennen.

Vandaag gaan we die geschiedenis ontrafelen en een 50 jaar oude, maar toch grappige hardwareverhaal vertellen dat elke ontwikkelaar zal laten zeggen: "Ah, dat had ik niet verwacht."

1. Conclusie: de huidige /usr is geen "User"

In de huidige Linux Filesystem Hierarchy Standard (FHS) wordt /usr als volgt gedefinieerd.

Een gebied voor (meestal) alleen-lezen programma's, bibliotheken en gedeelde data die op het hele systeem worden gebruikt.

Daarom ziet de structuur er zo uit.

• /usr/bin – de meeste gebruikersprogramma's
• /usr/sbin – systeembeheerprogramma's
• /usr/lib* – de bibliotheken die die programma's gebruiken
• /usr/share – handleidingen, pictogrammen, locale‑bestanden, etc.

Het is duidelijk ver verwijderd van persoonlijke bestanden. Alle persoonlijke bestanden, documenten, foto's, etc. bevinden zich onder /home.

Dus, in één zin:

/usr = "Geen User, maar een gedeelde opslagplaats voor OS‑ en applicatie‑resources"

Maar er blijft een vraag over.

"Was /usr oorspronkelijk toch een afkorting voor user?"

Hier begint het interessante deel. Het begon als een afkorting voor User. Maar de betekenis is in de afgelopen 50 jaar volledig omgekeerd.

2. De vroege Unix: /usr/gebruikersnaam was het home‑directory

Laten we teruggaan naar het begin van de jaren 70.

Op die tijd was het home‑directory van een gebruiker niet "/home/anna" maar

• /usr/anna – het stond direct onder /usr.

Dus in die tijd was /usr echt een directory voor "user‑gerelateerde" dingen.

De computers waren dan PDP‑11‑machines en de schijven waren ongelooflijk klein.

• Root‑schijf (/) – een kleine ruimte voor de kernbestanden van het OS
• Tweede schijf (/usr) – een ruimere ruimte, waar de home‑directories werden geplaatst

Deze structuur maakte logisch gezien veel zin. Het probleem? Unix (en de ontwikkelaars) groeide te snel.

3. "Schijf vol" → systeembestanden naar /usr verplaatsen

Unix bleef groeien, nieuwe commando’s en functies werden toegevoegd. Het probleem was dat de root‑schijf (/) niet groter werd.

Op een dag kwam de situatie:

"Er is geen plek meer op / voor programma’s…"

De ontwikkelaars namen een praktische beslissing.

"De tweede schijf (/usr) is ruim genoeg, laten we de niet‑essentiële programma’s daarheen verplaatsen."

Zo begonnen de programma’s, bibliotheken en data die ooit in /usr stonden als "user‑home" langzaam naar binnen te dringen.

Het resultaat is de structuur die we nu kennen.

• /bin – de minimale set commando’s die nodig zijn om op te starten (oorspronkelijk op de root‑schijf)
• /usr/bin – de overige algemene commando’s (verplaatst naar de tweede schijf)
• /lib vs /usr/lib – dezelfde logica

Kortom:

"Oorspronkelijk een gebruikershuis, maar door schijfruimte‑tekort is het nu een systeem‑huis."

Een echte "harde schijf‑tekort‑truc".

Later bleef Unix groeien.

• De home‑directories verplaatsten naar een meer intuïtieve directory zoals /home.
• /usr werd een volledig gedeelde programmeer‑ en bibliotheek‑ruimte.

Het is nu een beetje grappig.

• Naam: usr (user)
• Inhoud: systeem‑ en applicatie‑bestanden

De eigenaar is verhuisd, maar het huis is nu alleen vol met systeem‑bestanden.

4. "Unix System Resources"? Dat is een later verzonnen afkorting

Deze tegenstrijdige situatie bleef bestaan, waardoor iemand later zei:

"Laten we zeggen dat /usr een afkorting is voor Unix System Resources."

Je hebt misschien documenten gezien die schrijven: "/usr = Unix System Resources". Maar er is één belangrijk punt.

Dit is een backronym – een afkorting die later is verzonnen, niet de oorspronkelijke betekenis.

In de oorspronkelijke Unix‑documentatie en getuigenissen:

• /usr was oorspronkelijk een afkorting voor "user"
• Het was bedoeld voor home‑directories
• Door schijfruimte‑problemen werd het uitgebreid tot "user‑gerelateerde programma’s" → "alle programma’s en bibliotheken"

Met de tijd hebben mensen de realiteit samengevat als:

"Nu is het een plek voor systeem‑resources, dus laten we het Unix System Resources noemen."

Dit wordt een backronym genoemd.

In de ontwikkelaarswereld zie je dit vaak.

• Een tijdelijke naam/structuur
• Wordt gedocumenteerd
• Wordt een standaard
• En later wordt het uitgelegd alsof het oorspronkelijk zo bedoeld was.

5. De structuur van 50 jaar geleden tot nu: de Usr Merge

Na het horen van dit verhaal kun je denken:

"Als de schijven nu ruim zijn, waarom hebben we nog steeds aparte /bin en /usr/bin?"

Moderne Linux‑distributies (Ubuntu, Fedora, Debian, etc.) werken aan het opruimen van dit historische erfgoed. Dit proces heet /usr merge (UsrMerge).

Probeer het volgende op een moderne distro:

$ ls -l /
lrwxrwxrwx 1 root root    7  ...  bin  -> usr/bin
lrwxrwxrwx 1 root root    7  ...  sbin -> usr/sbin
lrwxrwxrwx 1 root root    7  ...  lib  -> usr/lib

Meestal zie je dit.

• /bin is geen echte directory, maar een symlink naar /usr/bin
• Hetzelfde geldt voor /sbin en /lib

De huidige structuur is dus:

"De meeste programma’s en bibliotheken bevinden zich onder /usr."

Waarom samenvoegen? Er zijn verschillende redenen, maar de belangrijkste zijn:

• Vereenvoudigen van pakketbeheer en porting
• In container‑/image‑gebaseerde distributies is het gemakkelijker om /usr als één "systeem‑image" te behandelen
• Er is geen reden meer om de oude scheiding te behouden vanwege hardware‑beperkingen

Het interessante is dat alles teruggaat naar:

"In de jaren 70, door schijfruimte‑tekort, werden programma’s naar /usr verplaatst."

Een perfect voorbeeld van "een tijdelijke oplossing is nooit permanent".

6. Hoe moeten we /usr vandaag begrijpen?

Bij het werken met een Linux‑systeem kun je /usr als volgt zien.

"Een gebied voor gedeelde programma’s, bibliotheken en data die door het hele systeem worden gebruikt."

Teruggekeerd:

• Persoonlijke bestanden / instellingen → /home/jeaccount
• Veelvoorkomende data (logboeken, cache, DB, etc.) → /var
• Niet‑pakket‑geïnstalleerde apps → meestal onder /opt of /usr/local (Ask Ubuntu)

Kortom:

• /usr = OS‑ en applicatie‑wereld
• /home = persoonlijke wereld

Dit maakt het minder verwarrend.

Conclusie: een directorynaam vol ontwikkelaars‑compromis

De /usr‑directory bevat:

• De praktische zorgen van de vroege Unix‑ontwikkelaars die schijfruimte‑tekort moesten overwinnen
• Een "later op te ruimen" oplossing die uiteindelijk een standaard werd
• En de moderne standaardisatie‑ en opruiming‑werkzaamheden (UsrMerge)

In plaats van simpelweg te onthouden:

• "/usr = Unix System Resources"
• "/usr is geen gebruikersdirectory"

Het is nuttiger om de achtergrond te kennen. Dan zie je in de terminal:

"Ah, dat is het resultaat van een 50‑jaar oude schijfruimte‑tekort‑oplossing."

Een directory op een zwart scherm, maar met een rijke geschiedenis van hardware‑beperkingen en ontwikkelaars‑compromis. Dat is best interessant, nietwaar?"

Referenties