Russinovich szerint megérhetjük még a nyílt forrású Windowst

Microsoft, Windows

Mark Russinovich magáénak tudhatja a Microsoft egyik legmegtisztelőbb címét. Mark Russinovich Microsoft Technical Fellow. Windows kernelhacker, a Microsoft Azure műszaki igazgatója.

Russinovich a napokban azt találta mondani egy, a kaliforniai Santa Clara-ban megrendezett eseményen (ChefCon), hogy egy nyílt forrású Windows eljövetele határozottan lehetséges, utalva arra, hogy a mostani Microsoft már egy teljesen más Microsoft.

A részletek itt olvashatók.

( carlcolt | 2015. 04. 03., p – 19:16 )

Engem nem is az erdekel, hogy open source legyen, hanem hogy Unix like / Unix based legyen a fo asztali rendszeruk. (Tudom, ez sok visszafele komaptibilitasi problemat okozna, valahogy kapasbol "emulalni kene a regi fajlrendszert" 20 eve irt alkalmaszasokhoz, etc.)

(Mindjart jon egy random Powershell troll, aki nem fogja felfogni, hogy a Powershell a bash/csh/zsh-val ellentetben nem system-wide shell. Aztan vele karoltve meg fog erkezni egy Cygwin troll is, aki ugyanezt nem fogja felfogni)

(Mindjart jon egy random Powershell troll, aki nem fogja felfogni, hogy a Powershell a bash/csh/zsh-val ellentetben nem system-wide shell. Aztan vele karoltve meg fog erkezni egy Cygwin troll is, aki ugyanezt nem fogja felfogni)

A powershell nem az, de a .NET-tel jóbarát, és azzal együtt már rendszerek elég széles körét képes közvetlen megszólítani. Tanultak a VBScriptből, és most már minden új verziójú MS termék vagy powershellel szkriptelhető, vagy legalább van olyan API-ja, ami .NET-en keresztül elérhető.

Amúgy meg kár vitatkozni, almát körtével összehasonlítani. A *sh plaintext alapú, aminek megvannak az előnyei (mindennel kompatibilis, ami Unix), meg a hátrányai (minden inputot parse-olni kell, szívni az escape-eléssel, stb), a PS meg objektumalapú, aminél meg más előnyök és hátrányok vannak. Nem véletlenül lett a PS olyan, amilyen, nagyon szépen elmagyarázzák a készítői, és bárki megtapasztalhatja, mennyire értelmetlen (pl Cygwin alatt) szöveges Unix-szerű shellt használni Windows adminisztrálására.

ez cseppet sem volt triviális. amikor először tettem fel ezt a kérdést, akkor a szaki mondta, hogy írjak egy vb scriptet, ami meghívja a ps scriptet. mondtam, hogy bocs, ekkora baromságot had ne. tök jó nyelv és ennyire gáz nyitás. amúgy meg így is bloat a cucc (majd ha úgy fut egy egy soros hello world, mint egy sima cmd (indulási vs futási idő), akkor újra kap pluszt tőlem. addig csak akkor, ha indifferens a környezet indítási ideje (mert pl sokáig fut)

u.i.: xp (fujjfujj?) esetén még most sem támogatott (ne gyere azzal, hogy miért xp. mikor jött ki a ps?)

--
xterm

Nem idiotizmus vagy informatikai analfabetizmus ez, hanem csak szimplan ez lett szamomra "a logikus rendszer", leven ebben az evtizedben a leheto legritkabban hasznaltam Windows-t, szinte semennyire sem. Lehet, hogy nekem a bash script a kalapacs es nekem minden szog, de szamomra ez annyira logikussa valt, par aprosagot leszamitva (pl user-group-other fajljogosultsagok, azok aztan tenyleg elavultak), hogy nekem ezekutan teljesen idegen a Windows-fele registry-s, cmd.exe-s, Documents and Settings-es vilag. Mas rendszerekben meg valljuk be, ez a "60-as evekbeli szemetdomb" mukodik, sok esetben meg konkretan jol is.

Lehet, nem tűnt fel, de a Microsoft kb. a .NET óta mást se csinál, csak radírozza le szépen lassan a régi sallangot és próbálja átlendíteni a 80-90-es években lefektetett alapokat a 21. századba.

Registry meg a cmd? Kb. a kit érdekel kategória, nem ez a jövő, régóta nem. Documents and SettingsUsers-el meg nem tudom mi a bajod, teljesen ugyanaz, mint a /home Linuxon.

Egyébként egy szóval nem mondtam, hogy a Windows lesz az egyetlen ultimate alternatíva a 70-es éveknek. Csak azt, hogy az egekig ajnározott Unix filozófia ebben a formában kőkorszak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

.AppData/Local/LocalRow/Roaming/Documents/Registry/ProgramData/.Application Data/.Local Settings/My Documents.

Emlékeztető, hogy többszáz Unixnak 40 év alatt összesen se sikerült ekkora kompatibilitási+használhatósági káoszt összehoznia.

Ja, és a ROTFL-díjas (bugtenger) NFS kliens, valamint a Control Panel, amit sikerült annyira meginnoválni, hogy a Windows 3.1-é is átláthatóbb és jobban tervezett.

Szerintem a meghajtóbetűjelezés jóval ósdibb és ijesztőbb. Az egységes fájlrendszernek egyszerűen nincs egyetlen hátránya sem.
A parasztot úgyis csak az érdekli hogy a fájlkezelőjében lásson valami gombócot ha bedugja a pendrive-ot, meg mellette egy eject icont. Ez pedig megvalósul minden modern DE -ben.

--
arch,debian,openelec,android

Mostmar kivancsi vagyok: mi az ami egyertelmuen olyan bajod, ami az osszes Unix-alapu es Unix-szeru rendszert erinti?

Oke, text alapu shell neked nem jott be, nekem igen, nalam okosabbak is mondtak, hogy az objektum parse-olas nem shell feladat, de elfogadom, hogy ha szerinted igen / neked ugy kenyelmesebb

Azt is alairom, hogy az ugo rwx jogosultsag rendszer elegge hianyos tervezes, meg hat van par apro baromsag (datumoknal honapok vs het napjainak szamozasa)

Az is oke, hogy a C-nek mik a problemai.

De pl. en is tudok ilyet ami evtizedek ota a Windows resze es ugy rossz ahogy van: registry.

De a lenyeg: mostmar kivancsi vagyok. Hogy nezne ki neked egy olyan "tokeletes oprendszer", ami nincs megragadva a 60-as 70-es evekben? Nem muszzaj hogy a Windows legyen a peldad, lehet total fiktiv is, csak "ne legyen benne egy 60-as 70-es evekbeli elem sem" ugymond. ;)

