nem nyert, talán átfutottál a transaction szón. Itt nem a filerendszer van szétszórva gépekre, hanem egy tranzakció. Azt mondom a saját gépem kernelének, hogy inditok egy xyz azonositójú tranzakciót, amelynek résztvevője a helyi c lemez egyik ntfs kötete, egy távoli gép egyik sharejének egyik állománya ill egy userlandben futó alkalmazás (mondjuk web service) xy hivása. Majd elkezdek dolgozni a tranzakción belül, felülirok fileokat a helyi gépen, a távoli gépen, belehivok a web service-be, majd kiderül, hogy valami gáz van, rollback az egész. És innentől a kernel levezényli a helyi ntfs, a távoli share (jah, akár távoli registry is lehet) ill a web service visszaállitását a tranzakció előtti állapotba.
"Melyik reszet kellene kombinalni userland-el?"
lásd fent
"Jo hat persze, Win API nincs benne"
kár, hogy ez nem win api. és kár, hogy nem is ugyanezt várnám a vms (de lehet tőlem linux is) kernelétől, hanem csak egy ennek megfelelő absztrakciójú és komolyságú apikat. Nem kell ezt erőltetni, köze nincs egy vms-nek ilyen szintű dolgokhoz. Hát erről beszéltem, hogy majd akkor hasonlitgassuk őket, ha hasonló szintű szolgáltatásokat nyújtanak.
"Ha szamodra ez azt jelenti, hogy ossz-vissz. 2 db van, akkor sajnalom"
jó látom továbbra sem érted az egészet. Én vállalati SAJÁT FEJLESZTÉSŰ több száz alkalmazásról beszélek. (amit aztán ki lehet egésziteni érzés szerint néhány KÜLSŐ alkalmazással is, ami szintén szivás mikor megáll az új kernel miatt, de valójában elhanyagolható probaléma, mivel azoknak más a felelőse)
"tehat ott nem kell kernelt buheralni"
ehh, de nem érted... nem a kernelt kell buherálni, azt már szétbaromlta más, neked a saját dolgaidat (és a 3rd party) alkalmazásokat kell újra és újra az állandóan változó kernelhez heggeszteni.