HH kezdessz elmenni kicsit anti-MS modba. Bizalmi index? A bizalmi index kb annyira ertelmes, mint a szavazas alapu sakkozas.

Kezdem azt érezni, hogy manapság jobban jár az aki két gépet tart fent. Egyet netre a másikat meg a tübbi stuffra. Lehet para vagyok de nekem egyre inkább az az érzésem, hogy figyel a big brother.
Borzasztó érzés

talán azért nincs belőle akkora botrány, mert vannak akik megértik és nem csak ms utálattól elködösült szemmel vizsgálják a dolgot.

annyi történik csak, h az update saját magát frissíti. ennyi.

már az eredeti blog bejegyzésben is tiszta képzavar, h a kompatibilitásról dumál a csávó.

Nem lehet, hogy amikor elfogadja az ember telepítéskor a szerződést (aminek feltűnését általában mindenki olvasás helyett a tovább gombbal szokott lereagálni), az tartalmaz erre vonatkozó engedélyt is?

Nem hiszem, ugyanis nekem valamiert ha frissit a winupdate, akkor meghal a gepem, ezert is kellett kikapcsoljam az automata frissitest. Ha meg a gepem meghalna 1-2-3 percre akkor azt azert eszrevennem.

a régi pentium3-as gépemen detto lehal a win ha az auto frissítés be van kapcsolva. ha manuálisan frissítek, akkor mást nem futtathatok közben, mert tuti nem sikerül a frissítés és 100% megeszi a gépet a telepítőkkel :D vicc.

ha jól sejtem, úgy kéne ennek működni, h van a védett rendszer partíció ami az eredeti eszközszállítóé, azaz az oem-é, a maradék lemezterületen meg van egy public és egy private mappa. persze én nem olvastam el a ms eula-t.

norti,
az egész windows egy vicc, csak sajnos ez az összes operációs rendszerre igaz.

a helyzet az, h nem nagyon sikerült megtalálni azt az infrastruktúrát, vagy architektúrát, amelyben a felhasználók képesek lennének felügyelni a saját számítógépük működését.

de erről nem az ms tehet, hanem a rendszerprogramozásban uralkodó rétegszemlélet. amit az oprendszer írásakor el kellene felejteni.

a felhasználók többsége ugyanis nem képes átlátni semmiféle multilevel megoldást, így nem tud mit kezdeni a hierchikus fájlrendszerrel, de még a menürendszerrel sem, a preemptív ütemezéssel, de még a fájlok kiterjesztével sem, azaz gyakorlatilag képtelen felügyelni a számítógép működését.

egyesek ezt úgy szokták összefoglalni, h a felhasználók többsége hülye, persze inkább arról van szó, h a programozók eszköztára nem elég kifinomult ahhoz, h figyelembe vegyék a felhasználók lelkivilágát. de ez egy nagyon messzire vezető téma.

Van olyan gépem, amin megy a frissítés, és olyan is van, amin nem. Azon kívül, hogy 3-400 megát foglal (meg időnként némi sávszélességet), nem látok különbséget. Lehet, hogy nincs is szükség a frissítésekre?

Ennyi:

winportal.net/?id=1123

Biztos bennem van a hiba, de egyáltalán nem tartom gáznak. Csak azokban a módokban frissít, amikor legalább a kommunikációt engedélyezted, a teljes offnál nem csinálja az inkriminált frissítést. Amit frissít, az a kommunikációs layer, ha úgy tetszik, de éppen te kérted, hogy szóljon.

Pedig imádom utálni a microsoftot.

Nem tudom, fura, ahogy itt néhányan cukrozzák a taknyot. Ha én egyszer kinyilvánatottam, hogy nem akarom, hogy a gépemen változtatást hajtsanak végre (Letiltottam az update-t) akkor mind jogi élrelembe, mind erkölicsleg aggályos a dolog (Aggályos? Enyhe kifejezés. Talán inkább pofátlanság) Teljesen mindegy, mit hova csinált, ha egyetlen bitet is megváltoztatott, az gáz.

Hat ha kikapcsoltatok, aztan megis frissult, az gaz. Nem szep dolog a power user kezebol kivenni az eszkozoket. Hatha o tudja jobban, hogy mit akar.