Oke, text alapu shell neked nem jott be, nekem igen

Ebben az a szép, hogy ott van pl. a Python. (volt erről már egy thread, ahol egy Powershell-huszár nagyon hirtelen elhallgatott, amikor a több kommentjében levő "ezt a feladatot nem is lehet két sorban pythonnal megoldani" problémát két sorban [amiből egy egy import volt] megoldottam...)

De pl. en is tudok ilyet ami evtizedek ota a Windows resze es ugy rossz ahogy van: registry.

A kivitelezés lehet, hogy rossz, de azt el kell ismerni, hogy "azok" megcsinálták az egységes, központilag, egységes eszközökkel (regedittől a policy-ig) menedzselhető konfigurációt - amit aztán az alkalmazásfejlesztők többnyire rosszul használtak, ez tény.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

De pont az a baj, hogy rengeteg alkalmazas egy hatalmas adatbazishoz nyul, hasonlitsd mar ezt ossze az OS X-es plist fajlokkal pl., ahol nem minden rendszerdb-bol kiolvasasnal ugyanazt a hatalmas adatbazisfajlt nyitod meg es filterezed, hanem eleve egy-egy kis fajlokat nyitogatsz meg azzal a keves kulccsal, ami kellhet (es azokba is irsz). (A Unix plain text konfig viszont ehhez kepest tenyleg kokorszak).

Nem azt mondtam, hogy jó a megvalósítás, de a cél jó volt. Felőlem lehet per user fájlokban kismillió mappába szétdobálva a konfig, ha egységes és eszközökkel jól ellátott. (valamelyik BSD-nél is a "kövi pár év tevei" dián szerepelt ez, tehát nem lehetek ezzel egyedül :) )

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A registry sem egy fajl, masreszt a sok kis fajl nyitogatasa-csukogatasa meg aztan valoban eroforras takarekos. Harmadreszt meg sok ember a regedit alapjan iteli meg a registry sebesseget, mellette epp csak azt keptelen felfogni, hogy a registry egy kulcs-ertek alapu db, es nem arra van optimalizalva, hogy szekvencialisan olvass belole, hanem arra, hogy kulcsokat erj el gyorsan.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem egy fajl, de egy nagy db, amihez sokszor hozzanyulnak, es amikor hozzanyulnak, ugyanugy olvasgatni irogatni es ezekkel szinkronban lockolgatni kell egy par soros plist fajlhoz kepest mindenkeppen nagyobbnak szamito fajlokat. Raadasul OS X-nel aztan a file cache-eles tenyleg jol meg van ilyen teren oldva (teny, hogy elegge ram pazarlo mas szempontbol), tehat a "sok fileio" erved sem igazan all a laban.

Ami kulon van, az legyen kulon kicsi es fuggetlen adatszerkezet, lasd meg singleton vs multithread, nos, gondolj ugy a registy-re, mint egy "mindenkeppen brutalisan nagy singleton" ahova kulonbozo process-ek szeretnenek irni es olvasni is. Agyrem.

(Persze nem a Windows hibaja, hogy az alkalmazasok fejlesztoi akkor is odairnak, amikor semmi nem indokolja)

Erdekes, hogy egy nehany 10 Mb-nyi adatot kezelo adatbazisra igy kiakadnak itt egyesek, aztan meg masik oldalrol jon a bigdata es a sokszaz Tb, Pb kulcs-ertek alapu adatbazisok.

De sebaj, mint tudjuk a registry nem kerulhet file cacheba, illetve az abban valo dolgozas csak es kizarolag filebol tortenhet, mert veletlen sem kezelheti a memoriaban a registryt a Windows, azt nem kezelheti lock-free adattipussal, stb.

Mindenesetre vicces, hogy ennyire leragadtatok a Windowsnal, abbol is kb. a 80-as, 90-es evek termesenel.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Te jottel azzal hogy "a file io nem optimalis", azert jottem a file cache-sel, egy szoval se mondtam hogy a registry-t nem cache-eli be a Windows a memoriaba. Raadasul a memoriaban ugyanugy oda kell figyelni, hogy ha egy adatbazisba irna es olvasna 10-100 program, egy plistnel meg a legritkabb esetben tobb 2 process-nel. (Arrol nem is beszelve, hogy azt a memoriaba irt adatbazist/valtozasait idonkent vissza is kell irni a diskre (aramszunet? Plane desktopon)).

"Mindenesetre vicces, hogy ennyire leragadtatok a Windowsnal, abbol is kb. a 80-as, 90-es evek termesenel."

Mondja ezt Mr. "Ne legyen ez is Unix, mert egy ujabb rendszer ragad le a 70-es evekben". Egyebkent meg ilyen logikaval ne igyal vizet, mert mar tobb evezreddel ezelott is vizet ittak. Meg ha mar "minden elvatult ami a 70-es evekbol meg a Unixbol jott", hasznalj csupa olyan oprendszereket meg programokat, amiben abszolut semmi sem C-bol lett gepi kodra forditva. Ja hogy nincs ilyen? Szivas!

Hm, bocs talán fel tudsz világosítani (vagy itt valaki). Mennyire szokta a Windows úgy alapjáraton a registry DB-t izélgetni ?

Nehezen tudom elképzelni, hogy pl egy Photoshop, vagy akármilyen más programot mondhatnék, futás időben a registry-t piszkálja. Ettől függetlenül persze lehetséges.

