Nå er det norske operativsystemet IncludeOS klar til bruk

[joerlend]

Jeg sliter litt med å forstå konseptet, sett fra en containerbrukers perspektiv. Det virker litt unødvendig hvis du allerede har et containermiljø, men hvis du ellers ville ha brukt en vanlig VM, så begynner det å gi mening. Men hvis du prøvde å selge meg dette som en erstatning for Docker og LXD, så kjøper jeg ikke. Men hvis det er tenkt mer som en hypervisor-uavhengig mellomting mellom VM og container, så er det i hvertfall interessant, selv om jeg personlig ikke klarer å se hva jeg ville ha brukt det til. Jeg mener; hvis jeg skal ha en webserver i en sky, så er ressursbruken så liten at det er lite å spare. Men hvis jeg skulle ha mange webservere i en sky, så ville det tilsynelatende lønne seg å sette opp et containersystem i utgangspunktet, særlig hvis du ender opp med forskjellige versjoner av IncludeOS.

 

Men morsomt konsept, særlig fordi jeg ikke forstår det. Det er jo nødvendig for å kunne bli positivt overrasket.

[Per Buer]

Containere er noe annet. De er generiske bokser som du bygger rundt en app for å isolere den. Men de er veldig tungdrevne og ikke særlig egnet til bruk i "high throughput, low latency".

Tenk at du er Amazon. Du har 100 Petabyte med lagring som skal tilbyes til rundt en million vm'er. Du har ATA-over-Ethernet på storage-siden og noe blockdevice-over-tcp på vm-siden. Du trenger X antall vm'er som skal holde litt tilstand på dette. Da kunne IncludeOS vært noe.

Eller Pokemon Go. Du har tusenvis av VM'er som skal snakke med millioner av klienter. Du trenger et edge-lag i arkitekturen din som håndterer klientene og forholder seg til API'ene på innsiden. Det edgelaget skal være sikkert, raskt og kunne skaleres hurtig opp og ned. Rimelig perfekt use-case.

Med mindre du skriver den koden du skal kjøre selv så er neppe IncludeOS relevant med det første. Mulig det kan bli det på sikt.

[8D7R4G4Y]

 

Meget interessant prosjekt for min del da jeg skriver masse c/c++-prosjekter, men før det er full posix-støtte eller støtte for tråder blir det rimelig umulig å få brukt det. Håper på oppdateringer:)

Hvorfor vil du ha tråder?

 

For det første bruker jeg systemer som har 88 fysiske tråder i dag, og 5000 i morgen. For det andre er det veldig vanskelig å lage 100% asynkrone/nonblocking løsninger når man skal integrere mange apier. For det tredje vil en applikasjon jobbe raskere når en deler opp arbeidsmengden i flere tråder. Hvis du vil dele opp en jobb over flere applikasjoner i stedet snakker vi om en overhead som er uønskelig for min del. For det fjerde så er dagens hardware og interrupter designet for å kunne utnytte flere tråder i en applikasjon eller operativsystem. Bruker du et os uten støtte for tråder kommer hardwaren din til å jobbe i sneglefart.

[8D7R4G4Y]

Eller POSIX for den saks skyld. Posix er for at brukeren skal finne frem, dette skal kjøres uten bruker.

Uten posix må jeg skrive om prosjektene mine for å få kjørt dem. Det er fint med en standard som fungerer på mer enn ett os.

Eller synes du at alle bør skrive applikasjonene sine 3 ganger for å støtte mac, linux og windows ?

[Shruggie]

 

Eller POSIX for den saks skyld. Posix er for at brukeren skal finne frem, dette skal kjøres uten bruker.

Uten posix må jeg skrive om prosjektene mine for å få kjørt dem. Det er fint med en standard som fungerer på mer enn ett os.

Eller synes du at alle bør skrive applikasjonene sine 3 ganger for å støtte mac, linux og windows ?

 