kutacs_: a vege fele azert egy kicsit elszalad a lo :). Ki kell szolgalni a felhasznalot, persze (latszik is a valtozas a huzaldugdosastol a 3D desktopig), de a masik oldala a dolognak meg az, hogy a juzernek sem kene alvarnia, hogy tanulas nelkul ertse a gep (oprendszer, alkalmazasok) mukodeset. A bonyolult dolgok hatekony mukodtetesehez/hasznalatahoz bizony erteni kell oket, ahhoz meg valamilyen (!) formaban tanulni kell. Az autoval szeretnek szamitastechnika kapcsan peldalozni (nagysagrendekkel egyszerubb rendszer), es meg azt is tanulni kell. Meg a kozlekedest. Akkor ezen mi a meglepo? Ettol meg lehet, hogy a hierarchikus elrendesek nem jok (nagy mennyisegu adatnal tenyleg nem!), az ember nem tul jo a rendszerezesben, meg a vilag dolgai sem feltetlenul sorolhatok be ilyen rendszerekbe. Mindenki azt gondolta, hogy majd a jol kidolgozott ontologiakkal fogjuk rendszerezni a sok tudast, aztan lof@szt - a szakertok sem birjak elkesziteni oket, a cimkezes meg egeszen jol mukodik.

Nyilvan a vinyon is bizonyos adatokat cimkezve vagy (es) indexelve egyszerubb tarolni, de masoknak jo a hierarchia. Es egy egyszeru konyvtarszerkezetet illik megerteni es atlatni az atlagnal benabb juzernek is.

Olvassatok már utána, jézusom. Ha ki van kapcsolva az automatikus mentés (tehát a 4 opcióból a disabled van kiválasztva), akkor nem tölti le az itt említett csendes update-et sem. De persze egyszerűbb agyatlanul bégetni. Birkák.

a legidegesítőbb mikor már éjjel 3-kor mennél a francba aludni ez meg elkezdi hogy ne kapcsold ki

én meg sose hagyom úgy a gépemet hogy nem állt le

Én csak azt nem értem, hogy, ha a PiciPuha elő tud állítani olyan oprendszert, mint a 64bites Server 2003, akkor ugyanerre a kernelre építve, hogy a fenébe lessz akkora szemét, mint a viszta... Én amíg vindózt használtam, addig is elsősorban olyan verziókat preferáltam, amiknél a jogosultságkezelést kézben tudtam tartani (NT, Server 2000, 2003). Azért a jelen helyzetben tényleg nem az a gáz, hogy Billék javítják, amit elcsesztek, hanem az, hogy úgy nyúlnak bele a gépbe, hogy nem értesítik róla a júzert, tökmindegy, hogy milyen céllal teszik, vagy tényleg jobb lesz-e utána...

atleta,
csak arról beszéltem, h a rétegszemlélet a rendszerprogramozásban finoman szólva nem működik. lásd hálózati rétegek. először az volt, h elméletben kell 7 réteg. aztán azt mondták, h gyakorlatban elég 5, más helyeken meg az jött ki, h 3 réteg az ideális.

hagyjuk a felhasználókat. a helyzet az, h a fejlesztők többsége is legfeljebb 1 réteg működésével van tisztában. és ez nem azért van, mert mindenki hülye, hanem az van, h ezek a rendszerek bonyolultak, ezért nem vagyunk képesek minden részletét felfogni.

erre azt szokták mondani, h ez nem baj, hiszen senkinek nem kell a rendszer működését egészben látnia, elég ha egy részét megismeri. ez általában igaz, de a rendszerprogramozásban nem igaz.

a rétegszemlélet a rendszerprogramozásban szerintem korlátozottan alkalmazható. és itt is ez a probléma, h akkor most melyik réteg mit csinál. van a updater réteg, ami rá van húzva a rendszer egészére, és akkor most hol tudok, mit bekapcsolni.

a helyzet az, h teljesen fölösleges itt bármilyen wrapper, annyit kellene csinálni, h az oem jogosult az rendszermagot frissíteni, de köteles a felhasználói adatokat legalább logikailag, de inkább fizikailag elkülöníteni.

ha ezt a szokásos szemléletben közelítjük meg, akkor van a mag, rajta a héj, vagy burok, és akkor kell egy cső, amelyik belefúródik a magba. azaz nem egy köztes réteg kell ide, amelyik frissít, hanem egy cső, amelyik eléri a magot. és persze kell olyan cső is, amelyik meg éri el. ebből viszont sehogy sem jön ki a 7 réteg, de még 3 sem.

persze semmi újdonságot nem mondok én ezzel, ez a mag-héj-cső felfogás kernighan & ritchie-től jön, és gates-ék hozták be az api-t (alkalmazásprogramozásra és nem rendszerprogramozásra) azaz mondhatnám, h gates a hunyó, csak ugye éppen a unix és a c volt az, amelyik az egyszerű bemenet-kimenetet kivette a nyelvből (bejött a printf, scanf), azaz ezt a felfogást éppen ők szorították háttérbe. a linuxot meg hagyjuk, mert az meg már rég nem egyszerű kimenet-bemenet kapcsolatokra épül, hanem az api-ra.

persze nem azt állítom, h kernighan, ritchie, jobs, gates, torvalds hülyék lennének, mindössze arról van szó, h 20-30 évvel ezelőtt nem láttuk át, h milyen szemléletben kellene operációs rendszereket írni, és még ma sem látjuk igazán.

kutacs: Az a helyzet, hogy retegek nelkul megkevesbe lenne kepes barki is atlatni a rendszert. A retegek szerepe pont az atlathatosag novelese, a komplexitas csokkentese.

@kutacs_, a 7 réteg az referencia, azért van kitalálva szépen, különválogatva a funkciókat, hogy tudjunk beszélni a valóságról, ahol akárhány réteg van.

Szinbad,
a réteg felfogás egyfajta gondolkodás. arról szól, h nem kell a rendszert részleteiben ismerned, elég egy részt megismerni. ebben a felfogásban a rétegek egymásra épülnek, illetve lehetőség van egy rétegre több partíciót is építeni. ez gyakorlatilag egy hierarchiát eredményez, ahol minden elemnek meghatározott funkciója van.

ez a felfogás tökéletes ha egy önmagában álló célhardvert fejlesztünk, mert szisztematikusan lehet építkezni lentről felfelé, de fordítva is. előbb csak emuláljuk az alsóbb szintet, aztán megépítjük.

ugyanez a felfogás folyamatosan csődöt mond a hálózatokban. a hálózatok működése ugyanis egyszerű bemenet-kimenet kapcsolatokon alapul, ehhez alapvetően mellérendelő viszonyokban kell gondolkodni nem hiearchiában. azaz a szigorú alá-fölérendeltségi viszonyokat el kellene felejteni, ami a réteg felfogás lényege.

sztahanov,
mondjuk a rendszermag frissítése szerinted melyik réteg feladata az osi modellben.

nem akarok ezt ragozni, de amikor kernighan & ritchie a unixot kitalálták szó sem volt arról, h itt lesznek mindenféle api-k.

ők azt gondolták, h van a rendszermag (core), ezt körbeveszi egy héj vagy burok (shell) és vannak csővezetékek (pipe). ezek egy része áthatol a héjon eléri a magot (program), más részük csak a héjig jutnak el, ott működnek, azon futnak (script).

ez most a 70-es évek, szó nem esik a számítógépes hálózatokról, arról, h a gépeket össze kellene kapcsolni és a magoknak együtt kellene működni. k & r fogják és a rendszerprogramozásra szánt nyelvből, a c-ből kiveszik az egyszerű bemenetet-kimenetet. persze szükség van mondjuk a szabványos bemenetet olvasni és a kimenetre írni, ezért megszületik az első api: a printf, scanf. az i/o nem része többé nyelvnek, ami egy radikális szemlélet váltást eredeményez. aztán stroustrup első dolga, h visszateszi az i/o-t operátorokat a nyelvbe, de nem a hálózatokról szó nincs.

a komponens szemlélet erősödik meg, a következő generáció, jobs és gates ezt viszik tovább, és lesznek nagyon sikeresek. majd jön torvalds, és a többiek, ez a generció szakít az operációs rendszerek régi filozófiával, jön a gnu's not unix, ami egy csomó windows klónt eredményez linux márkanéven.