Mert, rendben, feltelepül a program, egy rakás dolgot elraktároz. Rendben. Induláskor kiolvas ezt azt, rendben.

Magára a Windowsra mint OSre is kiváncsi lennék, hogy futás időben mennyit szokott "read/write" műveleteket végezni a regDB-ben, úgy alapjáraton. (Tehát ha pl nem 10+ program telepítése fut éppen)

Köszi a válaszokat :) (Közbe googlizok egy sort, tényleg érdekelne a dolog)

Mihez képest vizsgálnád? Azért ne felejtsd el, hogy a registry minden műveletnél több mindent csinál, mint egyszerű lookup (akár memória, akár disk) pl. szórakozik az ACL-ekkel, átmegy kompatibilitási rétegeken a registry virtualizáció miatt stb.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Be tudod vele lőni azt, hogy system-wide _értéket_, bizonyos csoportok szerkeszthessenek? Ez azért a unix acl-ekkel/tool-okkal nagyjából azt kéne, hogy jelentse, hogy vagy külön tool, ami megcsinálja a jogosultság-ellenőrzést (mint pl. a sudo/sudoers), vagy értékenként külön fájl.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

>1 felhasználónál, ha le akarod korlátozni, hogy mihez férhet hozzá, de valamihez mégis jogot kell neki adni.

Win-es példa: azt, hogy melyik user lépett be utoljára a HKLM-ben tárolja, ahova mezei userek nem írhatnak - viszont nekem kellett az, hogy néhány (mezei) usernek megengedhessem, hogy felülcsapják az utoljára belépett user nevét, hogy a következő login promptnál helyes usert kapjanak; ACL átállít (ráadásul csoportházirendből... tényleg marha kényelmes a registry ;) ) és problem solved.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hat most ennek a Mac-es alternativajanak utana kene neznem, de jo eselyt latok ra, hogy van erre megoldas.

(Meg valahogy eleve idegen gondolat szamomra Mac-eken hotel rendszerben dolgoztatni usereket, ott altalaban mindenkinek "megvan a maga sajat Mac-je", legalabbis azokbol a peldakbol, amit lattam).

De ha in-house is kene ezt megoldani, jo nagy cegnek kell lennie ahhoz, hogy ez komoly gondot okozzon. Akkora cegnel meg van penz ilyesmit kifejleszteni, ami a megfelelo rendszerkonfigokba ir (abban sem vagyok hirtelen biztos hogy ez plist-ben tarolodik, nem tudok ezzel a ponttal vitatkozni ebben a formaban, vagy van megoldas, vagy nincs, es vagy egyszerubb/optimalisabb a megoldas, vagy nem).

Biztos, hogy nem jó az úgy, ahogy van, elvégre egy sok éves megoldásról van szó és mindig minden implementációt lehet jobbá tenni.

Viszont ha az az elméleti kérdés merülne fel, hogy melyiket lehet a másikhoz képest gyorsabbá tenni, az OSX új .plist formátumát, amelyik mindenféle random XML fileok feldolgozását jelenti (XML, amelyik szerintem se nem human-readable, se nem machine-readable), vagy egy célirányosan a feladatra tervezett, binárisan kódolt kulcs-érték alapú adatbázist, akkor az utóbbira voksolnék...

Persze tagadhatatlan, hogy a registry szekvenciális keresésnél lassú, nem véletlen adott ki a Symantec anno olyan Norton (SystemWorks) Registry Editor segédeszközt, amelyik erre volt optimalizálva. Viszont aki debuggolt már Windows alatt registryvel kapcsolatos problémákat, az láthatta, hogy akár egy másodperc alatt milyen sok registry művelet tud történni a háttérben és mégis elég jól skálázódik, úgyhogy nem a sebességével és a válaszidejével van baj.

Szóval ha igaz lenne az, hogy random XML fileokat gyorsabban lehet parseolni, mint egy binárisan indexelt adatbázist, akkor az összes DB megoldást dobhatnánk a kukába, hisz feleslegessé válnának... Ezen érdemes szerintem elgondolkozni.

Nem arrol van itt szo, hogy "dobjunk ki minden db megoldast a picsaba", hanem arrol, hogy sok kis fuggetlen "db" (oke, az nem db) vs 1 nagy db.

Amit a registry megnyer azon, hogy binarisan tarolja az adatot vs xml parse, azt elvesztheti azon, hogy minden alkalmazas obelole akar valamit kiolvasni mikozben irni is, mig az alapesetben lassabb xml-es plistet 1-2 process pingelgeti per (cache-elt) fajl. Minden mas esetben azt latom, hogy akkor hasznalnak DB megoldast, amikor mar elkerulhetetlen, hogy sokmindenki minden adatot lasson (pl. szerver oldalon RDBMS-ek), de mindenki azert torekszik arra, hogy a kulon egymastol fuggetlen adatbazisok kulonallok legyenek (tudom, tudom, tobb tera vs "parszaz mega", de akkor is). Registry-nel ott kezdodik a baj, hogy legutobb mikor neztem, a Windows-ra irt programok jelentos resze is olvasgatott belole es irt is bele boven. Olyanok, amiknek a beallitasait semmi mas nem fogja hasznalni. (De mint fentebb emlitettem, nem a Windows hibaja, hogy igy irnak ra programokat idonkent).

De ettol fugggetlenul tenyleg elgondolkodtato amit irsz. Viszont az is, hogy miert a Symantec-nek kellett kiadnia egy toolt, ami arra volt jo, hogy megoldotta, amit a Microsoft evtizedekig nem tudott hazon belul. Foleg, hogy mint irtad "mindig minden implementációt lehet jobbá tenni", nos, nem ugy tunik, hogy az MS-nek erre barmikor is tul nagy igenye volt. Meg ugy elso ranezesre is nekem a registry tipikusan annak a kodnak tunik a Windows-ban, amit egyszer valaki osszerakott, azt hitte majd 4-5 Windows komponens fog bele irni, es o maga se gondolta volna, nem is ugy tervezte, hogy majd ekkorara novi ki magat.

