Triplázódni fog a Windows ára?
2003-11-16T08:15:19+01:00
2003-11-19T14:04:11+01:00
2022-07-27T15:57:35+02:00
  • ez igaz. viszont semmi köze sincs az oprendszerekhez, tök mind1 milyet használsz ez a veszély fennáll. Az máskérdés, hogy valószinűleg még senkit nem törtek meg winampon keresztül, de a lehetőség valóban létezik.
    Mutasd a teljes hozzászólást!
  • Azt hogy egy lyukas winamp pont akkora biztonsági lyuk (sem nem több sem nem kevesebb) mint egy lyukas Mozilla vagy IE. De mig az utóbbakat elég sokan figyelik és sikítófrász van egy-egy lyuk hatására az előbbit (és a többi kismillió alkalmazást) a kutya sem figyeli. Azaz hiába patchelgeted te a browsered, leveleződ, offiszod, ettől még nem leszel biztonságban.
    Mutasd a teljes hozzászólást!
  • ezen hozzaszolasom is off gyanus lett
    nem jo nap ez nekem
    Mutasd a teljes hozzászólást!
  • cinizmus nélkül megkérdezik, hogy na ilyet tud a windows...


    igy van
    raadasul annak kiserlete nelkul, hogy megnezzek van-e ilyen a masik(mas) rendszerben
    nyilvan ertek hozza: oda kell kattintani..
    Mutasd a teljes hozzászólást!
  • mit is kell ezen végiggonolni? hogy tudom-e központilag patchelni a klienseken a mindenféle szedett-vedett programot. persze. miért ne tudnám?
    (megjegyzem, ha akarom eleve nem tudnak felrakni semmilyen programot, csak amit én engedélyezek. még olyat se amit nem is kellene telepiteni. md5 hash-es software restriction policy rules... :)
    Mutasd a teljes hozzászólást!
  • group policy-s intellimirrortól is fényévekre van még (ami pedig ingyen van benne a rendszerben), sms-t, mom-t csak azért hoztam fel, hogy ezekhez képest meg kis sem lehet fejezni, hogy hol van...

    unicenternek legeljebb az alapmodulja lehet kb egy áron egy sms szerverrel (ráadásul a 2003-al) csak az még semmire nem jó szinte, és kb 200-300e utána minden egyes modul amit menedzselni szeretnél vele. (oracle, mssql, exchange stb-stb) Ennyit szerinted hány linux-os fizet ki?

    A tudásába se menjünk szerintem bele, főleg nem linux-on, mert ott erősen korlátozott a wines változathoz képest.

    Tehát nyugodtan maradhatunk group policy + intellimirrornál, egyébként eddig is erről volt szó, csak megemlitettem, hogy ennél is van még magasabb szint. Csak mert sokan vannak akik összeszkábálnak egy apt-get-et becronozzák majd őszintén, cinizmus nélkül megkérdezik, hogy na ilyet tud a windows...
    Mutasd a teljes hozzászólást!
  • Pont e jelleg miatt ráadásul a szoftverek kevésbé épülnek egymásra (ha mégis, akkor a telepítő belerakják az igényelt dolgokat), mint Unixon, ráadásul az OS maga tartalmaz nagyon sok olyan dolgot, amivel Linux esetében, mint minden rendszeresen jelen lévő segédeszközzel (böngésző, grafikus felület, egy konkrét scripting nyelv, titkosító csomag, stb.) nem számolhatsz.


    De hogy mennyit szívtam én anno olyanból hogy az XXXX program felülírt/törölt olyan DLL-t amit én használtam. És milyen ezoterikus dolgok tudnak összejönni a felülírás után
    Mutasd a teljes hozzászólást!
  • Jó. Akkor gondold végig: azt mondjuk még meg tudod mondani hogy az IE vagy a mozilla esetén ott egy lyuk, nosza patcheljünk. De mi a helyzet az olyan kisebb programokkal mint Pl. winamp vagy akár a total commander meg a többi kismillió userspace progi amit a kutya nem vizsgál ebből a szempontból ?
    Mutasd a teljes hozzászólást!
  • Khmmm... Azért az SMS-t ne vegyük egy kalap alá az apt-get-tel, mivel egyrészt külön termék (bőven nem a Windows része, mint ahogyan a hozzá szükséges SQL szerver sem), másrészt meg nem is teljesen erről szól (funkcionalitásának csak egy része a szoftver telepítés, management).
    Ha az SMS-hez akarsz hasonítani valamit, akkor mondjuk a CA-Unicentert lehet, az létezik Linuxra is (meg Win-re, meg Tru64-re, meg Solarisra, meg AIX-re, meg még egy csomó mindenre), annak az ára is és a tudása is hasonló.
    A te összehasonlításod olyan mintha én azzal próbálnám a Windows-t lehúzni, hogy nézd meg milyen gagyi szövegszerkesztőt raknak bele (Wordpad), a Suse-ba meg milyen jót (Open Office). Ja hogy az OpenOffice külön termék? Meg hogy komplett irodai megoldást a Windowsra is fel lehet tenni (pl. MS-Office-t, de akár az Oo-t is), még olyat is ami sokkal többet tud az Open Officenál (MS-O Prof, Accessel megtüzdelve)? Ugye milyen furcsán hangzik?
    Mutasd a teljes hozzászólást!
  • Ha a mysql ugy van configolva, es a usernek olyan jogai vannak. De a mysql itt szerveroldalrol kellene bugos legyen, szervert meg azert gondosabban frissit az ember.
    Viszont ok, ilyen extremebb peldakra nem gondoltam.
    Mutasd a teljes hozzászólást!
  • ez igy önmagában igaz, de ettől még ki tud akasztani bugos program egy rendszert. ha majd lesz időm keresek ilyen hibát. az viszont biztos, hogy ezek a legritkábbak. de ugye az is elég, ha van egy kicsit bugos (vagy egyáltalán nem) user alkalmazásod ami elér egy bug-os mysql-t és máris megvan a baj... hiába futtatad userként.
    Mutasd a teljes hozzászólást!
  • De abban is megegyezhetunk, hogy a vegrehajtando kodra vonatkozo jogosultsagokat a kernel mindig ellenorzi - hacsak nem bugos az is. Gondolom ez a Windows NTre es ujabb verzioira is igaz.
    Ugyhogy elmeletileg csak a user dolgaiban lehet kart - bar igaz, hogy az is egy elegge sulyos kovetkezmeny.
    Ooo, es igazabol meg systraceszel is be lehet iktatni egy ujabb lepcsot: http://man.netbsd.org/man/systrace+1+NetBSD-current
    Mutasd a teljes hozzászólást!
  • ok, akkor ezt tisztáztuk, patchelni kell mind a szervereket mind a klienseket minden rendszeren és ez a lényeg.
    Viszont az exploitok és férgek számát én nem tartom szakmai érvnek, a linux kis elterjedsége miatt ez a szám kicsi, de megmutatták már a hackerek, hogy arra is lehet férget is, virust is irni, ugyanolyan keményeket mind winre, igy a linux terjedésével folyamatosan nő ezek száma.
    Mutasd a teljes hozzászólást!
  • hmm, akkor megkövetem magam, ezek szeirint régen láttam IS-t, utoljára vb6-nál meg talán delphi 6-nál és ott szó nem volt még msi-ről, hanem csak saját rutinokról.

    De mentségemre legyen mondva, hogy a vitánkban is a régebbi (nem msi-s) változataként került elő és aszerint is beszéltünk róla - IS mint saját rutin és msi mint installer service, group policy
    Mutasd a teljes hozzászólást!
  • Akar hiszed, akar nem, a buffer overflowokat kivedo megoldasokat mikor felhoztam, _tenyleg_ nem mint egy mindig mindenhol mukodo, szent pajzskent probaltam beallitani oket, ez latszik a mondat megfogalmazasabol is.

    A desktopos dolgot illetoen szinten all ez, bar lehet, hogy ott nem voltam elegge vilagos. Nem vagyok annyira ostoba, hogy tenyleg mellozzem a patcheket, minden esetben.
    Arrol van szo, hogy ami desktop itthon mukodik, elhanyagolhato gyakorisaggal kell piszkaljam ilyen okokbol - ebbol indultam ki.

    A 80-443as viccedet en nem vicckent ertelmeztem, mert nem lattam helyet ott hasonlonak. Ezert valaszoltam ugy, ahogy.

    Ami viszont az egesz lenyege, hogy ezeket a hibakat kihasznalando nem jelent meg Linuxra, vagy hasonlokra tul sok virus vagy fereg, nem volt belole tul nagy problema. Es mivel a tuzfal is ad egy bizonyos vedettseget (a betolakodok ellen, peldaul akik vmi furfangos modon esetleg bindshellt inditanak a bongeszon keresztul, ha eppen annyira bugos), nem muszaj az ilyen bejelentesek utan naponta panikba esni, es rohanni frissiteni (foleg, ha automatizalva van, ahogy azt egyesek mar elozoleg is felvetettek).
    Mutasd a teljes hozzászólást!
  • Az IS egy kellemes grafikus kornyezet, amivel .msi csomagokat gyarthatsz. Ezek osszerakasa es kibontasa(telepites) 100%-ban csak a Windows Installer segitsegevel tortenik. Ha megnezed az SDK-t, akkor lathatod, hogy barmit meg tudsz csinalni pusztan a Windows Installer COM feluletetn keresztul, amit az IS tud. Ez eddig a "Basic MSI" -re vonatkozik.
    Az IS specifikus dolgok: uj scriptnyelv a Custom Actionokhoz, online update lehetoseg (ezert kulon fizetni kell), valamint a setup.exe keszitese, amibe be lehet csomagolni a telepiteshez szukseges dolgokat (ujabb telepitomotor pl), hogy ha valami nincs meg a kliensen, akkor is lefusson. Ehhez kepest azt allitani, hogy
    Az installshield és társaiknak az ég egy adta világon semmi közük nincs az oprendszer telepitő rutinjaihoz
    finoman szolva is erdekes meglatas.
    Mutasd a teljes hozzászólást!
  • Ez egy igen komoly hozzászólás volt, gratulálok hozzá.
    Esetleg egy ici-pici szakmai érvet is hallhatunk? Pl, hogy debizony egy installshield is terithető group policy-val ugyanúgy ahogy a msi hiszen az is az installer service-t használja amin keresztül a group policy-s intellimirror működik.
    És, ha ezt be is bizonyítod nekem, akkor nagyon elszégyellem magam.

    De remélem nem azzal fogsz jönni, hogy egy installshield is mondjuk felhasznál két függvényt installer service-ből, mondjuk registry kezeléshez, mert elsirom magam...
    Mutasd a teljes hozzászólást!
  • Ez igy ebben a formában nem igaz, hiszen egy group policyval kiterített msi is képes lehúzni kapcsolódó package-eket, ha úgy van definiálva. Egy sms-ről nem is beszélve, ami akár a patchek egymásra épülését is képes figyelni és ha kiosztasz egy új patch-t ami függ pár régitől akkor ezt észreveszi és előbb a régieket rakja fel a kliensre.
    Mutasd a teljes hozzászólást!
  • Nyelvtani játékokba inkább ne menjünk bele, valóban nem állitottad, hogy 100%-os biztonságot adnak a buffer overrun keresők, csak ezt hoztad fel a buffer overrun hibák ellen, mintha ezekkel megszünnének ezek a hibák -> nem kell velük törődni > igazoltad, hogy nem kell desktopon patchelni...
    Ugyanez a másik esetben is.

    En a netet a gatewayemen keresztul erem el. De nyilvan nem fogom blokkolni a http kapcsolatokat. Tuzfallal szurni olyan dolgokat lehet, mint a bindshellek, es egyebek.


    Te tényleg nem érted, vagy csak adod az értetlent? De mind1, hagyjuk a témát.

    A személyeskedést akkor tényleg hanyagoljuk próbáljunk a szakmai érveknél maradni...
    Mutasd a teljes hozzászólást!
  • Az installshield és társaiknak az ég egy adta világon semmi közük nincs az oprendszer telepitő rutinjaihoz.


    Neked viszont a temahoz nincs kozod, legalabbis a hozzaszolasod alapjan. A tovabbi fejtegetesek elott javaslom, hogy hasznald valamelyik ilyen csomagot (InstallShield, Wise) egy darabig, csak hogy kepet kapj...

    netchan
    Mutasd a teljes hozzászólást!
  • Szerintem meg a Linux-os package managerek járnak nem öt, hanem sokkal több évvel a windows installer (és az installshield, meg az XYZ. installer-készítő cumók) előtt.

    Ez technikai értelembe így van. Más kérdés, hogy Windows alatt egy hasonló package managernek egyszerűen nincs értelme, hiszen ott nem ingyenes és szabadon terjeszthető a legtöbb komponens, így hiába lenne technikailag képes egy csomagkezelő magától lehúzni minden igényelt programot, ha azokért fizetni kell(ene), máris megbukott az egész dolog, hiszen nem húzhatná le csak úgy. Pont e jelleg miatt ráadásul a szoftverek kevésbé épülnek egymásra (ha mégis, akkor a telepítő belerakják az igényelt dolgokat), mint Unixon, ráadásul az OS maga tartalmaz nagyon sok olyan dolgot, amivel Linux esetében, mint minden rendszeresen jelen lévő segédeszközzel (böngésző, grafikus felület, egy konkrét scripting nyelv, titkosító csomag, stb.) nem számolhatsz.

    Tehát Windows alatt nem azért nincs olyan összetett csomag-kezelő, mint Linux alatt, mert hülyék a programozók, hanem mert nincs gyakorlati jelentősége, létjogosultsága egy ilyennek. Amelyik funkcióknak meg van, azokat ugyanolyan jól tudja a Windows Installer, mint akármelyik linuxos csomagkezelő.

    A javítások kezelése Linux esetében folyamatos frissítéseken alapul a "stable" rendszerekben is, a "release early -- release often" elv alapján. Ez azt jelenti, hogy nem várnak össze több bugfixet egy service pack kiadásához (illetve az RH/SuSE entervájsz edisönjei ezt fogják tenni...), hanem mihelyst a hibára van megoldás, workaround, az kijön egy új csomag "képében", ami akár automatizálva is felmehet.

    Ez eddig a Windows esetében is így volt. Csak most találta ki az MS, hogy havonta csak egy csomagot ad ki.
    Mutasd a teljes hozzászólást!
  • ``Desktop rendszert, ha megfeleloen hasznaljak, aligha kell patchelgetni.''
    Nos, en nem tudom, a magyar nyelvet beszeled-e (bar ugy tunik, nem), de ez nem zarja ki a patchelest minden esetben.

    A buffer overflow elleni akarmikre sem mondtam, hogy 100%osak: ``... szinten nyujt egy bizonyos foku vedelmet.''

    En a netet a gatewayemen keresztul erem el. De nyilvan nem fogom blokkolni a http kapcsolatokat. Tuzfallal szurni olyan dolgokat lehet, mint a bindshellek, es egyebek.

    A celzasom az arcod meretere pedig csupan barati jellegu volt - annak ellenere, hogy baratomnak sosem mondanalak. Nem szoktam fenyegetozni.

    A Windowshoz nem ertek olyan szinten, hogy bele tudjak szolni a rendszerfrissito mehanizmusait boncolgato vitatokba. Talan ezert nem tettem meg. De azt tudom, hogy userkent rebootolni csak ugy nem fogsz.
    Mutasd a teljes hozzászólást!
  • Ja, hogy most már mégiscsak kell desktopot patchelni hiába nem root,hiába tűzfal? Hát igy már mingyjárt más, csak sajnos nem ezt mondtad múltkor... Azt senki sem vonta kétségbe, hogy mérlegelni (és ami ennél is fontosabb kitesztelni) kell a patcheket, de hogy tűzfalban és nem rootként futtatott alkalmazásokra bizzál egy komoly rendszert az egy égbekiáltó marhaság. Én csak ez ellen szólaltam fel, mert sajnos sok ember nem ért hozzá, elolvassa az ilyen beirásokat linuxról és el is hiszi, hogy azt nem kell patchelni... Ezzel van nekem a gondom. Egyébként hogy valójában patchelsz-e otthon (bár mint utóbb kiderült nagyon is patchelsz) az engem a legkevésbé sem érdekel az a magánügyed. De hozzá nem értőket félrevezetni már konrántsem az.

    A buffer overrun kivédő technikák minden rendszerre léteznek, de egyrészt nem minden szoftver használja őket másrészt ezek sem 100%-osak. Ja és mielőtt azzal jönnél, hogy te majd alkalmazod őket, hát alkalmazd mondjuk egy linuxos oracle-re, amiben szintén két marékkal lehet bugokat találni és semmit nem tehetsz ellene...

    Szomorú, hogy nem érted a 80-as, 443-as portra utalást, ezeken éred el a netet, és csak az első hozzászólásod kifigurázása volt, hogy egy tűzfal megvéd a bugoktól... (lásd opera, mozilla - vagy mondj bármilyen használható böngészőt - bugok amit nem lehet tűzfallal kiszűrni, max a teljes net elérést a fenti portok blokkolásával)

    A saját érdekemben? És megtehetnéd, hogy szemen köpsz? brrr, remegek mint a nyárfalévél.

    Ilyen komoly fenyegetést régen nem kaptam már. De hát ez jár, ha valaki egy linux-os tévedéseit (bár inkább szándékos csúsztatásoknak nevezném, persze a saját kedvenc rendszere irányában) megemliti...
    Mutasd a teljes hozzászólást!
  • Indokolt esetben nyilvan kell, es annyira nem is bonyolult, megjegyzem, hiszen Debianra is, es RedHatre (Fedorara?) is letezik apt-get, Gentoonak meg ott a portagee.
    De nem kell minden bugra ugrani, nem art elotte merlegelni, valoban megeri-e soron kivul hajattepni. Bar vegulis a te bajod.
    Alattam ezt a NetBSDt a Security Advisoryk es az audit-packages outputjanak elemzese utan upgradelem. Evek alatt meg nem volt belole gondom, es biztosra veszem, hogy nem tudnal kart tenni ebben a rendszerben.

    A buffer overflowok elkerulesere egyebkent tobb tehnikat is kidolgoztak, pl a PAX, a W^X, a propolice, exec-shield, stb, ami szinten nyujt egy bizonyos foku vedelmet.

    Hogy a 80as es 443as portot miert tanacsos szurni szerinted, azt nem tudom.

    A megfektetest nem ertem, a kod a user jogaival hajtodik vegre. reboot()olni akkor sem fog, ha a mozillat eredetileg nem terveztek, hogy ilyet csinaljon.
    Persze ha rootkent fut...

    Egyebkent nem tudom, mondtak-e neked, de ``e vilagban megvetik az onmagat felemelot'', ugyhogy a sajat erdekedben, finomits a hangnemeden. En sem koplek szembe, hiaba tehetnem meg.
    Mutasd a teljes hozzászólást!
  • Ha igen, (vagyis van "konverzió" install.exe és msi között), akkor igaz a fenti állításod.


    Természetesen van konverzió melynek egyik példája a winstall, melynek LE változatát minden server változathoz ingyen kapod... Ezzel bármilyen telepitőt át tudsz írni msi-re, akkor is, ha nem is tudod mit csinál. (snapshot difference)
    Tehát ahol ez számit és igény van rá, ott megoldható, hogy 100%-ban msi telepitést használj. (sok vállalatnál megy ez igy)

    Hány install.exe cucc tudja megmondani, hogy neki melyik dll melyik verziója szimpatikus, melyik másik alkalmazással nem fér össze...


    Mindössze a .net-es alkalmazás fileoknak a 100% képes erre...
    sok mással egyetemben, de ez most mind1.

    Az előbbinél esélyed van arra, hogy a beállításaidra keresztet vethetsz, az utóbbinál megmaradnak.


    Ez szintén nem igaz, msinél is megmaradhatnak - ha akarod!! - a beállitásaid, a többinél meg lásd első bekezdés... .Net app.config-jairól meg már nem is beszélve.

    A többit az msi is tudja, de pl md5 hash-nél jóval fejlettebb pki alapú szoftver aláirást tesz lehetővé mind az msi mind a .net. (persze .net msi)
    Mutasd a teljes hozzászólást!
  • Az installshield és társaiknak az ég egy adta világon semmi közük nincs az oprendszer telepitő rutinjaihoz. Azok "házi" készítésű rutinok. Amit hasonlítgatni kéne az a windows installer service.


    A WIndows-os programok hány %-a megy msi csomagból, és hány ezekből a saját tákolmányokból? Vagy ezeknek a telepítését/frissítését (függőségeikkel egyetemben, amiről tudomásom szerint nem mond semmit a telepítőkészletek jelentős része) is meg tudod oldani? Ha igen, (vagyis van "konverzió" install.exe és msi között), akkor igaz a fenti állításod.


    Ez sajnos szintén nem igaz lassan 4 éve a .net megjelenése óta, sebaj, jól hangzott...


    Hány install.exe cucc tudja megmondani, hogy neki melyik dll melyik verziója szimpatikus, melyik másik alkalmazással nem fér össze... A .NET szép dolog, csak a legtöbb alkalmazás még nem így készül...

    A többire fent van a válasz... egyrészt .net másrészt apt-get vs


    NOs, én nem ezt hasonlítottam össze, hanem azt, hogy hogyan lehet Windows alatt frissítéseket felrakni (pl. uninstall.exe, majd az új install.exe futtatása, illetve msi-nél ugyanez az OS szolgáltatását igénybe véve), illetve Linux alatt hogy megy: apt-get upgrade
    Az előbbinél esélyed van arra, hogy a beállításaidra keresztet vethetsz, az utóbbinál megmaradnak.

    Sajnos a legtöbb alkalmazás még nem msi-ben jön, ezt be kell látni. Az pedig, hogy mi lesz majd jövőre vagy az után, az nem lehet a mai összevetés alapja.

    (Szoftverterítés: osztott könyvtár, ha van valami benne, cron-ból dpkg -i; verziókövetés: minden egyes komponens, (csomag) verziókövetéssel kerül ki, lehet naplózni, hogy egy adott gépre mikor, mit raktunk fel automatice (dpkg -i >> install.log) távoli upgrade: ssh dpkg -i;
    központi szoftverleltár: ssh dpkg -l,)

    A satöbbihez:
    -A deb csomag tartalmazza, hogy mely szoftvercsomag mely verziója:
    -szükséges
    -ajánlott
    -összeférhetetlen
    az adott csomaggal.
    -A csomag tartalmazza saját maga rövid leírását
    -A deb csomag tartalma a telepítővel megvizsgálható (bele lehet "nézni", hogy mi is van benne, mi fut le telepítéskor/upgrade/uninstall esetén)
    -A csomag mely állományai tartoznak a
    -dokumentációhoz,
    -konfigurációs állományokhoz.
    -A deb csomag tartalmazza a benne lévő összes fájl MD5 kivonatát.
    -Egy azon csomag tartalmazza a különböző nyelvi verziókat.

    satöbbi.
    Ha egy csomagot törlök, attól pl. a konfigurációs állományai default-ban fent maradnak, hogy egy upgrade esetén (mert az uninstall/install valójában) a beállítások megmaradjanak. Ha a fenthagyott konfigurációs állomány változott ahoz képest, ami a csomagban volt (tehát egyéni beállítást tartalmaz) meg lehet nézni a különbséget, meg lehet hagyni a régit/feltenni az újat.
    Egy parancs kiadásával megállapítható a rendszerben található valamely fájlról, hogy:
    -tartozik-e valamely telepített csomaghoz,
    -ha igen, módosult-e a telepítés óta,
    -mely fájlokkal került egyszerre telepítésre (mely fájlok vannak vele azonos csomagban)
    stb, stb...
    Mutasd a teljes hozzászólást!
  • ok, téma részemről lezárva, ne patch-lj.
    Mutasd a teljes hozzászólást!
  • Azért a service lyukak jóval ritkábbak mint a userspace-es programoké. Meg persze linuxon aránylag kézben vannak tartva hogy milyen szerverek futkároznak. A M$ oldalon épp az volt a gond hogy régebben elég sok progi felment boldog-boldogtalannak. Na ez az amin mostanság kezd változtatni a M$.

    És ebből a szempontból tökmind1 hogy mennyi lyuk van a mozillán: ő ugyanolyan userspace progi mint a notepad. Ezzel nem igazán érdemes foglalkozni: a kismillió win-es (vagy linuxos) progiból szvsz senki nem tudná megmondanki hogy hány lyukas. A problémát a szerverek okozzák. Nem mondom ott is akad egy-két lyuk mindkét oldalon de azért nem annyira tragikus a helyzet.
    Mutasd a teljes hozzászólást!
  • Az installshield és társaiknak az ég egy adta világon semmi közük nincs az oprendszer telepitő rutinjaihoz. Azok "házi" készítésű rutinok. Amit hasonlítgatni kéne az a windows installer service. (group policy szoftverterítéssel, verziókövetéssel, távoli upgrade-el, központi szoftverleltárral(sms) stb-stb)
    No ezekhez hasonlítgassuk az apt-get-et. És akkor hol vagyunk még az sms/mom tudásától...

    Ezt sajnos a Windows-ok alatt nem mondhatjuk el, akár mennyire is ez a marketing-szöveg.


    Ez sajnos szintén nem igaz lassan 4 éve a .net megjelenése óta, sebaj, jól hangzott...

    windows installer, installshield meg az ezernyi másik "telepítőgyártó" produktuma


    Olvass egy kicsit utána, továbbra sem keverendő össze a windows installer (ami az oprendszer egy szolgáltatása) a kézzel írt telepitőrutinokkal...

    A többire fent van a válasz... egyrészt .net másrészt apt-get vs SUS/SMS/MOM=
    Mutasd a teljes hozzászólást!
  • így van a blaster is daemon-t (servie-t) fektetett meg, így ott is teljes mértékben lényegtelen volt, hogy userként használod a géped vagy adminként. Ugyanez a helyzet linux-on is.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd