Er Linux-kjernedesign utdatert?
Linux har tatt store fremskritt gjennom årene, og kommet langt utover der det var da det startet. Men en redditor lurte nylig på om Linux led av utdatert kjerndesign. Han stilte spørsmålet sitt i Linux subreddit og fikk noen interessante svar.
Ronis_BR startet tråden med disse kommentarene:
Jeg har vært Linux-bruker siden 2004. Jeg vet mye om hvordan jeg bruker systemet, men jeg forstår ikke for mye om hva som er under panseret på kjernen. Egentlig stopper kunnskapen min i hvordan jeg kan kompilere min egen kjerne.
Imidlertid vil jeg spørre informatikere her hvor utdatert Linux-kjernen er med hensyn til utformingen? Jeg mener, den ble startet i 1992, og noen egenskaper endret seg ikke. På den annen side antar jeg at det nyeste innen OS-kjernedesign (hvis dette eksisterer ...) burde ha avansert mye.
Er det mulig å angi i hvilke punkter utformingen av Linux-kjernen er mer avansert sammenlignet med utformingen av Windows, macOS, FreeBSD-kjerner? (Legg merke til at jeg mener design, ikke hvilken som er bedre. For eksempel har HURD et flott design, men det er ganske greit å si at Linux er mye mer avansert i dag).
Mer på Reddit
Hans andre Linux-redditorer svarte med sine tanker om kjernedesign:
ExoticMandibles: ""Utdatert"? Nei. Utformingen av Linux-kjernen er godt informert om moderne kjernedesign. Det er bare det at det er valg å gjøre, og Linux gikk med den tradisjonelle.
Spenningen i kjernedesign er mellom "sikkerhet / stabilitet" og "ytelse". Microkernels fremmer sikkerhet på bekostning av ytelsen. Hvis du har en liten liten mikrokjerne, der kjernen gjør det lettere å snakke med maskinvare, minnehåndtering, IPC og lite annet, vil den ha en relativt liten API-overflate som gjør det vanskelig å angripe. Og hvis du har en buggy filsystemdriver / grafikkdriver / etc, kan driveren krasje uten å ta ned kjernen og kan sannsynligvis startes på nytt ufarlig. Overlegen stabilitet! Overlegen sikkerhet! Alle gode ting.
Ulempen med denne tilnærmingen er den evige, uunngåelige kostnaden for alt det IPC. Hvis programmet ditt vil laste inn data fra en fil, må det spørre filsystemdriveren, som betyr IPC for prosessen, en prosesskontekstbryter og to ringoverganger. Deretter ber filsystemdriveren kjernen om å snakke med maskinvaren, noe som betyr to ringoverganger. Deretter sender filsystemdriveren sitt svar, noe som betyr mer IPC to ringoverganger, og en annen kontekstbryter. Totalt overhead: to kontekstbrytere, to IPC-samtaler og seks ringoverganger. Veldig dyrt!
En monolitisk kjerne bretter alle enhetsdriverne inn i kjernen. Så en buggy grafikkdriver kan ta ned kjernen, eller hvis den har et sikkerhetshull, kan den muligens utnyttes for å kompromittere systemet. Men! Hvis programmet ditt trenger å laste noe fra disken, kaller det kjernen, som gjør en ringovergang, snakker med maskinvaren, beregner resultatet og returnerer resultatet og gjør en ny ringovergang. Totalt overhead: to ringoverganger. Mye billigere! Mye raskere!
I et nøtteskall sier microkernel-tilnærmingen "La oss gi opp ytelsen for overlegen sikkerhet og stabilitet"; den monolitiske kjernetilnærmingen sier "la oss beholde ytelsen og bare fikse sikkerhets- og stabilitetsproblemer når de dukker opp." Verden ser ut til å akseptere om ikke foretrekker denne tilnærmingen.
p.s. Windows NT var aldri en ren microkernel, men det var microkernel-ish i lang tid. NT 3.x hadde grafikkdrivere som en brukerprosess, og ærlig talt var NT 3.x superstabil. NT 4.0 flyttet grafikkdrivere inn i kjernen; det var mindre stabilt, men mye mer performant. Dette var et generelt populært trekk. ”
F22Rapture: “En praktisk fordel for den monolitiske kjernetilnærmingen som gjelder Linux, er at den presser maskinvareleverandører til å få driverne sine inn i kjernen, fordi få maskinvareleverandører vil holde tritt med endringene i kjernegrensesnittet alene. Siden alle de fleste driverne er i treet, kan grensesnittene omformeres kontinuerlig uten å måtte støtte eldre API-er. Kjernen garanterer bare at de ikke vil ødelegge brukerområdet, ikke kjernearealet (drivere), og det er mye churn når det gjelder drivergrensesnittene som presser leverandørene til å føre driverne sine. Nvidia er en av få leverandører jeg kan tenke på som har ressurser til å opprettholde sin egen driver utenom treet, helt basert på proprietære komponenter.
Jeg mistenker at hvis sjåførene var sine egne små øyer atskilt med stabile grensesnitt, hadde vi kanskje ikke så mange selskaper som var villige til å åpne koden. "
Stokkand: "I denne sammenheng refererer ikke" monolitisk "til å ha (nesten) all kjerne og driverkode i et enkelt kildetre, det refererer til det faktum at hele kjernen og driverne kjører som en enkelt" oppgave "i en enkelt adresseplass.
Dette skiller seg fra en "microkernel" der de forskjellige kjerneelementene og driverne kjører som separate oppgaver med separate adresserom.
Som nevnt er Windows-kjernen i utgangspunktet monolitisk, men drivere er fremdeles utviklet separat. macOS bruker en slags hybridkjerne som bruker en mikrokjerne i sin kjerne, men som fremdeles har nesten alt i en enkelt "oppgave", til tross for at nesten alle drivere er utviklet / levert av Apple. ”
Slabity: “Folk har kranglet dette siden før 2004. Tanenbaum-Torvalds-debatten i 1999 1992 er et stort eksempel på argumentene mellom mikrokernel og monolitisk kjernedesign.
Jeg er personlig en del av microkernel-leiren. De er renere, tryggere og mer bærbare. I denne forbindelse var kjernens design utdatert i det øyeblikket den ble opprettet.
... Linux har overvunnet mange av problemene som kommer med monolitiske kjernedesign. Det er blitt modulært, dets strenge kodepolitikk har holdt det relativt trygt, og jeg tror ikke noen vil argumentere mot hvor bærbar det er. ”
TEchnicolourSocks: “Det er bare en riktig måte å utforme kjerne på, og det er måten TempleOS er.
Skrevet i HolyC, uten nettverk, bare ring-0. Som Gud hadde til hensikt. ”
Scandalousmambo: “Naturen til å utvikle et så komplekst system som Linux-kjernen betyr at det alltid vil være” utdatert ”ifølge folk som satt i høye stoler da det ble designet.
Dette operativsystemet representerer sannsynligvis titalls millioner arbeidstimer.
Kan den byttes ut? Sikker. Vil det? Nei."
Grumbel: “Rent praktisk betyr det ikke mye forskjell lenger. Tilbake på dagen var HURD ganske kult med sine userpace-filsystemer og slikt. Men Linux har siden da fått det meste av den funksjonaliteten. Hvis du vil skrive et filsystem, USB-driver eller inndataenhet i brukerområdet, kan du ikke trenger å hacke kjernen. Du kan nå til og med lappe kjernen på kjøretid hvis du virkelig vil.
Linux-filosofien om å bare ikke skrive buggy-drivere som krasjer kjernen i utgangspunktet, i stedet for å gjøre den super robust mot skitne drivere, ser også ut til å fungere ganske bra i den virkelige verden. Vi må sannsynligvis takke USB for det, da maskinvare som er selvbeskrivende fjernet behovet for å skrive en ny driver for hver nye enhet du kobler til PCen.
Så hele designdebatten er nå enda mer akademisk enn den pleide å være, ettersom det bare ikke er mange funksjoner igjen som du ville få med designendringer alene, og som du ikke kunne implementere i en monolitisk kjerne. ”
KugelKurt: “Selv om mye av diskusjonen her handler om mikrokerner vs monolitisk kjerne, gikk nyere forskning i programmeringsspråk.
Hvis du startet en helt ny kjerne i dag, er sjansen stor for at den ikke ville bli skrevet i C. Microsofts Singularity- og Midori-prosjekter utforsket muligheten for C # / administrerte kodekjerner.
Det mest kjente operativsystemet uten forskning uten C-kjerne er sannsynligvis Haiku som er skrevet i C ++. ”
OmniaVincitVeritas: “Det var utdatert da det ble opprettet og er fremdeles slik. Men som kjent fungerer teknisk fremgang nesten aldri slik at den teknisk / vitenskapelig overlegne løsningen løfter seg til topps på kort sikt; så mange andre ting påvirker suksess også.
Hvis det gjorde det, ville vi kjørt 100% sikre mikrokerner skrevet i Haskell. Sikkerhetsselskaper ville ikke eksistere. Jeg vil ha en enhjørning / ponnihybrid som kjører på sollys. ”
Daemonpenguin: “Det er noen konsepter som i teorien kan gi bedre kjernedesign. Det er for eksempel en Rust-kjerne som kan sidestegge et antall minneangrepsvektorer. Mikrokerner har i teorien noen veldig gode designvalg som gjør dem bærbare, pålitelige og potensielt selvkorrigerende.
Problemet er imidlertid at de er mer teori enn praksis. Uansett hvor god en teori er, vil folk nesten alltid ta det som er praktisk (dvs. arbeider nå) fremfor en bedre design. Linux-kjernen har så mye maskinvarestøtte, og så mange selskaper som finansierer utvikling at det er usannsynlig at andre kjerner (uavhengig av deres kule designvalg) vil ta igjen.
MINIX, for eksempel, har en solid design og noen fantastiske funksjoner, men har veldig lite maskinvarestøtte, så nesten ingen utvikler seg for plattformen. ”
Mer på Reddit
DistroWatch vurderer 4MLinux 21.0
Linux tilbyr mange forskjellige distribusjoner. Noen er utstyrt med mer programvare, og andre med mindre. 4MLinux er rettet mot de som foretrekker en lett distribusjon. En forfatter på DistroWatch har en full gjennomgang av 4MLinux 21.0.
Joshua Allen Holm rapporterer for DistroWatch:
4MLinux er en lett Linux-distribusjon designet for å gi fire viktige funksjonsområder. Med bare programvaren som er tilgjengelig på ISO, tilbyr 4MLinux et bredt utvalg av applikasjoner for å utføre systemvedlikehold; spille av mange typer multimediefiler; tilby en miniserver for å tilby en grunnleggende webserver; og den har et anstendig utvalg av spill, som distribusjonen plasserer i en kategori det kaller mysterium. Disse fire funksjonene gir grunnlaget for distribusjonens navn. Fire ting som starter med "M", så 4MLinux.
Oppstart av 4MLinux fra en flash-stasjon er en rask prosess. Jeg ble raskt og automatisk logget inn som root og kunne begynne å jobbe i skrivebordsmiljøet. På skrivebordet bruker 4MLinux JVM kombinert med en Wbar-lansering øverst på skjermen som gir snarveier til store programmer. I tillegg er det IDesk for å administrere skrivebordet, og Conky for å gi grunnleggende systemstatusinformasjon. Wbar, IDesk og Conky kan alle være slått av, men systemet er allerede veldig lett når de er i standard aktivert tilstand.
Ut av esken kommer 4MLinux med et anstendig utvalg av programvare. I JVM-applikasjonsmenyen er det snarveier for en terminal, Internett-applikasjoner, vedlikehold, multimedia, miniserver og mysterium. Internett-undermenyen inneholder lenker for nettlesing, HexChat for IRC, Sylpheed for e-post, overføring for Bittorrent, uGet for nedlasting, et verktøy for å dele filer via Bluetooth, GNOME PPP for oppringte Internett-tilkoblinger, og et alternativ til slå Tor av og på.
4MLinux gir mye programvare i en liten pakke. For systemvedlikehold er det et godt valg å ha for hånden. For multimedia, miniserver og mystery gir det et nyttig utvalg av programvare, men det er andre distribusjoner som bare fokuserer på en av disse oppgavene og gjør det bedre ved å være mer fokusert. Det er ikke å si at 4MLinux er dårlig, men det prøver å gjøre for mange forskjellige ting på en gang. For å være helt ærlig, tror jeg 4MLinux ville være et sterkere tilbud hvis det var 3MLinux og droppet mysteriumaspektet helt. Kanskje inkludert bare kabal eller noe annet lett spill å ha som en avledning mens vedlikeholdsoppgaver kjører og bruke plassen frigjort ved å fjerne spillene for å inkludere noen av de valgfrie utvidelsesapplikasjonene som standard.
Mer på DistroWatch
LinuxInsider omtaler Ultimate Edition 5.4
Ultimate Edition, derimot, er i motsatt ende av spekteret fra 4MLinux. UE er absolutt en maksimal glede siden den er fullpakket med programvare. En forfatter på LinuxInsider har en full gjennomgang av Ultimate Edition 5.4.
Jack M. Germain rapporterer for LinuxInsider:
Jeg var ikke begeistret over mine første praktiske erfaringer med å bli kjent med Ultimate Edition 5.4. Jeg fant en irriterende liste over ting som var galt med den.
Med mange års gjennomgang av Linux-distroer under beltet, har jeg lagt merke til en solid sammenheng mellom førsteinntrykk av en distros nettsted og varige inntrykk av en distros ytelse. La oss bare si at nettstedets uorganiserte tilstand, i dette tilfellet, gjennomfører i denne distros siste utgivelse.
Ett lite eksempel: Jeg fant ingen liste noe sted over minimumskrav til installasjon for maskinvare. Det viste seg å være frustrerende. Jeg kastet bort tid på å prøve å laste Ultimate Linux på flere aldrende datamaskiner. Noen av problemene var relatert til minne og lagringsplass. Andre problemer involverte mangler på grafikkort.
Ultimate Edition retter seg mot Linux-nykommere, men de som prøver det, trenger kanskje litt mer kjennskap til Linux for å komme rundt noen av problemene i å kjøre dette ikke-så-ultimate Linux OS.
Mer på LinuxInsider
Bommet du på en sammendrag? Sjekk Eye On Open-hjemmesiden for å bli oppdatert med de siste nyhetene om åpen kildekode og Linux.