Szerk.: egyebkent a plist "nem csak egy sima XML", "egyenesen parse-olhato" az Objective-C NSArray es NSDictionary adatszerkezeteibe, de ettol meg termeszetesen meretben ott van az XML overheadje.

De meg mindig nem irtad meg, hogy miert jobb az, hogy 1-2 fajlt megnyiszt, vegigolvasod az *egeszet*, beparseolod egy NSDictionarybe es abbol mazsolazgatod ki az adatokat, (kozben frissited a last access timet, stb., ami megint plusz io) azzal szemben, hogy van egy kozponti DB, ami valoszinuleg eleg pici ahhoz, hogy igy is ugy is bekeruljon a memoriaba es binarisan olvashato. Es mint mondom, memoriabol parhuzamosan olvasni statikus adatot egyaltalan nem problema, semmifele technikai akadalya nincs. Irasra szinten vannak lock-free megoldasok, ha nem lennenek, az RDBMS-ek is sulyos gondokkal kuzenenek a megbizhatosag teren. Registryvel leginkabb az egyetlen problema az, hogy nem az alkalmazas mellett van a beallitasa, illetve nem jon letre egy alkalmazas szintu helyi tarolo, amibe csak az adott alkalmazas ir es ami konnyen mozdithato az alkalmazassal egyutt (pl. HKCU-hoz hasonloan egy "current application", amely mindegyiknek a sajatja).

"Viszont az is, hogy miert a Symantec-nek kellett kiadnia egy toolt"

Nagyon egyszeru (szerintem): a Microsoft vagy nem erezte olyan hangsulyosnak a problemat, vagy piacot akart csinalni a 3rd party vendoroknak is, elvegre is a 3rd party fele is el kell tudni adni a Windowst, megpedig azzal, hogy ok mivel tudnak penzt csinalni. Symantec meg egy toolokbol elo ceg volt, neki kapora jott az, hogy keszitsen egy ilyet.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A kozponti DB-t is vissza kell vegul valahogy mindig irni diskre (mikozben masok hasznalgatjak). Es teny, hogy amugy sokkal kisebb, mint egy atlagos szerver oldali rdbms, kevesebb process is hasznalja, de meggyozodesem, hogy messze nem is annyira optimalis. 100x ekkora rdbms-t ledumpolok annyi ido alatt, amennyi ido alatt a resitry-ben megtalalok egy erteket szekvencialisan olvasva. Oke, hogy "nem erre van optimalizalva", de az a parszaz mega nem annyira big data, hogy ennyire ne menjen ez nekik. Szoval ez a tipikus "not by this margin" esete.

Mellesleg operacios rendszer feature-rol beszelunk. Ezek azok a feature-ok, amiket olyan surun hasznalunk, hogy inkabb megirjuk C-ben, meg ha eleve tovabb is tart, meg 10x annyit is kell figyelni arra, hogy pl. biztonsagos maradjon, mindezt egy minimalis sebessegnovekedesert. Ennel a feature-nel mondod azt, hogy "tok normalis, hogy kivarjuk mig 4 olvasas es ket iras befejzodik mielott mi odairhatnank". Az rdbms-hez valo csatlakozasod szerver oldalon az meg mar egy erosen user space valami, ott mar nem az oprendszered sokmilliard usere erez lassulast amiatt, hogy nem lett optimalis egy update query-d. De valahogy megis ez utobbi bizonyul lenyegesen gyorsabbnak. Mindemellett nem veletlen szokas az is, hogy az rdbms-nek van egy kulon dedikalt eroforraskeszlete (alapesetben hardvere). Mert ami ezt a lockolgatos irogatast szamolgatja, az ne szamoljon mast. Mert hat ahogy irtad: megoldott. De ennek a megoldasnak azert ara van a hardver kihasznaltsagaban.

Visszairas: Write ahead log. Irod a fajl (logikai) vegere a valtozasokat, majd ha a sikerult leirni rendesen, akkor allitod at a mutatot arra, hogy az uj lapra mutasson. (RDBMS-ek rendszerint lapokban dolgoznak, az a legkisebb egyseg amit hajlando irni/olvasni.) Nagy vonalakban ez az elve az osszes journaling megoldasnak, ami pont arra szolgal, hogy egyreszt biztonsagosan meglegyenek az adataid (aramszunet, fagyas, stb. beleertve), masreszt atomi muveletkent kezelodjon. Szoval nyitott kapukat dongetsz.

De ugyanez igaz a plistre: ott sem az eredeti fajlt irod felul, hanem egy uj, ideiglenees fajlba kezded el kiirni a modositasokat, majd fogod es lecsereled az eredeti fajlt. Nem veletlen, hogy a Windows nyujt erre fuggvenyt (WinAPI es .NET egyarant), holott igazabol egy-ketto rename es egy delete lenne ossz-vissz.

Masreszt jo esellyel biztos lehetsz abban, hogy a registry C-ben (esetleg C++-ban) van megirva. Azt sajnos nem tudom, hogy kernel vagy userspace, sajnos nincs keznel Windows Internals, hogy megnezhessem. De ha tippelnem kellene userspace, elvegre tobb keres jon a registrybol az userspace felol, mint kernelspace felol.

Egy RDBMS eseten is rengeteg kernel space kod mozog: halozat, io, processek kozti valtas, stb. Megjegyzem, idekeverni az RDBMS-eket megint csusztatas, masra van optimalizalva. Ha azokat is elkezdened key-value storagenak hasznalni, az se lenne olyan gyors, sot, merem allitani, hogy joval lassabb, mint a registry. Akar egy sqlite, ami kb. parba allithato lenne egy osszehasonlitashoz.

RDBMS-eknek meg egesz mas celbol van dedikalt eroforras-keszlete. Masreszt ismetelten irom: nem kell lockolni az irashoz. Nem tudom, hogy honnan szedted, hogy barmi ilyenhez kell lockolas.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ráadásul nem is csak KV-pair, de ez faszerkezetben, ami szintén tud problémás lenni rdbms-ben (lásd még az összes "kerülő" megoldás, nested set, rdbms-specifikus implementációk etc)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Persze, ezt mar tobbszor elmondtam, hogy egesz masra van a ketto.

