Onsdag 21 Nov 2018
18.11.21 10:55
Att utveckla en fönsterhanterare till Linux #2
Nu fick jag ju lite press på mig att faktiskt visa upp något, så här kommer den hemliga funktion 3 (det kommer att bli ett antiklimax för dom flesta tror jag)
Skrev att funktion 3 var påväg i mitt förra inlägg: Att utveckla en fönsterhanterare till Linux & nu har jag suttit & knåpat lite på den
Så funktion 3 är en inbakad version av HTCondor, eller ja, snarlikt koncept, dock kör jag utan schemaläggare eller kö, allt körs "live", ej distribuerat/klustrat (än), en dator åt gången per process nöjer jag mig med just nu.
Man kan också beskriva den som "x11vnc" fast utan vnc delen & bara input injection delen, jag är en flitig användare av x11vnc MEN mitt stora problem är att ifall jag använder lösningar baserad på frambuffer så funkar det skitdåligt då jag ofta sitter på 4g & 3g uppkoppling med väldigt tvivelaktig uppkoppling & begränsad bandbredd, då är det inte så roligt att hålla på & polla från en framebuffer & slösa bort den lilla bandbredden man har & eftersom x11vnc ändå implementerar en injection lösning för input så varför skicka framebuffer när man lika gärna kan köra hela fönstret lokalt & bara skicka kommandona till remote datorn som kör den relevanta processen ändå? Det blir mycket "billigare" bandbreddmässigt att bara dela input + data (return från remote process) istället för framebuffer
Funktion #3 hör ihop med funktion #2, all data är delad mellan alla datorer (om inte data-policyn säger annat men då får man hålla koll på att den processen man kör inte använder osyncad data, rörigt förklarat, går in mer på policy i framtiden), detta gör att alla "remote" processer körs lokalt men kan flyttas mellan vilken dator som helst, det spelar egentligen ingen roll på vilken dator en process körs på, processen går att nå från vilken dator som helst (hade ju underlättat om man kunde använda samma PID på alla datorer så man slipper mappa olika PID som är "samma" process mellan dom olika datorerna, har någon en lösning på att tvinga fram en PID så säg till)
Så kör jag ett program lokalt, tex "Writer" så fungerar allt precis som det gör på alla datorsystem, programmet öppnas & startar diverse processer. Medan programmet körs kan jag välja att programmet skall köras på en annan dator i nätverket, all data från processen sparas i ett "middleware", sen spawnas (eller använder en befintlig process om den finns tillgänglig & "tom") en likvärdig process på remote host:en (en annan dator i nätverket alltså), den nya processen mappas till den processen som sparades (middleware agerar som en translator mellan olika men samma process (hur illa förklarar jag egentligen? )) & därefter kopieras all process data till denna nya processen på remote host:en. X öppnar inget fönster på remote host:en utan endast en dolt process då ett fönster inte behövs, detta är som sagt ingen VNC lösning
Förväxla inte detta med X över nätverk heller, inte samma sak
Därefter skickas all interaktion med det lokala fönstret till remote processen (fönstret körs fortfarande lokalt till skillnad från VNC lösningar men skickar viss userinput (ej musrörelser & endast interaktion med GUI:t som resulterar i ny data) till den externa datorns process & därmed kan den externa datorns processorkraft användas istället)
(Liten demonstrations-film, filmen är rätt suddig, körde skräpet i en VM på macOS där jag kör en skalad upplösning, glömde av att ändra, så macOS skapar någon obskyr upplösning för att visa 1920xXXXX, så när jag spelade in skärmen via macOS så blev filmen i upplösningen 3686x2304 såååååå, jag, det blev som blev, hoppas det är okej, spelade in typ 10ggr innan skiten slutade krascha så vill inte göra om)
Edit igen: I filmen nämnde jag (tror det var denna jag nämnde det i) att webbläsaren också går att köra remote, det stämmer inte riktigt, det GÅR men det är för tillfället inte användbart, kör man remote så går det inte klicka på länkar, har inget sätt att få tillgång till länkarna & skicka data emellan processerna, i mina egna program skickas datan till remote-processer vid UI:event, men skit samma, man kör inte webbläsare remote ändå, eller jag har inte kommit på någon vettig anledning att göra det iaf
Varför?
Enkla svaret är lätt tillgång till andra datorer i nätverket, istället för VNC, SSH eller andra lösningar, förenklad delning av data. Tex jag jobbar ofta på min bärbara som går på knäna när jag kompilerar stora projekt, här är det superenkelt att flytta över kompileringen till en annan dator i nätverket så jag kan jobba vidare lokalt utan att störas av resurserna kompileringen kräver
Encoding är ett annat svar, eftersom all lagring är syncad (med den policyn jag kör nu) så är det lätt att dela upp jobb mellan dom datorerna man har tillgänglig om man vill, finns ju andra (bättre) lösningar som är klustrade, tex Compressor & jag tror Adobe också har något liknande, men licenskostnad & ibland krånglig setup osv, man kan komma undan med att bara skicka iväg lite ffmpeg jobb istället
Andra saker när den lokala datorn inte har resurser nog (få CPU kärnor & för lite ram), kör det remote på en biffigare dator istället
Till skillnad från VNC lösningar såsom x11vnc så kopplar man inte upp sig till ett remote fönster utan man kan flytta en process mellan alla datorer man har tillgängliga, programmen är alltså INTE låst till en dator på sättet som VNC lösningar används till
Tusen andra användningsområden (visar lite andra exempel såfort jag knåpat ihop lite relevantare program). Många (alla) användningsområden finns det redan lösningar på men har alltid viljat ha det inbakat direkt i OS:et
Känns som jag behöver gå igenom systemet mer genomgående framöver, tror inte jag förmedlade dess styrkor tillräckligt bra i detta inlägget
Man kan också beskriva den som "x11vnc" fast utan vnc delen & bara input injection delen, jag är en flitig användare av x11vnc MEN mitt stora problem är att ifall jag använder lösningar baserad på frambuffer så funkar det skitdåligt då jag ofta sitter på 4g & 3g uppkoppling med väldigt tvivelaktig uppkoppling & begränsad bandbredd, då är det inte så roligt att hålla på & polla från en framebuffer & slösa bort den lilla bandbredden man har & eftersom x11vnc ändå implementerar en injection lösning för input så varför skicka framebuffer när man lika gärna kan köra hela fönstret lokalt & bara skicka kommandona till remote datorn som kör den relevanta processen ändå? Det blir mycket "billigare" bandbreddmässigt att bara dela input + data (return från remote process) istället för framebuffer
Funktion #3 hör ihop med funktion #2, all data är delad mellan alla datorer (om inte data-policyn säger annat men då får man hålla koll på att den processen man kör inte använder osyncad data, rörigt förklarat, går in mer på policy i framtiden), detta gör att alla "remote" processer körs lokalt men kan flyttas mellan vilken dator som helst, det spelar egentligen ingen roll på vilken dator en process körs på, processen går att nå från vilken dator som helst (hade ju underlättat om man kunde använda samma PID på alla datorer så man slipper mappa olika PID som är "samma" process mellan dom olika datorerna, har någon en lösning på att tvinga fram en PID så säg till)
Så kör jag ett program lokalt, tex "Writer" så fungerar allt precis som det gör på alla datorsystem, programmet öppnas & startar diverse processer. Medan programmet körs kan jag välja att programmet skall köras på en annan dator i nätverket, all data från processen sparas i ett "middleware", sen spawnas (eller använder en befintlig process om den finns tillgänglig & "tom") en likvärdig process på remote host:en (en annan dator i nätverket alltså), den nya processen mappas till den processen som sparades (middleware agerar som en translator mellan olika men samma process (hur illa förklarar jag egentligen? )) & därefter kopieras all process data till denna nya processen på remote host:en. X öppnar inget fönster på remote host:en utan endast en dolt process då ett fönster inte behövs, detta är som sagt ingen VNC lösning
Förväxla inte detta med X över nätverk heller, inte samma sak
Därefter skickas all interaktion med det lokala fönstret till remote processen (fönstret körs fortfarande lokalt till skillnad från VNC lösningar men skickar viss userinput (ej musrörelser & endast interaktion med GUI:t som resulterar i ny data) till den externa datorns process & därmed kan den externa datorns processorkraft användas istället)
(Liten demonstrations-film, filmen är rätt suddig, körde skräpet i en VM på macOS där jag kör en skalad upplösning, glömde av att ändra, så macOS skapar någon obskyr upplösning för att visa 1920xXXXX, så när jag spelade in skärmen via macOS så blev filmen i upplösningen 3686x2304 såååååå, jag, det blev som blev, hoppas det är okej, spelade in typ 10ggr innan skiten slutade krascha så vill inte göra om)
Edit igen: I filmen nämnde jag (tror det var denna jag nämnde det i) att webbläsaren också går att köra remote, det stämmer inte riktigt, det GÅR men det är för tillfället inte användbart, kör man remote så går det inte klicka på länkar, har inget sätt att få tillgång till länkarna & skicka data emellan processerna, i mina egna program skickas datan till remote-processer vid UI:event, men skit samma, man kör inte webbläsare remote ändå, eller jag har inte kommit på någon vettig anledning att göra det iaf
Varför?
Enkla svaret är lätt tillgång till andra datorer i nätverket, istället för VNC, SSH eller andra lösningar, förenklad delning av data. Tex jag jobbar ofta på min bärbara som går på knäna när jag kompilerar stora projekt, här är det superenkelt att flytta över kompileringen till en annan dator i nätverket så jag kan jobba vidare lokalt utan att störas av resurserna kompileringen kräver
Encoding är ett annat svar, eftersom all lagring är syncad (med den policyn jag kör nu) så är det lätt att dela upp jobb mellan dom datorerna man har tillgänglig om man vill, finns ju andra (bättre) lösningar som är klustrade, tex Compressor & jag tror Adobe också har något liknande, men licenskostnad & ibland krånglig setup osv, man kan komma undan med att bara skicka iväg lite ffmpeg jobb istället
Andra saker när den lokala datorn inte har resurser nog (få CPU kärnor & för lite ram), kör det remote på en biffigare dator istället
Till skillnad från VNC lösningar såsom x11vnc så kopplar man inte upp sig till ett remote fönster utan man kan flytta en process mellan alla datorer man har tillgängliga, programmen är alltså INTE låst till en dator på sättet som VNC lösningar används till
Tusen andra användningsområden (visar lite andra exempel såfort jag knåpat ihop lite relevantare program). Många (alla) användningsområden finns det redan lösningar på men har alltid viljat ha det inbakat direkt i OS:et
Känns som jag behöver gå igenom systemet mer genomgående framöver, tror inte jag förmedlade dess styrkor tillräckligt bra i detta inlägget