ekkor jön a tcp/ip. aminek a lényege az lenne, h kommunikációs protokollokat hozunk létre, és a számítógépek szabványos bemenet kimenet kapcsolatokon keresztül kommunikálnak egymással. a tcp/ip hálózatban elvileg nincs api. (gyakorlatilag van persze, de a protokollcsalád éppen az api kiváltását szolgálná) sokáig azt hitték, h a protokollok között valamiféle hierchiát kell kialakítani, lásd 7 rétegű modell, 5 rétegű modell, de egyre nyilvánvalóbb, h ebben a felfogásban ilyen hierarchiára nincsen szükség. sokkal inkább lazább gráfszerkezet a nyerő, azonban egyáltalán nem világos, h ennek a gráfnak mik a csomópontjai és mik az élei. még az sem világos, h élek irányítottak legyenek-e. azon a csővezetéken, ahol érkezik az update, egyirányban, vagy kétirányba haladjanak a bitek. a rendszerprogramozásban rengeteg a nyitott kérdés, szóval egyáltalán nem véletlen, h a google sem tud egy épkézláb oprendszert letenni az asztalra.

és persze a microsoft sem tud. azonban csak ebben a kérdésben van nagy egyetértés.

csomo windows klont eredmenyez linux markanaven??? Melyik alternativ vilagbol jottel? :)

De a lenyeg, hogy a redszerek sajatossaga a komplextias, sot van olyan, hogy minimalis komplexitas, ami ala nem lehet menni. Az emberi elme mar viszonylag egyszeru dolgokat sem kepes felfogni segitseg nelkul. A retegek ilyen segitsegek. Es nagyon talaltak meg ki jobbat. Nincs olyan, hogy mas paradigma majd megolja a gondokat, there is no silver bullet.

Szinbád,
miben is különbözik a windows és a linux. műszaki-technológia szempontból kérdezem, és nem üzletfilozófiai szempontból.

és akkor a kérdés ide is szól, a rendszermag frissítése melyik réteg feladata az osi modelledben.

kutacs: az osi modell-nek mi köze a kernelhez?

az osi modell állítólag a valóságot modellezi. itt egy valóságos hálózati probléma, h időnként frissíteni kell a rendszermagot. gondolom akkor jogos a kérdés az, h ebben a modellben ez melyik réteg feladata.

kutacs: ja már értem. Akkor elmondom, hogy az osi modell hálózati protokollok modellje, és csak zárójelben jegyzem meg, hogy teljesen tisztán még sosem lett megvalósítva, de nem ez a lényeg. Ha gondolod, kicsit bővebben is kifejthetem, de szerintem ennyiből is látszik, hogy a kérdés kissé értelmetlen.

a modell lényege, h segítse a gondolkodást. azaz ha felmerül egy probléma, akkor segítsen a megoldásban. na most a kérdés az, h az osi modell milyen hálózati problémára adott már választ.

kutacs:

1) Az osi modell nem a valóságot, hanem hálózati protokollokat ír le, 7 rétegben (zárójelben: amit soha nem valósítottak meg 100%-osan tisztán, ezért modell)

2) A kernel frissítése nem hálózati probléma.

3) A kérdés értelmetlen

ez komment motor utazik rám, nem látom a frissítéseket, bocs.

> osi modell milyen hálózati problémára adott már választ

minden réteg végzi a maga dolgát, gyakorlatilag minden rétegen oldanak meg egy egy önálló problémát, hogy csak kettőt említsek a sok közül:

1) címzés
2) visszaigazolás

címzés rétegenként lehet más kezdve a fizikaitól (pl ethernet), hálózati (pl IP) vagy alkalmazás címzés (pl DNS)

Az egészben az a lényeg, hogy minden réteg megold valamilyen problémát, és azt jól leírt módon teszi.

Az egész az összekapcsolódásról szól, mivel ez egy hálózati modell, és te egy web böngészővel más rétegen kapcsolódsz, mint mondjuk egy VPN-es vagy ethernet kapcsolaton keresztül.

bővebben:

hu.wikipedia.org/wiki/OSI_modell

Egyébként a unixos pipe-ok is API-k, szabványosított API-k. Továbbmegyek: az API-k pedig komminikációs prokollok, de nem hálózati protokollok, hanem szoftver komponensek (jelen esetben processzek) közötti protokollokat írnak le/szabványosítanak.

Szinbád,
"a kernel frissítése nem hálózati probléma". hát mi. itt arról van szó, h az osi azt mondja, a protokollokat egymásra kell építeni, és nem elég a logikai és a fizikai réteg, hanem kell 1 fizikai réteg és még arra 6 másik réteg. így kell kialakítani egy hálózatot. erre mondom azt, h ez egy hülyeség.

Kazi,
egy logikai-fizikai szétválasztásról beszélsz, amihez nem kell 7 réteg. a klasszikus unix felfogásban van a mag és van a héj. ott is megvalósítható ez a szétválasztás.

a unix azt mondja, h kell még a cső, ami arra szolgál, hogy ezeket a mag-héj csomópontokat össze lehessen kötni egymással. illetve a unix azt mondja, h a mag és a héj is tele van információs csomópontokkal és ezeket is csövekkel kell összekötni.

az osi modell azt mondja, h a magra újabb és újabb héjat kell felhúzni, ahhoz hogy kommunikálni tudjunk. most nem én vagyok az első aki azt mondja: na ne viccelj.

nem újabb héjak kellenek, hanem csövek. és ezeknek a csöveknek esetenként át kell hatolniuk a héjon, és és bele kell fúródniuk a magba. különben bizonyos problémákat nem tudunk megoldani, például nem tudunk rendszermagot frissíteni, és nem lesz biztonságos hálózatunk.

kutacs: az OSI modell hálózati prokollok modellje, nem szoftver komponensek modellje. A kettő messze nem ugyanaz.

> egy logikai-fizikai szétválasztásról beszélsz, amihez nem kell 7 réteg

Az OSI modell definiál 7 réteget, a jelzett linken tudsz tájékozódni.

oké, nekem az a véleményem, h az osi modellt követve nem fogunk tudni hatékony és biztonságos hálózati megoldásokat nyújtani.

el kellene felejteni ezt a hételemű hálózati vermet. miért éppen hételemű, és miért éppen verem. ugye ezek a gépek itt utasításvezérelt szekvenciális gépek, és alapvetően sorosoan kommunikálnak egymással. sorosan. a kommunikációhoz sor kell, és nem verem. felőlem lehetne verem is, csak akkor azt valamivel meg kell indokolni. és ugye még a hét eleműségre is mondani kellene valamit.

a hálózatot a világon mindenhol gráfokkal modellezik, a hálózati problémák elemi sorbanállási problémák, ugye a rendszermag frissítésekor meg kell várni, amíg a felhasználó a komponenst elengedi, a frissítéssel rendszerint várni kell, és a kéréseket a beérkezés sorredjében kell kiszolgálni, különben kavarodás lehet, a régi felülírja az újat (nem tudjuk h mi okozta a skype összeomlását, de valószínűleg az, h a gépek nem voltak konzisztens módon frissítve)

sokkal előrébb tartanánk, ha vennénk valami épkézláb gyakorlatban is működő konstrukciót, mondjuk a unixot, ahol a csomópontok egy magból és egy héjból állnak, és csövekkel vannak összekötve úgy, h a csövek belefúródnak a magba.

ezáltal is hatékony és biztonságos kapcsolatok jönnek létre. (1) a felhasználó véletlenül nem tudja tönkretenni a magot, mert azt a héjon keresztül nem lehet módosítani. (2) ha valaki szándékosan tönkreteszi a magot a csövön keresztül, akkor a felhasználó adatai nem sérülnek, mert azok nem a magban, hanem a héjban vagy a burokban vannak. (3) a hálózat minden szegletében lehetővé válik a logikai-fizikai szétválasztást, azaz a fizikailag különböző kapcsolatok a felhasználó elől mindvégig rejtve maradnak. (4) ugyanakkor tetszőleges méretű alhálózatok hozhatók létre különféle összetettségű problémák megoldására, elég hatékonyan tudunk mondjuk processzorokat összekapcsolni.

azaz az osi modell mellett annyi érvet lehet felhozni, h egyszer az iso elfogadta szabványnak, pontosabban valami ajánlásnak.

kutacs: a kulonbozo retegek (ahogy te hivod oket) kulonbozo absztrakcios szinteket jelentenek. Ahogy Szinbad irta, a megertest segitik. Nem igaz, hogy azert talaltak ki oket, hogy a tobbit ne kelljen erteni. Azert van rajuk szukseg, mert az ember agya mar csak olyan hogy egyszerre csak nehany dolgot tud fejben tartani (allitolag ez olyan 7-9 a legtobb embernel).

Namost ha omlesztve minden egyben van, akkor minden reszletre figyelni kell, amikor valamin gondolkozol (valahol hozzapiszkalsz a rendszerhez). Ha vannak jo absztrakcioid (pl. APIjaid), akkor minden problemat a megfelelo szinten tudsz kezelni. Pl. egy szovegszerkesztoben nem kell azzal foglalkoznod, hogy hova kerulnek majd az elmentendo file darabjai a vinyon. Mert azt a file-rendszer megoldja. Az viszont meg mindig nem foglalkozik azzal, hogy akkor most hogy is kell elkuldeni az adatokat arra a vinyora, mert lehet, hogy nem is vinyo van alatta, hanem pendrive. Vagy ramdisk.

Ettol meg te, amikor szovegszerkesztot irsz, jo esetben nagyon is tisztaban vagy az egesz folyamattal (kezdve a low level driverek mukodesetol folfele mindennnel). Mert akkor pl. nem probalsz meg byte-onkent irogatni.

Es minel bonyolultabb egy rendszer, annal inkabb szukseg van arra, hogy az egyes reszeit elbujtassuk ilyen absztrakciok moge. Ennek az egyik oka az, hogy mi emberek ilyen benak vagyunk, a masik pedig az, hogy a megfeleloen darabolt rendszerben az egyes interface-ek menten (API, de ha mar szo volt a halozati protokollok retegezeserol, akkor ott is) szetszedheto az egesz, es az egyes reszek kicserelhetoek egeszen addig, amig az uj elem is megfelel az adott interface-nek es betartja az elvart viselkedest. A halozati stack remek pelda: az egyes retegek menten szinten szetvalaszthato, es egy felso reteg ala berakhatsz egy maskepp mukodo implementaciot. Pl. a HTTP protko az nem csak TCP folott mehet, nyomathatod bluetooth-on is, mert semmi nincs a HTTP-ben, ami a TCPhez kotne. Az IP az nem csak ethernet folott mehet (es ezt ugye tudjuk, mert nagyon sokminden folott hasznaljuk), az is mehet mondjuk BT folott. Ha nincs ez a retegezes, akkor irhatod at a webszervered, ha ilyen trukkoket szeretnel bemutatni.

'Lukat furni' meg nem kell, az alacsonyabb retegeket bar elfedik a magasabbak, de ez csak annyit jelent, hogy nem kell oket hasznalni. Te attol meg lenyulhatsz, ha nagyon muszaj. De akkor a te komponensed mar nem tartja be ezt a jo kis konvenciot, es nem lehet vele olyan jol trukkozni, sok mindentol fogg fuggeni. Pl. ha a webszervered odapiszkal az ethernet driverbe, akkor nem csak nem fogod tudni mas halozati technologia folott hasznalni, de ha tortenik egy valtoztatas azon az alsobb szinten, akkor az teged is erinteni fog, te is irhatod at a szoftvered.

júzer, akarod fissíteni a cdm.dll, wuapi.dll, wuauclt.exe, wuaucpl.cpl, wuaueng.dll, wucltui.dll, wups.dll, wups2.dll, wuweb.dll fájlokat? öööö. nem. de. ja, nem. ja de. ennyi.

atleta,
ezt értem, de ezt úgy mondjátok, mintha a komponens alapú felfogás lenne az ultimate programozási szemlélet. nem azt mondom, h ez a felfogás rossz, hanem azt, h hálózat építésekor nem hasznos.

hiszen a hálózatokban az elemek rendszerint úgy rendeződnek el, h a csomópontok alapból érti az összes szomszédját, azokban az esetekben ha ez nem áll fenn, akkor szükséges egy direkt vagy indirekt logikai átfordítás.

de nem lehet előre megmondani, h ez az átfordítás milyen lépésekben fog zajlani, mert az igények folyamatosan változnak, és ahhoz kell igazodni.

itt ez a móricka ábra az osi-ról.
hu.wikipedia.org/wiki/K%C3%A9p:Paralell_2.png

oké, persze működhet így a is egy vállalat, de adott esetben nincs szükség ennyi szintre, és ezek a szintek felcserélődhetnek.

például nem kell titkár, és titkárnő sem, az igazgató adja közvetlen adja oda a csomagot gépkocsivezetőnek, mivel az információ titkos, az a protokoll, h a másik oldalon előbb kell odaadni az igazgatónak, és csak utána lehet kibontani. ha hatékony és biztonságos hálózatot akarunk építeni, akkor képtelenség így uniformizálni.