Fair enough, men det vil ikke hjelpe deg til å kjøre ting på IncludeOS. Mer her: https://github.com/hioa-cs/IncludeOS/wiki/FAQ

[Per Buer]

 

 

Meget interessant prosjekt for min del da jeg skriver masse c/c++-prosjekter, men før det er full posix-støtte eller støtte for tråder blir det rimelig umulig å få brukt det. Håper på oppdateringer:)

Hvorfor vil du ha tråder?

 

For det første bruker jeg systemer som har 88 fysiske tråder i dag, og 5000 i morgen. For det andre er det veldig vanskelig å lage 100% asynkrone/nonblocking løsninger når man skal integrere mange apier. For det tredje vil en applikasjon jobbe raskere når en deler opp arbeidsmengden i flere tråder. Hvis du vil dele opp en jobb over flere applikasjoner i stedet snakker vi om en overhead som er uønskelig for min del. For det fjerde så er dagens hardware og interrupter designet for å kunne utnytte flere tråder i en applikasjon eller operativsystem. Bruker du et os uten støtte for tråder kommer hardwaren din til å jobbe i sneglefart.

 

Jeg tviler veldig på at systemet ditt har fysiske tråder i seg. :-)

Og så og si all programvare jeg jobber med til daglig er trådet. Dog vil jeg si at maskinvare i liten grad er laget for det. Du har disse CPUene med flere registersett som kjappere kan bytte mellom to tråder i samme applikasjon, men ytelsesgevinsten ved å slippe å gjøre dette byttet er temmelig klar.

 

Tråder er fint - men at IncludeOS ikke har noen støtte for det er faktisk helt OK. På en måte hadde det vært moro å få Varnish til å kjøre i det - men det ville uansett tatt et par år å komme dit (vi er gift med temmelig omfattende POSIX).

 

IncludeOS skal jo, i motsetning til f.eks. Linux, ikke være "all thing to everyone". Det er et nisjesystem.

[Emancipate]

Huff, her var det mange kunnskapsløse kommentarer. Man trenger ikke å kunne mye om dette for å skjønne hva det er.
 

Det må være noe jeg misser.

Ja.
 
I noen sammenhenger har det blitt populært å kjøre "virtuelle maskiner". Bruksområdene for dette kan dere slå opp selv. Da har man et "host OS" og et "guest OS". Host OS kan være Windows, Linux eller et mer spesialisert lettvekts-OS. Guest OS er som regel Windows eller Linux. IncludeOS er en erstatning for Linux/Windows som guest OS.
 
Fordelen er åpenbar: Man kan få plass til maaaaaange flere virtuelle maskiner på en fysisk maskin, fordi diskplass og minnebruk blir mye mindre.
 

Eller POSIX for den saks skyld. Posix er for at brukeren skal finne frem, dette skal kjøres uten bruker.

POSIX er et API. Det er et standard sett funksjoner som kan brukes av programvaren. At det skal kjøres uten bruker blir en litt rar tankegang. Hvis ingen bruker et system, hva er vitsen med å kjøre det?
 

Hvorfor vil du ha tråder?

De aller fleste moderne programmer kan kjøre ting parallelt i flere tråder. Unntaket er Node.js, som kjører flere prosesser. IncludeOS har ikke støtte for hverken tråder eller prosesser.
 

 

[Shruggie]

Posix DEFINERER et API, men det er bare en bitteliten del av standarden. Og selvsagt skal VMer kjøres uten bruker, hva i alle dager prater du om? Vi snakker om redundante server-prosesser her - microservices, ikke å kjøre en SSH server. 

 

Og hvis du bruker microservices for å kjøre flertrådete oppgaver, så har du antageligvis ikke fulgt med på hva som har skjedd i industrien de siste årene.

 

Alt i alt tror jeg du skal være jævlig forsiktig med å snakke om kunnskapsløshet...

Endret 1. oktober 2016 av Shruggie

[Emancipate]

Det var åpenbart at det var POSIX-apiet vedkommende som sa at støtte for POSIX manglet, mente.