Viszont, a fa strukturat az eleresi utvonalaknak koszonhetoen barmikor kisimithatod (ahogy teszi is pl. a .reg fajl.)

Egyebkent errol jut eszembe, HHVM-nel tok jo volt, hogy megleptek azt, hogy volt egy strukturalt konfig fajl, erre az okosok kitalaltak, hogy terjenek vissza a php.ini-hez. Na most, mikor utoljara neztem, az gyakorlatilag abbol allt, hogy a strukturakat kisimitottak egy x.y.z = asdf formaba, ami se nem volt kompatibilis a regi PHP.ini-vel, nem volt strukturalt es meg tobbet is kellett hozza gepelni...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azt nem értem, miért beszéltek itt RDBMS-ről? Nem tudom a registry hogy van megírva, de a felhasználást tekintve soha nem volt szűk keresztmetszet, mert lényegében
konfig fileokat tartalmaz egységes interface-en, amiket meg az alkalmazások 99%-a induláskor egyszer felolvas, és nagyon-nagyon ritkán esetleg ír. Ráadásul a key
struktúra miatt inkább egy key alapú adatbázis lehet, mint a mongodb és a társai, ráadásul még bonyolult lekérdezéseket sem kell támogatni.

Nekem annyiban tetszik ez a koncepció, hogy nem kell keresgélni, hogy egy adott alkalmazás a könyvtárszerkezetben mégis hova a csodába pakolgatja a konfig file-jait.

Régebben az különösen jellemző probléma volt, hogy egyes programok túl nagyon gyakorisággal olvastak értékeket a registryből, vagy írtak bele. Ezekről egyébként épp Russinovich tartott előadást akkoriban (akkor még nem a Microsoftnál dolgozott) és David Solomon. Voltam én is egy ilyen konferencián, ahol ezeket mutatták be (ők írták egyébként a Windows Internals könyvet, szóval elég jól értenek a témához). Amire konkrétan emlékszem az a Realtek hangkártya driverhez csomagolt hangerőszabályzós alkalmazás volt, amelyik ült a tálcán és a háttérben folyamatosan, nagy sebességgel pollozta az egyik registry kulcsot, hogy változott-e. Az ilyen megoldások nem túl egészségesek, ez tény, de az MS nem véletlenül tart állandóan ilyen fejlesztői és üzemeltetői konferenciákat, hogy felhívja a helyes és helytelen implementációkra a figyelmet. De ahogy PaX Úr szokta mondani, ez nem feltétlenül segít abban, hogy a fejlesztők ennél is "kreatívabbak" legyenek...

A Symantec meg nyilván azért adott ki szekvenciális keresésben is gyors registry editort, mert ők a fejlesztők és a pro userek számára készítettek eszközöket (az egész Norton Utilities és SystemWorks erről szólt akkoriban, most már ezek sem kaphatók). Nem hiszem, hogy a Microsoftnak egyébként ne lett volna házon belül már erre kész megoldása. Egyszerűen csak úgy ítélték meg, hogy az ilyeneket nem csomagolják a Windows mellé, mert az átlag felhasználók úgy sem tudnak vele mit kezdeni és nem is kell érteniük ahhoz, hogy hogyan működik a rendszer. Ez napjainkban is így van. A Russinovich sysinternals cuccai is csak külön tölthetők le az MS weboldaláról, pedig elég nagy jóság, ha az ember rendszerközeli dolgokkal szeretne foglalkozni Windows alatt (egyébként ha jól emlékszem, akkor Ubuntu sem telepíti alapból pl. az strace és lsof programokat...).

Nem hiszem egyébként, hogy a registry csak 4-5 Windows komponens számára lett volna tervezve. Jól mutatja a struktúrája, hogy mennyivel nagyobb volumenben gondolkoztak (Local Machine vs. Remote Registry, CurrentVersion, CurrentControlSet, egyedi SIDek, stb.). Ettől még persze lehet nem szeretni. Én is jobban kedvelem a registryben saját adatokat nem tároló portable programokat.

"Jól mutatja a struktúrája, hogy mennyivel nagyobb volumenben gondolkoztak (Local Machine vs. Remote Registry, CurrentVersion, CurrentControlSet, egyedi SIDek, stb.)"

Ezek mind ott voltak a kezdetektol, vagy egyszer csak lattak, hogy most mar muszaj ilyenre megcsinalni?

"Ettől még persze lehet nem szeretni. Én is jobban kedvelem a registryben saját adatokat nem tároló portable programokat."

+1, es ennel kozelebb szerintem nem fog erni a velemenyunk egymasehoz ebben

Windows 3.1 tartalmazott már REG.DAT filet, amelyik a registrynek lehetett az előfutára, de akkoriban pont az OS X .plist-hez hasonló módon, alkalmazásonként külön INI fileokban tárolták a beállításokat, amik viszont problémát jelentettek, ha egyszerre két példányban futott egy alkalmazás és mindkettő ugyanakkor szerette volna írni az INI filet. Az ilyen versenyhelyzetek elkerülésére is kezdték el bevezetni a registyt és a Win95 megjelenésekor már annak használata volt a fő irány. Akkor már ez a struktúra volt biztosan, viszont nem tartalmazott jogosultságkezelést, az csak az NT vonallal került bele, ahogy a remote registy menendzselhetőség is.

Memoriaba írást a létező legegyszerűbb muvelet atomi szinten megoldani, egyreszt, mert sok a 1-2-4 byte hosszu ertek, a hosszabbakat meg egy pointer cserével atomizalni lehet. Írásra meg mar regota ismert tobb módszer, hogy hogyan lehessen tranzakciozni a műveleteket.

Párhuzamos olvasás is meglehetősen triviális, masreszt nem hiszem, hogy a registry ugyanannak a reszet irjak párhuzamosan.

