Det var store nyheter når 3.0 kernel ble sluppet i slutten av juli, men som flaks ville ha det, er i ferd med å støte sin egen versjon nummer opp en annen grunnleggende del av den gjennomsnittlige fordelingen til 3,0 i tillegg: standard filsystem hierarkiet (FHS). Hvis du ikke er sikker på nøyaktig hva det betyr, eller hvorfor du bør bry seg, ikke bekymre deg. Det er de distroer som implementerer FHS – når det går bra, er alt du vet at systemet går greit. Men det betyr ikke at det ikke er noe viktig gjemt bort i denne nye utgivelsen

Hva som nå

FHS definerer den grunnleggende strukturen i en Unix-lignende operativsystem &ndash.?; hva katalogene er, hva slags filer og data hører hjemme i hver, og så videre. Dette er viktig for programutviklere (slik at de vet å lage midlertidige filer i /tmp /snarere enn i brukerens hjemmekatalog, for eksempel), men det er også viktig for systemadministratorer. Ikke bare FHS spesifisere hvor
katalogene går, men det angir viktige egenskaper som hvilke kataloger må monteres beskyttet (kritisk for sikkerhet) og som må være tilgjengelig ved oppstart (slik at vitale kataloger er på lokale disker ikke NFS monteringer som ikke vil være tilgjengelig tidlig i oppstartssekvensen).

Denne type informasjon er spesielt viktig for systemer som Linux som ikke har en eneste bedrifts eier. IBM og Sun kunne diktere AIX og Solaris layout uten å konsultere noen. Red Hat, SUSE, og Debian, på den annen side må komme til en enighet om filsystem layout eller avtale med " fragmentering " klager. Selvfølgelig kan den faktiske administrator av hvilken som helst maskin konfigurere Linux-systemet ad nauseum. For eksempel, hvis du ønsker å lagre alle dine loggfiler i /boot, hjemmekatalogen i /etc, fjerne /bin /sh, og mount /usr /lib fra en iSCSI-stasjonen, ingen vil stoppe deg (du vil bare må migrere konfigurasjonen selv). FHS bare angir hvordan du kan få et fungerende system oppe og går ut av boksen

FHS faktisk vokste ut av den gamle ". BSD " hierarki av forhistoriske Unix dager, selv om de moderne * rcng (FreeBSD, OpenBSD, NetBSD) har skilt siden da. FHS har senere blitt en Linux-fokusert standard som flere og flere proprietære Unix-leverandørene migrere til Linux fra sine historiske produktlinjer, og det er en del av Linux Standards Base (LSB). Men den siste oppdateringen til FHS – versjon 2.3 – ble utgitt i 2004, som er gamle i databehandling vilkår.

Tilbake i mai 2011, og Linux Foundation (som vedlikeholder LSB) bestemte seg for å prøve og re-starte FHS prosessen, invitere deltakelse fra hele Unix -lignende landskapet, og produsere en lang forfallen oppdatering. Det arbeides nå nærmer seg ferdigstillelse. FHS 3.0 vil være en inkrementell oppdatering, noe som reflekterer nye praksiser og gjøre plass til de måtene som databehandling har endret seg i de foregående syv årene, snarere enn å innføre radikale nye konsepter.

Hva er nytt i 3.0

Den største endringen i FHS 3.0 er trolig tillegg av en ny toppkatalog, /kjøre. Den /løpe katalogen hovedsak flytter /var /run (som brukes til å holde kjøre-time data som vises først etter oppstart, slik som prosess ID (PID) filer) opp ett nivå, og konsoliderer noen annen dynamisk generert, ikke- vedvarende miscellany – inkludert /var /lock lock-filer, /dev /shm midlertidig lagring og udev tilstand.

Målet er for /kjøre for å holde alle system-state data som ikke er meningsfull hvis vedvart fra en omstart til en annen . /Var katalogen der den ligger i FHS 2.x er spesifisert som for " variabel " -innholdet filer, men for det meste det er brukt av standardapplikasjoner – for logger, e-spoler, cacher, og så videre. Det betyr at det er ofte lagret på en egen partisjon, og kan monteres relativt sent i oppstartsrekkefølgen. Den /løpe katalogen inneholder kjernesysteminformasjon, og ved å være en egen toppkatalog, kan den plasseres på rotpartisjonen å sikre tilgjengelighet så snart init prosessen trenger det. Den /løpe katalogen kan også brukes for per bruker statlige data (for eksempel økt informasjon), men det er en pågående diskusjon om nøyaktig hvordan dette alternativet vil bli formulert.