[Shruggie]

Det var åpenbart at det var POSIX-apiet vedkommende som sa at støtte for POSIX manglet, mente.

Nei, det var ikke det. Og selv om det var det hadde ikke det du sa vært riktig.

[8D7R4G4Y]

 

 

Eller POSIX for den saks skyld. Posix er for at brukeren skal finne frem, dette skal kjøres uten bruker.

 

Uten posix må jeg skrive om prosjektene mine for å få kjørt dem. Det er fint med en standard som fungerer på mer enn ett os.

Eller synes du at alle bør skrive applikasjonene sine 3 ganger for å støtte mac, linux og windows ?

Fair enough, men det vil ikke hjelpe deg til å kjøre ting på IncludeOS. Mer her: https://github.com/hioa-cs/IncludeOS/wiki/FAQ

Kan du utdype det?

[8D7R4G4Y]

 

Det var åpenbart at det var POSIX-apiet vedkommende som sa at støtte for POSIX manglet, mente.

 

Nei, det var ikke det. Og selv om det var det hadde ikke det du sa vært riktig.

Jeg trodde det var åpentbart at det var det jeg menteDet er jo det jeg utvikler mot:)

 

 

 

Meget interessant prosjekt for min del da jeg skriver masse c/c++-prosjekter, men før det er full posix-støtte eller støtte for tråder blir det rimelig umulig å få brukt det. Håper på oppdateringer:)

 

Hvorfor vil du ha tråder?

For det første bruker jeg systemer som har 88 fysiske tråder i dag, og 5000 i morgen. For det andre er det veldig vanskelig å lage 100% asynkrone/nonblocking løsninger når man skal integrere mange apier. For det tredje vil en applikasjon jobbe raskere når en deler opp arbeidsmengden i flere tråder. Hvis du vil dele opp en jobb over flere applikasjoner i stedet snakker vi om en overhead som er uønskelig for min del. For det fjerde så er dagens hardware og interrupter designet for å kunne utnytte flere tråder i en applikasjon eller operativsystem. Bruker du et os uten støtte for tråder kommer hardwaren din til å jobbe i sneglefart.

 

Jeg tviler veldig på at systemet ditt har fysiske tråder i seg. :-)

 

Og så og si all programvare jeg jobber med til daglig er trådet. Dog vil jeg si at maskinvare i liten grad er laget for det. Du har disse CPUene med flere registersett som kjappere kan bytte mellom to tråder i samme applikasjon, men ytelsesgevinsten ved å slippe å gjøre dette byttet er temmelig klar.

Tråder er fint - men at IncludeOS ikke har noen støtte for det er faktisk helt OK. På en måte hadde det vært moro å få Varnish til å kjøre i det - men det ville uansett tatt et par år å komme dit (vi er gift med temmelig omfattende POSIX).

 

IncludeOS skal jo, i motsetning til f.eks. Linux, ikke være "all thing to everyone". Det er et nisjesystem.

Kall det gjerne kjerner hvis du vil. Eneste forskjellen i forhold til tråder i et os er omtrent bare delt minne:)

 

Jeg mener du tar feil angående maskinvare som i liten grad er laget for det. Det finnes vel snart ikke maskinvare igjen som ikke er laget for det. Nettverkskortet ditt er multicore/queue. Diskdriveren din er multicore (helt ned på fysisk lesenivå på feks nvm-disker). Gpuen din har tusenvis av cores. Dette gjelder også virtuelle maskiner. Å fyre opp en ekstra stor haug med vmr for å kunne utnytte alle tråder/kjerner/multiqueues ser jeg ikke på som en spesielt god løsning. Det bør kunne utnyttes på flere nivåer enn dette. Behovet for mpi/ipc kommer også gjerne fort da, noe som ikke blir billig.

 

Men som du sier; Det er mange som ikke har dette behovet. I allefall ikke i dag.

[Shruggie]

Fair enough, det var bare ikke sånn jeg leste det.