Fileio-nal meg a sok kis különálló fájlt emlitettem. Amugy kivancsi lennek, hogy mi a hatékonyabb, egy tetszőleges hosszúságú plusz fájlban egy ertek átírása (mondjuk egy true-rol valamit falsera), amihez ujra kellhet irni az egesz fájlt (es ügye ezt is tranzakciozni kell), vagy mondjuk egy db-ben 1..4 bytet módosítani, amit atomi lépésként le lehet tudni.

Tobbire nem reagalnek, mert egy hosszu linkgyujtemeny lenne az érvelési hibas oldalrol. Az meg érdektelen, hogy mi mennyi C kódot tartalmaz, hogy ha az adott reszfeladatra jo. Ld. Singularity, ahol az os bootolasahoz kellett egy minimal ASM es C.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Memoriaba írást..."

Ami a vegen diszkre is ra kell, hogy keruljon megfeleloen utemezve, mikozben irogatnak bele tobben is, igen?

"egy tetszőleges hosszúságú plusz fájlban egy ertek átírása (mondjuk egy true-rol valamit falsera)"

Ha mar annyira jottetek ezzel a szekvencialis olvasassal, mondok inkabb egy ilyet: INSERT, vagy valtoztassunk meg egy wordot dword-re es ugy irjuk at az erteket (oke, tudom, ugy is "egyszeru", de a plist atiras vagy ahhoz addolas mindenkeppen egyszerubb).

(Es annak a "sok kicsi" plist file-nak a szamossaga annyira nem sok, bar alairom, hogy ha benchmarkig eszkalalodik ez a vita, igazsagosabb volna nem SSD-n, hanem HDD-n tesztelni.)

A kivitelezés lehet, hogy rossz, de azt el kell ismerni, hogy "azok" megcsinálták az egységes, központilag, egységes eszközökkel (regedittől a policy-ig) menedzselhető konfigurációt - amit aztán az alkalmazásfejlesztők többnyire rosszul használtak, ez tény.

Szerintem az idealis az lenne, mint amilyen a linuxon van (~/.config/alkalmazas), *ES* egyebkent lenne meg egy adatbazis a hatterben *IS*, ami ugy mukodne mint egy kvazi cache.
Az alkalmazasok (ha akarjak) az adatbazist nyaggatjak, az emberfia meg a konfigfajlt irogatja, es az adatbazis mindig szinkronban lenne a fajlokkal.

Pont ugy mint, amilyen a linuxnak a /proc fajlrendszere. Az egy zsenialis dolog. Hirtelen nem jut eszembe, hoyg windows alatt van-e ilyen... :-D

Persze ott van a gnomenak a sajat windows registry koppintasa. Ott szerintem ami szar volt azt szerintem sikerult lemasolniuk. Teljesen hasznalhatatlan es hasznavehetetlen...

Megj2:
A windows registryje az olyan amit az emebr meg bottal se szivesen piszkal...

Megj3:
A konfigfajlok tipikusan az a terulet ahol sebessegoptimalizalni kell... LoL

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Szerintem az idealis az lenne, mint amilyen a linuxon van (~/.config/alkalmazas)"

Es hany, de hany alkalmazast nem lehet igy konfigolni, sot, /etc-bol sem....Ez csak egy konvencio, amit vagy betartasz, vagy nem.
Ugyanugy, Windows alatt a rendszer biztosit az alkalmazasok szamara egyseges konfiguracios keretrendszert, de ezt az appok vagy leszarjak, vagy nem. De ha leszarjak, azert a Windows a hibas, persze.....#openszorszkettosmerce

"De ha leszarjak, azert a Windows a hibas, persze.....#openszorszkettosmerce"

Hazi feladat: szamold meg hanyszor hangzott el ebben a topikban a "nem a Windows hibaja" kefejezes. Csak en ketszer emeltem ki hogy nem a Windows hibaja hogy igy irnak ra alkalmazasokat, mikozben amugy a registry ellen erveltem.

Par oraja meg kicsit aggresszivabban akartam erre a kommentedre emiatt reagalni, de aztan lattam, hogy a Som-som felek tenyleg elszalltak egy kicsit, es maradt egy olyan remenyem, hogy rajuk gondolhattal es nem ram "kettos merce" cimszo alatt.

Lasd meg: "Uzenetem a Microsoft-nak es a Canonicalnak" a secure bootos topikban, ott se volt kettos mercem.

>> Szerintem az idealis az lenne, mint amilyen a linuxon van (~/.config/alkalmazas), *ES* egyebkent lenne meg egy adatbazis a hatterben *IS*, ami ugy mukodne mint egy kvazi cache.
>> Az alkalmazasok (ha akarjak) az adatbazist nyaggatjak, az emberfia meg a konfigfajlt irogatja, es az adatbazis mindig szinkronban lenne a fajlokkal.

Ehhez annyi config filera lenne szükség, ahány beállítási paramétere (értékpárja) van az adott alkalmazásnak. Ez egy komolyabb programnál több száz is lehet, az operációs rendszer beállításaira levetítve meg sokezer...

Az adatbazisbol a kulcs a programneve lenne az ertek pedig a program konfigfajlja.
Szerintem folosleges a konfigfajlt szetbanyaszni es azokat is kulon feltenni.

Ennek az egesznek osszesen 2 dolog miatt lenne ertelme:
1. gyorsabb(cache) -- szerintem a konfigfajlok olvasasa pont nem az a terulet ahova kell a sebessegoptimalizalas, dehat az ms csak tudja mit csinal:)
2. kozpontilag (programbol) elerheto minden alkalmazas konfigfajlja.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"szerintem a konfigfajlok olvasasa pont nem az a terulet ahova kell a sebessegoptimalizalas"

Hogy könnyebb legyen átlátni, miről beszélünk, csináltam egy kis iránymutató mérést Process Monitorral.
"Nyugalomban lévő" számítógépemen, 30s mérési idő átlagában, átlag 3200 registry művelet van másodpercenként.

Üdv,
Marci

Ha kell egy rendszeren NoSQL alkalmazas, akkor legyen. De miert is pont a kozponti konfiguracios allomanyok kiszolgalojat kell abuse-olni?