Kutacs: a komponensekre bontas nem biztos, hogy ultimate megoldas, de ahogy mondtam a gyarlo embereknek szukseguk van ra, mert igy tudnak jol gondolkodni. Matekban is hasznaljuk. Amikor egy nagyobb problemanak gyurkozol neki, akkor batran hivatkozol mindenfele mas bizonyitasokra, azokat adottnak veszed.

Geppel generalt szoftverek eseteben (lasd genetikus programozas) lehet, hogy nem ez az optimalis megoldas, embereknel meg nem nagyon talaltak jobbat. A mernokok igazabol evszazadok ota hasznaljak (lasd meg szabvanyositas).

> hiszen a hálózatokban az elemek rendszerint úgy rendeződnek el,
> h a csomópontok alapból érti az összes szomszédját, azokban az
> esetekben ha ez nem áll fenn, akkor szükséges egy direkt vagy
> indirekt logikai átfordítás.

Modnom, szoftver technologiai kerdes. Ha nincs retegezett architekturad, akkor minden halozattal foglalkozo szoftvert (kvektol az apacsig) irhatsz at, ha valtozik valami a rendszered felepiteseben. Rossz esetben akkor is, ha lecsereled az egyik 100Mbit-es eternet kartyadat egy masikra. Vagy wlan-ra, vagy ahogy mondtam bluetooth-ra. Plusz a homogen kornyezet sem igaz, mert van, ahol ethernet van, van ahol PPPOE, meg uvegszal, meg mindenfele rafinalt dolgok zajlanak am a melyben. Aztan megis mindegyik felett lehet CSzni :). Tehat 3 dologrol van szo: az egyik a konnyu valtoztathatosag (bizonyos szinteken a protokollok csereje), a masik az egyszerubb szoftver kod (nem keverunk bele oda nem tartozo fogalmakat, dolgokat), a harmadik pedig igenis az, hogy nem homogen a rendszer (az also retegek egyes gepeken mas hardware es protokol folott mukodnek, a felsobbek megis lehetnek egyformak).

Kedves HH, kerlek ne menj el a "HUP az isten, a MS meg a kocsog" iranyaba, mert eddig nagyon jol tartottad (legalabbis latszolag) a fuggetlenseget. Kerlek szakmai alapon itelj.

csak azt mondom, h a bonyolultság kezelésének nem az egyetlen módja az amiről beszélsz. és még azt is, h a hálózatokban a multilevel megoldások nem különösebben hasznosak.

meg azt is mondom, h a tcp/ip hálózatban erendendően nem volt api, a protokollokat éppen az api-k kiváltására találták ki, éppen az volt az egyik alapötlet, h ne legyen távoli eljárás hívás, nem legyen idl, térjünk vissza a unix filozófiájához és parancssoros üzemmódban működjön a hálózat. legyenek assembly programok és a shell scriptek, előbbi ellátja az alap funkciókat, utóbbiak pedig a felhasználói felületet adják.

a programok és a scriptek ne legyenek szintekbe szervezve, pontosabban ez 2 logikai szint van, ide vehetjük még a fizikai szintet is, és akkor 3. így is meg van a procedurális absztrakció, és van logikai és fizikai elválasztás, amire szükség van, hülyeség 5 vagy 7 réteget szervezni. ez a felfogás soha nem érvényesült tisztán. mindig jött valaki aki feltalált valami idl-szerűséget a protokollok közé mint valami győzedelmes újat. ennyi a lényegi mondanivaló, innentől kezdve hitvita lenne.

kutacs: önmagad hibájába esel, Te is egy API-t favorizálsz (unix shell script-ek), mint univerzális megoldást. A helyzet az, hogy amit írsz, attól az egész IT ipar nagyon messze van, teszem hozzá, szerencsére.

> hülyeség 5 vagy 7 réteget szervezni

Szóval az OSI modell hülyeség? Jól értem? Te vagy az első, akitől ezt hallom.

Kazi,
jól érted.

még annyit pontosításul, h a shell script a terminálok esetén adja a felhasználói felületet, a hostok esetén fejlesztői felületet nyújt. azaz távolról meg tudsz szólítani egy gépet úgy, h nem ismered a megvalósítás részleteit. nincs se 4., 5., 6., 7., se 2.5-ik szint. erről szól a tcp/ip, és nincsenek api-k, csak protokollok vannak.