Games er også å få det en gang-over . Tradisjonelt spill ble behandlet annerledes enn andre brukerprogrammer, med sine egne /usr /spill og /var /spill underkataloger. Det ble gjort for det meste historiske grunner – størrelsen på spillet data var stor i forhold til annet innhold, og på grunn av sin ikke-essensielle natur, ikke verdt sikkerhetskopiering på relativt trege og dyre kassetter. Men det samme kan
argumenteres for underholdning og andre ikke-essensielle tjenester, og backup lagring har utviklet seg betydelig de siste årene. Den nye planen er for spill å bruke /usr /bin for binærfiler, /usr /share for spillinnhold, og /var /lib for " høy score " data og andre småting som potensielt trenger å være tilgjengelig med flere brukerkontoer

Speaking of konsistens, SELinux har også bodd i et ikke-standard sted i FHS 2.x era. i topp-nivå /SELinux katalogen. Dette endrer også i 3.0, flytting til /sys /fs /SELinux. Referanser til den gamle X11R6 – funnet i /usr /X11R6 og andre forbeholdt steder – har blitt frarådet på forespørsel fra X.org, som er nær økes den tapte stående protokoll versjonsnummer. Eldre referanser til xfree86 har også blitt skåret ut, og til slutt " xorg " kan ta sitt navn helt. Det kan være vanskelig å tro i 2011, men et tiår siden var det kommersielle X-servere som konkurrerte sterkt med referanse XFree86 utgivelser for admin virksomhet. Ingen har mye innflytelse lenger.

Det er nok av andre mindre opprydding i utkastet til spesifikasjonen, inkludert erstatte referanser til Bourne skall (sh) og Bash å godta noen POSIX-kompatible skall i stedet, avklaringer på hvordan uavhengig programvare leverandører kan bruke /opt, og lagringsplasser for man-sider og ICC fargeprofiler.

Hva er ikke nytt i 3.0 (eller i det minste ikke ennå)

Det betyr ikke at alt er satt i stein for 3.0 ennå, men. Pågående diskusjoner blant annet å avklare bruken av /srv katalogen, og viktige spørsmål om hvordan FHS angår noen andre spesifikasjoner, for eksempel XDG katalog specs. Du kan lese gjennom FHS diskusjon listearkivet til å følge individuelle ideer, men en raskere oversikt over prosessen er tilgjengelig ved å se på FHS 3,0 " roll-up " bug og dens avhengigheter. Merk at ikke alle problemer er oppført i avhengighetene vil ende opp med å bli adressert i denne utgaven.

Til tross for den konservative endring-set planlagt for inkludering i 3.0, er prosessen med å diskutere de foreslåtte endringene interessant på egen hånd, delvis fordi det avslører hva bekymringer er på administratorer "og distributører sinn, og som kan dukke opp i fremtidige revisjoner.

For eksempel, det er en pågående debatt om hvordan vi skal håndtere gi binærfiler for flere prosessorarkitekturer på ett enkelt system . I øyeblikket, betyr dette vanligvis bare støtte IA-32 (32-biters x86) binærfiler og IA-64 (64-bit amd64) binærfiler på en maskin, men den konvensjonelle tilnærmingen har sine mangler. For en, forviser det 64-bits biblioteker til et bestemt /lib64 sted mens IA-32 slapper inn /lib – Selv om IA-64 er de aller fleste av bibliotekene kjøres. For en annen, er det en kunstig grense, støtter bare to arkitekturer, og som alltid irriterer standarder komiteer. Debian har utarbeidet sin egen tilnærming til problemet som Debian Multiarch, som håndterer 32/64-bits arkitekturer på en rekke prosessorfamilier, samt blandede instruksjon sett bruker emulering.

Det var også forslag om å begrense bruk av /var, som for tiden er et sammensurium av urelaterte typer data, for å lage en topp-nivå /eksport katalog for nettverksressurser, og å fusjonere /usr hierarkiet inn /helt. Ingen ser spesielt sannsynlig i øyeblikket, men antar at det ikke er syv år før neste FHS revisjon, kan ideene bli gjenopplivet

Det er nok et viktig poeng.; samle interesserte på ett sted og diskutere disse spørsmålene bidra til å avklare nåværende tilstand og får interessentene tenker på nye alternativer. Det var aldri en bevisst beslutning om å la 2,3 utgivelsen av FHS samle støv i syv år – det bare glapp ut av den kollektive bevissthet. Som et resultat, var det flere Unix-lignende grupper (for eksempel BSDene) som mistet interessen helt og har ikke gidder å delta i FHS 3,0 diskusjon. Forhåpentligvis den nye versjonen vil sette standarden tilbake på et solid fotfeste, og mer nyttige debatter fortsetter som den beveger seg fremover. Anmeldelser