Van am millioszor jobb NoSQL, mint a windows registry.
Ott a mongodb, a redis, a Couchdb an Couchbase es meg sorolhatnam.
Vannak grafadatbazisok(Neo4j) is, ami egy picivel masabb csak.

Egyebkent akkor rakjunk SQL adatbazist is a registrybe, mert van jopar alkalmazas ami SQlite-tal jon.
Mekkora konnyebbseg lenne, ha azt is tudna a Windows registry. Ja varj, arra mar van fizetos termeke az MS-nek (MSAccess, MSSQL), akkor megse. Vegyek azt a jonepek.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> Van am millioszor jobb NoSQL, mint a windows registry.

Ez oké, de registry már jó pár évvel azelőtt volt, mint a felsorolt NoSQL megoldások. Persze, ki lehetne váltani, csak kettő probléma van vele:
1) felesleges bloatware lenne egy off-the-shelf nosql adatbáziskezelőt beépíteni
2) hogy oldod meg, hogy ne kelljen újraírni az összes meglévő alkalmazást?

> fizetos termeke az MS-nek (MSAccess, MSSQL)

Amennyi adatot tárol a registry, arra még az MS SQL is ingyenes. :)

> 3200 registry művelet van másodpercenként.

Ezt en, mint negativum latom.

Kozben en is csinaltam egy tesztet erre linuxon:
inotifywait -r -m $HOME/.config

Pontosan 0/masodperc ha nem inditok programot.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem nem túl logikus a 60-as éveket emlegetni a mai Linux kapcsán. Ahogy a Win10 nem Win 1.0, a legújabb Ford nem T-modell, az ember nem azonos az első emlősökkel.

Az sh-t emlegetni is annyira logikus, mint a mai Win szemére hányni a cmd.exe-t. Van más script nyelv is unixokra.

Ha a Unix/Linux rendszerek rosszak lennének, nem használnák. Márpedig messze a világ legelterjedtebb rendszerei, egyre népszerűbbek. Ennyire hülye lenne a szakma?

Valamelyik egykori Unix fejlesztit megkerdeztek, hogy miert nem váltja le a Plan9 az Unixot. A valasz az volt, hogy mert nem eleg rossz.

Az egesz IT-t végigkíséri a "nem eleg rossz" mentalitás. Az rendben van, hogy nem dobalu,k ki mindent azonnal. De attól meg nem az lesz a jovo, ami a mult.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ahogy programozási nyelvből annyi van, mint égen a csillag, így OS-ből is van jó sok. Ha biztonság, sebesség, fejlesztési költség alapján lenne _valóban_ jobb, akkor az előnytelenebbek már kihaltak volna. Egyszerű survival of the fittest. Ha nem történt meg, akkor az épp elég bizonyíték arra, hogy _jelenleg_ nincs jobb. (Vagy még nem tudunk róla.)

Ez így elég vulgárdarwinista, nem?
Élőlényből is van egy csomó fajta, sőt növényevő mérsékeltövi párosujjú patás emlősből is, miért nem haltak még ki az előnytelenebbek? Több idejük lett volna rá, mint az OS-eknek...
"survival of the fittest" - pávát láttál már?

Üdv,
Marci

A hasonlat (pontosabban a kovetkeztetes) ott santit, hogy figyelmen kivul hagyod, hogy melyik eloleny hol el. Valoszinuleg nem egy itteni faj elpusztulna az eszaki/deli sarkon, szimplan azert, mert nem ahhoz a kornyezethez adaptalodott. Mareszt a tulelels tobbfelekepp is tortenhet: tortenhet adaptacioval es tortenhet azzal, hogy a kornyezetet probalod a magad igenyeihez alakitani. Utobbi pl. az ember muve.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"figyelmen kivul hagyod, hogy melyik eloleny hol el."

Már miért hagynám figyelmen kívül? Írtam valahol olyat, hogy csak 1 nyelv vagy OS létezik? Desktopon a Windows virul, telefonon a Linux, stb. Ráadásul hiába írsz egy u.a. jó Unix-szerű rendszert, mint a Linux, attól még nem fogja azonnal a Linux piac 50%-át átvenni. Ha meg jobbat írsz, az újdonságait valószínűleg a Linux átvenné. L. linuxos GUI-k OS X / Windows megoldások átvétele (picit hasonlóan a növények hagyományos nemesítéséhez).

"a tulelels tobbfelekepp is tortenhet: tortenhet adaptacioval"

Igen. Pl. a Unix/Linux világ ma nem az, mint fél évszázada. Pont ezt írtam. Pl. az Android telefonom sem épp egy 60-as évekbeki Unix.

Nem látom, hogy bármi ellentmondás lenne a kettőnk nézőpontja között.

"Jól értem: a Windows desktopon virulva haláltusáját vívja?"

Igen, jól érted. A desktop jelentősége csökken, ráadásul amit a Win7 nyújt, azt pl. Linux Mint formájában ingyen is megkapod. Ezért menekül előre (=dinamikusan fejlődik) a Win. A Win8 egy zsákutca, a Win10 (technikai és üzleti változtatásokkal) bejöhet.

Lehetséges. Mindenesetre eddigi hozzászólásaid alapján nem úgy tűnt nekem, hogy akadályozna Téged az időbeli távolság hiánya a megítélésben... :)
Bár az még érdekelne, hogy ha Szerinted a Windows 10 még bejöhet miközben a Windows a haláltusáját vívja, remény-e ez a halál utáni életre? :)

(csak viccelődés, no offense!)

Üdv,
Marci

"eddigi hozzászólásaid alapján nem úgy tűnt nekem, hogy akadályozna Téged az időbeli távolság hiánya a megítélésben"

Igen, de jelenleg szervizben van az időgépem.

"Szerinted a Windows 10 még bejöhet miközben a Windows a haláltusáját vívja"