kutacs: lenne egy rávezető kérdésem: hogyan implementálnál egy relációs adatbáziskezelő szoftvert API-k nélkül. (némi segítség: a relációs adatbázis kezelő szoftver egy új absztrakciós szint, a fizikai fájl szintű tárolást elrejti, és ehelyett egy logikai sémát nyújt a relációs adatbázis kezelő alkalmazásoknak)

Kazi,
ha relációs adatbázisokról beszélsz, akkor gondolom láttál már kívülről oracle-t.

>sqlplus @script

most hagyjuk a username/password párost, mert ezekben a szerencsétlen környezetben nincs sso. hol látsz itt api-t. elárulom az oracle belsejében sincs sok, többségében assembly programok futnak.

nem arról van szó, h nincsenek absztrakciós szintek, hanem arról h ezeket a szinteket nem api-k képviselik.

az előző komment elszállt, vagy csak kimoderálták, mert a téma erősen off.

de gondolom láttál már oracle-t, vagy valami hasonlót. ott azt mondod:

sqlplus @script

nincs api. az oracle belsejében sincs sok. assembly programok vannak, és néha shell scriptek futtnak. és elég jól működik a dolog. nem arról van szó, h nincsenek absztrakciós szintek, hanem arról, h ezeket nem api-k képviselik.

amiről amúgy beszéltek az nagyjából corba, ami a tcp/ip egyik versenytársa volt. még csak azt sem állítom, h a corba-nak ne lenne létjogosultsága, csak azt mondom, h a tcp/ip nem multilevel elképzeléseken alapul. és bocs a folyamatos offolásért.

kutacs: felreerted Kazit, o azt kerdezi scriptnyelvben hogyan implementalnal index treeket, oszlop kalkulust, toredezettsegmentesitest, elszotott tranzakciokat, olap kockakat?

> sqlplus @script

azt ugye látod, hogy ami a @script-ben van, az saját API?

"amiről amúgy beszéltek az nagyjából corba, ami a tcp/ip egyik versenytársa volt."

??? Hogy micsoda ??? Figyelj, valoszinuleg fiatal vagy meg, es ezert nem alazlak a porba, de sokat kell meg tanulnod. A velemenyed az IT-rol eleg tavol van a valosagtol. Ezt joszandeku kritikakent irom, meg ne sertodj.

Hát én ezen nem lepődtem meg, pénzéhes emberekről van szó, és szerintem nem csak titkos update van, bár ha valaki a servicesben kikapcsolja az automatikus frissítést, illetve leállítja a servert akkor egész biztos hogy nem fog ilyen megtörténni, másrészt meg hát nem kell Microsoftot használni.

Annyira bénák, akik hőzöngenek, ha az auto update fut!
Soha nem fogom felfogni, hogy lehet valaki olyan agyatlan, hogy azt állítja, neki csak úgy, magától , öntudatra ébredve elkezdi magát frissíteni a win, anélkül, hogy ő ezt jóvá hagyta volna. Ilyen egyszerűen nincs. Ha meg van, biztos vagyok benne, hogy valamit a béna user kúrt el. Nem kicsit, nagyon. A winupdate sztem nagyon hasznos, frankó dolog.
Én nagyon örülök neki, hogy van, és hogy havonta vagy gyakrabban jönnek az update-ek, nem csak a windowshoz, de az office-hoz és még egy sor ms cucchoz, ha van microsoft update-ed (nem sima windows update). Persze csak ha eredeti ms szoftvered van.
Az ilyen paranoiás emberek meg inkább keressenek fel egy pszichiátert!

A hiba a júzerben van.

az api technológai szempontból arra jó, h az eredeti megoldások hibáit elfedjék, vagy javítsák, esetleg újraimplementálják apró vátltozatatásokat végrehajtva. üzleti szempontból meg arra, h az eredeti megoldást hordozzák. nem az api áll it megoldások kiindulópontjában. azt mindig utólag alakítják ki.

aki fejleszteni akar, annak azt tudom ajánlani, h próbáljon meg programokat írni. programokat egyszerű bemenettel és kimenettel, és utólag próbálja meg kialakítani az api-t.

de nem fontos ezt a tanácsot követni persze.