Krízishelyzetben szokott az evolúció felpörögni. Pl. a Nokia Mobile Phones 2011-2012-ben omlott össze, miközben 2011 legjobb mobilja a Nokia N9 volt (a ki sem adott N950 mellett) és másik oldalon a Symbian is durván felpörgött. A Win-t és a Symbian-t is piacvezető helyzetben érte a krízis, de a Win-t lehet, hogy időben fogták még meg, másképp mondva, a változás elszenvedője helyett a változás motorjaként próbálják pozicionálni. (Ez persze blöff, de a túléléshez elég lehet, mert az Androiddal ellentétben a desktop Linux nem olyan jó.)

Pedig igaza van.
Az alkalmazasok koltoznek be bongeszomotor ala.

Nehol meg kivetnivalot se lehet talalni,
vagy szerinted egy Windows Wordben kikuldott kerdoiv jobb megoldas,
mint mondjuk egy surveymonkey-os weblap?

Ez egy baromira egyertelmu folyamat. Vagy nem tudom, te milyen fuggony mogul nezed a vilagot...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Az alkalmazasok koltoznek be bongeszomotor ala."
Igaz, olyanok is vannak. Meg olyanok is, amik böngészőmotor alól natív app-ba vándorolnak. Mennyiségi statisztikám nincs.

"vagy szerinted egy Windows Wordben kikuldott kerdoiv jobb megoldas,
mint mondjuk egy surveymonkey-os weblap?"
Az attól függ. Például, hogy van-e hálózati kapcsolat ott, ahol használni akarom.

"Ez egy baromira egyertelmu folyamat. Vagy nem tudom, te milyen fuggony mogul nezed a vilagot..."
Nem tudom. Milyen függöny mögül nézem a világot?

Kétségtelenül, a vékony klienses és böngészőalapú megoldások elterjedőben vannak:

"WINTEL'S DISCONTENT? What of the old model? In the face of the Web--a truly universal standard--the prevailing Wintel standard doesn't look so unshakable. And the huge profits that Microsoft and Intel get by setting the standards don't look so safe. Since September, the hardware business has been buzzing about low-cost ``Internet appliances'' that will challenge Intel PCs."
(BusinessWeek, 1995. december)

A terjedés üteme azért mégsem az, amit 20 éve (!) gondoltak erről, többen.
Például a vékonykliens hardverek részesedése, ha jól tudom, nem nőtt szignifikánsan sok év alatt sem.
A webes alkalmazások terén pedig már az n+1. módszernél járunk, hogy létrejöjjön az az új, OS-független és böngészőfüggetlen "platform", ami a natív alkalmazásokkal megegyező teljesítményt és produktivitást nyújt gyakorlatilag minden helyzetben.

Üdv,
Marci

"..pedig már az n+1. módszernél járunk..."

És ez meg is volt és lesz is mindig. Ugyanis amint egy egységes irányt venne fel egy piacvezető, addig az ő piaci részesedésére törő új versenyző ki akarja ütni a helyéről, és épp az addigi tendenciák megváltoztatásával, egy új irány létrehozásával akarja / tudja ezt elérni nagyon sok esetben.

Kicsit offtopic leszek, de megnéztem a surveymonkey-s cuccot. Hogy ez a weboldal is egy mekkora bloat okádék - már elnézést :) Sajnos annyi a felesleges sallang mindenütt és mindenhol - nem kapod azonnal a lényegi infót - én ezt a tendenciát sajnálom csak.

Amúgy tudom hogy csak példának hoztad, de kiváncsi voltam az oldalra.

( palmaci | 2015. 04. 04., szo – 01:33 )

Na most, a windows eseteben 80-as 90-es evek technologiarol beszelgetunk. De sajnos ez nem igaz. Mivel a Windows 1,2,3,9x sorozat a DOS-ra epult. De ez mara ki is halt.

Az egyetlen rendszer amit az alapoktol 80 evekben terveztek a OS/2 volt. De ez is kihalt.

Az NT is vonal meg nem a semmibol lett kitalalva, hanem VMS hazassaga a OS/2-vel es a DOS-os Win-nel. Az NT tervezo es fejleszto mernok anno a VMS szuloatja. (DOS kernel kuka, helyette a VMS hibrid kernel, modositott HPFS as NTFS, es GUI-nak a Windows) Az otletek es a felepites pl a KERNEL szintek, de meg a pagefile.sys is a VMS oroksege. Az NTFS meg a HPFS kicsit modositott verzioja volt. De hat VMS-t is 1977 adtaki a Unix meg 1971. Szoval massszivan funky time.

Azert durva, hogy UNIX tobbmint 40 eves technologia, de ki kell mondani nem tudtak meg jobbat kitalalni. Mert az is teny a Windows is egyre jobban kacsingat vissza unix-os dolgokhoz. pl mennyi uj parancssori eszkoz van. Winsrv Core. Amugy a winnek nagyon sokat segiteni, ha a teljes magaban hurcolt DOS-os es win16 mocskot kidobnak belole.

A DOS/16 bit vonal az NT alapú Windows-okban mindig is egy külön, a rendszer alapjaitól független kiegészítő volt.

http://en.wikipedia.org/wiki/Virtual_DOS_machine
http://en.wikipedia.org/wiki/Windows_on_Windows

Ez olyannyira igaz, hogy a 64 bites Windows-okban soha nem is volt benne, szóval itt már teljesült is a kívánságod :)

akkor vajon miért használja még mindig a 1979-es 86-dos rendszerbetöltési struktúráját a windows, meg a veszélyesen ostoba futási szinteket, meg a végtelenül ostoba tervezést, - ez valószínüleg nemzetbiztonsági szempont - másról még nem is beszéltem :))

attól hogy átnevezzük a rendszert, meg a filekokat, még nem lesz egy másik rendszer, ráadásul olvastam feljebb, hogy a unix/unix like/... milyen elavult, amiben egyébként van valami...

de ettől még nagyon jót röhögtem!

( hokuszpk | 2015. 04. 04., szo – 07:51 )

minden tiszteletem Russinovich ure, de valaki keresse meg es adja vissza neki a gyogyszeresdobozt, vagy csak egyszeruen ebressze fel.