Helyi és távoli hibák a Linux kernelben

Akkor se csinalhatnad meg egykonnyen ha a Linux kernel mikrokernel felepitesu lenne, mert a Linux ellentetben a Windows-zal _NEM_ egy termek. A legtobben hasznalunk ilyen/olyan disztribuciot amiben alapobol eleve nemcsakhogy mas verzioszamu kernelek vannak,

hanem azok is patch-elgetve vannak, stb.

Azzal, hogy bra azt mondta "apt-get install kernel-igmp" szerintem egyertelmuve tette, hogy nem Linux, hanem disztribucio szinten mukodhetne az ilyen jellegu frissites.

A tobbihez inkabb nem is szolok hozza, csak halkan a BeOS-ra, MacOS X-re es AmigaOS-re gondolok, mint mikrokerneles rendszerekre, hogy tenyleg mennyire "lassuak"...

hunger wrote:
> A tobbihez inkabb nem is szolok hozza, csak halkan a BeOS-ra, MacOS X-re es
> AmigaOS-re gondolok, mint mikrokerneles rendszerekre, hogy tenyleg mennyire
> "lassuak"...
AmigaOS mint mikrokernel (vagy egyáltalán, kernel) egy olyan
architektúrán, amiben még MMU sincs?

Ez biztos? :)

Az x86 miatt lassú a mikrokernel pc-n. Az általad felsoroltaknál ez nem jelentkezik. Nomeg hol gyors az osX? Nem a kernelen múlik egy adott os által kiváltott sebeségérzet.

Az AmigaOS az pont rossz pelda, ugyanis MMU nelkuli cuccon konnyebb mikrokernelt irni mint monolitikusat ;-) Ez hulyen hangzik meg persze nem is pontos, de az az igazsag, hogy pl egy sima C64-re irt Contiki OS kozelebb van a mikrokernelhez mint a monolitikushoz, bar a hw supportalt vedelmi rendszerek (I mean memorialapozas, meg ilyenek) az hianyzik. Ilyen korulmenyek kozott tulkeppen amugy sincs kulonbseg sok dolog kozott ahol pedig kene ;) tehat a user space es kernel space nem hatarolhato el, igy automatice mikrokernel feeling lesz belole :) Mig Linux eseten pl hiaba vannak kernel thread-ek, azert nem egeszen ugyanugy mukodik mint egy user space process. Na mind1, nem ragozom :) tehat inkabb ugy kene fogalmazni hogy igazan jo biztonsagos, server feladatra szant OS-t (szerint e Mac OS X es a BeOS se az) jelenleg nem szokas mikrokernel arch-ra epiteni.

imho nem attol mikrokernel, hogy van-e hardveres memoriakezeles vagy nincs...

Nekem nyilt forraskod kell, kooperacio lehetosegese, eshogy lehetoleg standard megoldasok legyenek hasznalva.

Nyilt forraskod nincs, ez van. Kooperacio es standard megoldasok? Ha ennek hianyat 5 evvel ezelott veted fel a Microsoft ellen, akkor igazat adok, de most amikor szabvanyos Kerberost hasznal, RDP-t, stb...

Kicsit a Belga feelingem van:

Ha nincs nyilt forraskod az a baj,

ha Open a Solaris, de nem GPL az a baj,

ha nem szabvanyt kovet MS az a baj,

ha maga teremti a szabvanyt az a baj,

ha standard megoldast hasznal az is baj.

lgb wrote:
> Kisse bonyi mar a thread szerkezet, szoval ide irok :)

newgw-ng rulez :-)

tehat inkabb ugy kene fogalmazni hogy igazan jo biztonsagos, server feladatra szant OS-t (szerint e Mac OS X es a BeOS se az) jelenleg nem szokas mikrokernel arch-ra epiteni.

Lehet, hogy nem szokas, de biztonsag szempontjabol akkor is jobb megoldas lenne, ha a leheto legkevesebb kod futna ring0 szinten es ezt mikrokerneles felepitessel lehet a legjobban elerni.

AmigaOS mint mikrokernel (vagy egyáltalán, kernel) egy olyan

architektúrán, amiben még MMU sincs?

Nem tudom, mikrokernel volt-e.

De nekem volt az Amigamban MMU. Az ugyanis nem az architekturatol, hanem a procitol fuggott. A 68020-tol mar volt, nekem 68030 volt benne.

1. az univerzalis hotfix ugyanugy mukodik/hetne, mint maga a kernel forditas: mindenki maga forditana le, abbol a forrasbol, amibol a futo kernele is szarmazik (+patch). ezt runtime belinkelni a futo kernelbe nem akkora ordongosseg, lasd alabb.

2. az MS uj hotpatch mechanizmusa eleg egyszeru asm szinten: minden fuggveny ele beszurnak 5 toltelek byte-ot (0xcc vagy 0x90 amit eddig lattam) ill. maga a fuggveny is egy toltelek 2 byte-os utasitassal kezdodik (mov edi,edi). ezek utan a hotpatch eloszor atirja az 5 byte-ot egy 'jmp uj_fuggveny'-re, ami ugye i386-on pont 5 byte, aztan pedig atirja a dummy 2 byte-ot egy 'jmp short'-ra, ami raugrik az 5 byte-os hosszu jmp-ra. ez igy majdnem SMP-safe es linux ala is siman meg lehetne csinalni.

az egesz runtime/hotpatch dologhoz persze az is hozzatartozik, hogy ez (is) egy ketelu fegyver, hiszen nagyban leegyszerusiti a backdoorok installalasat is (tessek meggondolni, hogy a dummy utasitasok nelkul hogyan lehet SMP-safe modon megpatch-elni a kernelt...).

1. a windows nem mikrokernel, hanem klasszikus monolitikus kernel + kernel modulok (vagyis minden 'kernel' kod ring-0-ban, azonos cimterben fut). mint a linux vagy a BSD-k.

2. a windows kernel (ring-0 kod, hogy egyertelmu legyen ;-) ugyanugy bugos, mint a userland. neha egeszen amator szinten, lasd EEYE advisory-k (pl. ntvdm vagy expand down data segment).

Basszus, végigkutattam a fél netet, de sehol se találom ezt az iddqd.ko -t. Mondd, honnan töltötted? :-)

Hi!

Azert flame elott nem artana megnezni par dolgot, pl hogy grsec-kel sebezheto-e. Ugyanis ilyenkor mindenki flamel, hogy sz*r a Linux, meg minden, de senki se emliti meg altalaban, hogy a grsec a hibak nagy reszet megfogja.

A masik dolog, hogy mindenki azzal jon, hogy a kezdo user nem fog kernelt forgatni. A kezdo user szerintem SP-t se fog feltenni, nemhogy hotfixet. Azt se tudja, mi az altalaban. Az a jo eset, amikor egy kezdo user le tud jatszani egy filmet a gepen, vagy hogy fel tud tenni egy drivert. Az olyan szintu user, aki tesz fel SP-t, vagy valami mast, az kernelt forgatni is tud.

A 3. megjegyzes, hogy az uj kernel kiadasa utan nem sokkal meg szoktak jelenni a hibat javito kernelmodulok is. Amikhez nem kell reboot.

By(t)e

TBS::Antiemes

Jezus... Lehet hogy csak en vagyok tul igenyes, de azert ennek meglehetosen eroteljes hack szaga van, es ranezesre is szanaszet lognak belole az acskapcsok... :) Bar igazabol egy ilyen runtime patchelesi mechanizmus igazan elegans megvalositasahoz az egesz dinamikus linkelesi procedurat fel kene boritani majdnem (hehe) minden rendszeren, amit nyilvan senki sem mer bevallalni...

Az AmigaOS nem hasznal MMU-t alapertelmezeskent, akkor sem ha a processzorban van MMU. Egyedul egyes fejlesztoeszkozok (debughoz), emulatorok/virtualis gepek (pl. Mac emulator), es rendszergyorsito patchek hasznaljak az MMU-t. Meg persze a hardver MAPROM funkcio nelkuli turbokartyakon altalaban MMU-val szoktak biztositani a shadow ROM irasvedettseget. (Amugy is relativ nehez 68k-ra altalanos MMU kodot irni, mert ahany CPU-szeria, annyifelekeppen mukodo MMU-t sikerult belefureszelni a Motorolanak.)

Egyebkent kerem vegyuk eszre mekkora bikeshedet sikerult epiteni itt hirtelen. A fo problema a Linuxal nem az, hogy felepitesileg mikro vagy monolitikus kernel. A fo baj az, hogy nem modularis. Ertsd: nem tudod pl. a teljes TCP/IP alrendszert, es hasonlokat kiszedni a kernelbol. Nincsenek jol elhatarolt, megtervezett(!) interfeszek, amikhez lehet fejleszteni a dolgokat, es amik legalabb egy kernel foverzion at stabilak. Attol meg hogy pl. a TCP/IP kulon alrendszer lenne, nyugodtan futhatna Ring0-n (vagy Supervisor modban mer' olyan hogy Ring0 csak x86-on van, ugye :), szoval ennek semmi koze ahhoz h. mikro vagy monolitikus kernelrol beszelunk eppen, sot lehetne ugyanugy resze a kernelforrasnak is. Viszont megoldana az ilyen problemakat, hiszen a kernelnek az a resze, aminek a patchelesehez mar mindenkeppen ujrainditas kell, eleg minimalis. De ez mar eleg messzire vezet, mert az igazan jo megvalositashoz sztem sok regi begyoposodott konvenciot el kene dobni, tobbek kozott atalakitani az egesz dinamikus linkelesi eljarast, a bootprocedurat, es hasonlokat, amit ha itt felemlegetnek, akkor sok hardcore Linux hivot es C programozot kerulgetne a szivinfarktus, es le lennek flamelve, amihez most nincs kedvem. :) (Egyebkent vannak igen jo megvalositasok a problemara, de gyakran pont a konvenciokkal valo szakitas miatt nem terjednek el, tyuk vagy tojas problema.)

iddqd nem a doom 1-2 jatekban volt az orokelet cheat? :P

Nem azt írta a Bra, hogy sebezhetetlen minden támadással szemben?

rotfl, ok, leesett :P

1. a windows nem mikrokernel, hanem klasszikus monolitikus kernel + kernel modulok (vagyis minden 'kernel' kod ring-0-ban, azonos cimterben fut). mint a linux vagy a BSD-k.

Akkor nem tudom miert irjak mindenhol azt, hogy mikrokerneles...

"Microkernel Designs and the Windows NT Architecture" [www.microsoft.com]

"micro-kernel architecture" [www.microsoft.com]

The system is built on a fully 32-bit microkernel foundation." [www.microsoft.com]

stb.

Kernel hibakrol meg annyit, hogy kozel sem jon ki annyi Windowsra, mint Linuxra (de tudom, hogy erre az a valasz, hogy azert, mert nem nyilt forraskodu... blabla :)

hunger wrote:
> rotfl, ok, leesett :P
Örülök, hogy valakinek, végre. :)

Mondtam egy rossz szot a Solaris-rol vagy barmi masrol? Azt hiszem te allandoan csusztatsz itt az m$ megszallottsagod miatt. Nem mondtam hogyha nem GPL az baj, nem mondtam semmit a Solaris-rol stb stb. Nem is volt szo ezekrol, ne keverd ide.

Az m$ SOSE hasznal standard megoldast, szomoru vagyok ha ENNYIRE vak es napellensoz vagy ... Neha azt mondja magarol hogy hasznal csak egy "kicsit" modosit par dolgon hogy azert megse legyen olyan egyszeru nem m$ termeket is belevenni a buliba ha valaki nem homogen kornyezetet szeretne pl. Mas esetben ahol meg a standard megvan ott gyorsan par ezer szoftver szabadalommal levedi, lasd pl az office XML formatum es hasonlo terveit. Ott is mondja, "nesze nektek standard megoldas, XML!" de azon belul mindent szepen szabadalmaztatni akar, szoval hiaba XML ugyanott tartana mint a jelenlegi .doc formatummal.

nem tudom, feltunt-e, de a forrasaid mind az MS-tol szarmaznak ;-). szoval az ntoskrnl.exe meg az osszes .sys EGY cimterben fut, azonos (ring-0) privilegium szinten -> ez nem mikrokernel, akarhogy is csurom-csavarom. annak idejen, amikor az NT kijott, jo reklamszoveg volt, hogy megkulonboztessek az archaikus/elavult/blablabla UNIX alapu rendszerektol, de csak ennyi, ez is kamu szoveg az MS-tol.

a kernel hibakrol meg... nos igen, nem vegeztem szamszeru osszehasonlitast (meg te sem, az MS-nek jo szokasa ui., hogy tobb cuccot javitanak egy patch-ben, mint amit elismernek, a dolog kb. ugy mukodik, hogy ami mar nyilvanos, azt megemlitik, a tobbit meg fu alatt), de ranezesre nem nehez megmondani, hogy forraskod elerhetosege -> tobb bug megtalalasa. ilyen alapon az IE a vilag legbiztonsagosabb bongeszoje, mivel abban kevesebb bugot talaltak, mint a Mozilla alapuakban (mielott valaki ramutat a sok IE bugra, nezze meg a Mozilla bugzillat es mondja meg nekem, hogy a tobb szazezer bejegyzesbol vajon hany jelent tavolrol kihasznalhato hibat). ugye milyen abszurd osszevetes? ezert probaltam arra celozni, hogy a bugok szama helyett a bugok 'minoseget' erdemes megnezni, vagyis azt, hogy milyen programozoi tipushibakat vetettek az egyik ill. masik oldalon. en a linux-ban nem tudok olyanrol, amirol az emlitett ket EEYE advisory beszel -> linux csavok nagyon gyurjak az i386-ot ;-).

Namost asszem' kozelednek a velemenyek egymashoz. Marmint arra celzok hogy nem vagyok feltetlenul Linux megszallott. Ha pl a Hurd fejlesztok jelentkeznenek (de mas peldat is lehetne mondani) hogy kesz a varva-vart mikrokenrel architekturaju GNU kernel, es lemosna a Linuxot a palyarol secc perc alatt, akkor legyen ugy!

A mikrokernel mint elv szep, egyaltalan nem mondtam hogy ezzel lenne gond, a gond az elv implementalasaban van, legtobb esetben. Innen eredeztetheto eleve ugye Linus jol ismert esete a MinixLinux vitaban. Az a baj, hogy az elvek es a gyakorlati dolgok nem mindig talalkoznak.

Abban igazad van, hogy modularitas, biztonsag stb stb szempontjabol is jobb lenne ha nem egy monolitikus kernel belesejeben lenne minden osszezsufolva. De ennek ellenere valahogy megse latok elterjedt, normalis, hasznalhato, stb megoldast ami nyilt forraskodu es mikrokernel felepitesu.

Amugy a Linux se tisztan monolitikus tobb szempontbol se, bar az igaz hogyha egy skalan neznek azert messze sokkal kozelebb van a monolitikushoz mint a mikrokernelhez. En ezen is azt velem feldedezni hogy a Linux eseteben pl inkabb gyakorlati szempontok alapjan probaljak azt fejlesztni, mig pl a Minix az ugye tisztan elmeleti alapon lett mikorkernel, bar mondjuk ugye a Minix az tipikusan oktatasi celra szuletett, tehat nem feltetlenul fair az osszehasonlitas.

Hat miert irjak azt akkor? Mert megtehetik ui nem tudod ellenorizni. Mostmar erted miert utalom az m$-t? Mert hazudik ossze/vissza, nyomja a FUD-ot minden ellen ami nem m$ stb ...

Azt TELJESEN komolyan irtam fentebb (lentebb? ;-) valahol, hogy van egy egyetemeken tanito ismerosom akinek VAN hozzaferese Windows forraskodhoz es UNIX-ok eseteben sem hulyegyerek, es o mondta nekem hogy az m$ szerinti mikrokernel fogalom nem igazan fedi azt amit egy informatikai szotarban irnak errol, hanem amolyan "marketing ertelmezese a mikrokernelnek".

Mint leirtam errol ott is en NEM tudom eldonteni, mert en nem lattam nyilvan. Nekem mindig csak fenntartasaim vannak, mert az M$ legtobbszor NYILTAN a pofadba hazudik ... Lasd TCO cikkek, FUD-ok, stb stb. Ne mondd mar hogy ez NORMALIS viselkedes egy ceg reszerol ... Es akkor 1 ilyen ceg termekeben bizz meg? Ami zart forrasu, meg az sem tudod rola hogy mikrokernel/monolitikus (mivel csak az m$ dumajat KELL elhinned), es kb hany hw platformon is fut a WIndows? Szamoljunk csak! Hasonlitsuk ossze mondjuk a Linux-szal? Stb. Szoval erre mondom hogyha az m$-t valasztod, akkor le vagy kotve az M$-nel, a PC-nel, az M$ sajat megoldasainal, protokoljainal stb stb. Hat ha neked ez kell ...

En ERRE mondom hogy ez szerintem nem szabadsag ... Es talan nem hulye a vilag sok kormanya/szervezete stb, amikor pont ugyanezert hagy fel az m$ termekekkel: a szabadsag hianya, a tulzott elkotelezettseg EGYETLEN ceg mellett (UNIX-oknal azert nem EGY darab ceg van ugye), stb.

Tudod, az az igazsag hogy NEM mondhatom el hogy nincs igazad ... Attol hogy a Linux mellett alltam itt a flame-ben nem vagyok teljesen vak abba az iranyba, hogy a Linuxnak volt/van/lesz sok betegsege. Foleg az, hogy a Linux eretdetileg nem lett megtervezve. I mean, Linus elprogramozgatott, masok is beszaltak, es mindenfele koncepcio nelkul (marmitn az elejen!) olyan lett amilyen. Ahogy en latom az a fogalom KESOBB kezdodott, amikor probaltak kisse atgondoltabba tenni az egeszet es ez mar jo ideje tart. Ahogy en latom jo fele tartanak.

De ezt legalabb latod, vizsgalhatod stb. Windoze eseten SEMMIT nem tud egy atlag ember, hisz hol a forraskod? Azt kell elhinned/hasznalnod/stb amit az M$ akar. Nincs mas lehetoseged nagyon ... En ebbol a gondolatbol kiindulva irogattam, nem abbol hogy "Linux az isten a tokeletesseg, es a Windows a szemetesvodor alja". Ez azert tulsagosan elvakult hozzallas lenne barki reszerol. Imho.

Passz. Nem ismerem, kb annyit tudok rola hogy van egy neutrino (?) nevu mikrokernele, es vmi real time oprendszer. De ennyi volt, tehat erdemben nem tudok beleszolni ... De nem hinnem hogy szerver OS lenne igazan, ami tobb tucat hw platformon fut, es nyilt forraskodu megoldas. Szerintem a QNX specialisabb, nem "altalanos celu" szerver OS azert ... De javitsatok ki, nem szeretnek hulyeseget irni ...

Az ... M$ bedobja a marketingfogaskent hogy "nem kell reboot patcheles utan". De _NE_ akard tudni hogy oldjak meg, mert szivrohamot kapsz. Tipikus m$ hozzaallas szerintem azert KELL a nyilt forraskod hogy ennyire gany dolgok ne legyenek mar. FELTEVE ha igaz hogy igy oldottak meg, ha nem akkor sorry, nem szoltam :)

Azt hiszem te allandoan csusztatsz itt az m$ megszallottsagod miatt.

Ha ha, igen. Én vagyok az "m$" megszállott, te meg az anti-"m$" slashdot hippi. :))

Az m$ SOSE hasznal standard megoldast, szomoru vagyok ha ENNYIRE vak es napellensoz vagy ...

A szemellenzős te vagy, drága barátom. Amiket én felsoroltam (Kerberos, RDP) szabványosan használt megoldások a Windowsnál is. A többi anti-"m$" hitgyülekezetes barátoddal nyugodtan beszéljetek badarságokat, szerencsére egy komolyabb cégnél a vezetőség nem az ilyen véleményekre alapoz.

Jee, Jedlikes vagy? Megvan meg az a cuki Linux fw ott? ;-)

Nade. Szerintem a flame mar reg nem arrol szol, hogy grsec v nem grsec, hanem alapveto DESIGN beli megfontolasokrol (mikromonolitkus kernel) meg nyilt forraskod zart forraskod.

az MS-nek jo szokasa ui., hogy tobb cuccot javitanak egy patch-ben, mint amit elismernek, a dolog kb. ugy mukodik, hogy ami mar nyilvanos, azt megemlitik, a tobbit meg fu alatt

Ugye nem gondolod komolyan, hogy ez csak az MS-nel van igy? Az Opensource fejleszteseknel ugyanez a helyzet... "mindenhol soprik a sz*rt a szonyeg ala" ;)

speciel a grsec nem ved meg ezen hibak ellen (legalabbis a DoS ellen), max nehezebbe teszi tenyleges exploit (nem DoS) irasat/vegrehajtasat (de azt is csak akkor, ha jol van konfiguralva, pl. KERNEXEC bent van).

igazad van, csak van egy kis kulonbseg: az MS-nel (meg hasonlo cegeknel) ugy soprik a szonyeg ala a bugokat, hogy tudnak roluk es megis hazudnak. (az en tapasztalataim alapjan) az open source-nal leginkabb az tortenik, hogy normalis fejlesztes soran idonkent kihasznalhato bugokat is fixalnak, csak eppen nem realizaljak a dolog horderejet es nem lesz belole csinnadratta (ami persze nem jo dolog, mert azt mutatja, hogy rossz a programozok szemlelete, de legalabb a felhasznaloi kozonsegnek nem kell teljesen vakon kovetni a fejlesztoket).

A QNX-el mi a helyzet?

Teljesen jó, nekem most is fut az egyik gépemen egy QNX 6.3.

Aki eddig csak Linuxot látott annak furcsa lehet, de az ős Unix parancsok működnek rajta rendesen. Van rá egy szép, letisztult grafikus felület is (Photon), amely a Longhorn felépítéséhez hasonlít (van tálca, az ablakokon minimize, maximize, close gombok, az asztal jobb oldalán pedig load kijelző, memória használat, stb.). Működik vele az Intel gigabites hálókártya, az ATI Radeon videokártya és egy rakat opensource program letölthető hozzá (Mozilla pedig alapból van hozzá).

[troll]

Mitől van az, hogy többé nem fáj a fejem a havonta kijövő legújabb local/remote linux DoS miatt?

Gyanítom azért mert OpenBSD-t használok. :)

Függetlenül ettől.

Nekem ötletesnek tűnik az, amit fent leírtak, hogy hogy műxik.

A bajom avval van, hogy egyszerűen nem képesek számon tartani saját házuk táján belül, hogy mi hogy merre, meddig, és pl. ha nem használok tartományvezérlőt, hanem munkacsoportokba teszem a gépet, és meg akarom változtatni a munkacsoport nevét, akkor meszeltek az egésznek... Reboot... (Na jó, ez XP-n áll... 2003-at nem teszteltem....)

De még ma is kiscsillió program kéri a telepítése után, hogy indítsuk újra...

De mondok jobbat: ma beraktam egy felírt lemezt a meghajtóba. (Linux alatt írtam ofkóz)

Azt már megszoktam, hogy bizonyos lemezeket vhogy úgy reagál le, hogy a könyvtárlista első elemét mutatja csak meg, és abba ha be akarnék lépni, akkor azt mondja, hogy a hozzáférés megtagadva.(Adminisztrátori jogkörrel rendelkező felhasználónak!!!)

Nade az egyik hasonló módon írt (adat+joliet+rr) lemezzel ezt játszotta el: a total commanderből, a sajátgépből, és gyakorlatilag mindenből eltűnt a DVD-olvasó. Csak lestem, hogy ilyet még nem szoptam :-) Azt persze nem tudom, hogy tud egy laptopból "eltűnni" a CD/DVDolvasó :-) De természetesen a reboot megoldotta... (Teljes rebootról beszélek, a megszokott hibernálás + vissza nem jó+!"%!+"/ )

> Az Opensource fejleszteseknel ugyanez a helyzet... "mindenhol soprik a sz*rt a szonyeg ala" ;)

Te hunger! Komolyan mondom csípom a búrád! Nálad jobb ellenérvet nehezen találni, ha windowsról akarnék embereket lebeszélni! :-) Már csak egy negrót kéne a szádba adjak, és világítanál! :-)

És már tudom is, hogy az első dolog amit megvilágítanék veled, az az lenne, hogy elmagyarázod nekem, hogy OS fejlesztésekben hogy tudnak vmit a szőnyeg alá söpörni, mikor bármely két release között tudsz diff-et csinálni, általában részletes changelog készül a változásokról, vagy akár minden egyes apró változást végigkövethetsz szinte bármely projekt verziókövető rendszerében, mert ma már szinte mindnek van publikus cvs/svn/egyéb elérhetősége...

Max. annyi lehet, amit PaxTeam ír fentebb, hogy nem mérik fel egy változás horderejét, és nem csinálnak belőle csinnadrattát...

De attól még a changelog-ból nem szokás kihagyni azt sem...

On 2004-12-18, Pásztor György <pasztor@linux.gyakg.u-szeged.hu> wrote:

> De még ma is kiscsillió program kéri a telepítése után, hogy indítsuk
> újra...

Gondolom, megszokasbol, "artani biztos nem art alapon", vagy mert nem
akarnak bajlodni (meg)egy Windows verzio szerint switchelo "case" tipusu
elagazas berakasaval a setup programjukba.

De nem azert mert >=WinXP-n ez technikailag kene... foleg ha nem rak fel
drivert a setup, ami azert az esetek tobbsege.

(Mindez csak guess, nem vagyok Win expert...

> e most amikor szabvanyos Kerberost hasznal,

Most kezdek lefordulni a téma olvasásakor a székemből a röhögéstől...

Én nem ittam semmit. Hunger! Biztos, hogy te se?! :-)

> ha maga teremti a szabvanyt az a baj,

A szabványokról még annyit megsúgnék, hogy azok nyíltak, hogy biztosítani tudják a kooperáció lehetőségét. Az M$ pedig pont ezt nem akarja, mert akkor vele kompatibiliset is tudna csinálni akárki, és akkor lehetne a saját programjaival "szabványteremtésével" szemben alternatív megoldásokat csinálni. És akkor mindjárt sokkal nagyobb lenne a piaci választék. Ez pl. kifejezetten az office dolgok terén tud idegesíteni, főleg akkor, amikor egy két soros levelet .doc csatolmányként küld el nekem az "igen tisztelt" kolegina... Mert sokan azt sem tudják, hogy pl. az M$ Officeon kívül is van élet... Pl. amikor vki. nekem avval jön, hogy az OOo sz@r, mer', nem kompatibilis teljesen a M$ Office-szal pl. a makrói terén, akkor legszivesebben a kezébe adnék egy fa-testápolót, magamhoz is vennék egyet, és mondanám neki, hogy ok, akkor ezt most menjünk es az M$ fejlesztési részlegének is meséljük el :-)

Elvégre a táncoslábú megmonda: divelopörz, divelopörz, divelopörz... Nekik aztán tényleg van belőlük, és tényleg azt csinálják, amit a főnökség mond nekik: inkompatibilis termékeket...

És most, hogy így elgondolkodom, ehhez tényleg sokkal nagyobb programozói teljesítmény kell, mint ha vmi. olyat akarnánk alkotni, ami aztán mással is képes lenne együttműködni...

Win expert én se vagyok...

DE! A windows programok közt hányat láttál már olyat, amelyiknek saját telepítője volt, és nem a szokásos M$ telepítő részeket használta, és nem a saját M$ féle .dll-eket, stb...???

Magyarul, ha jól van kitalálva, akkor csak a megfelelő rendszerhez tartozó .dll-ben kellene simán lekezelni rendesen a dolgot, hogy most csinált-e a telepítő olyan elmeháborodást, ami miatt kell reboot.

On 2004-12-18, Pásztor György <pasztor@linux.gyakg.u-szeged.hu> wrote:
>
> Win expert én se vagyok...
>
> DE! A windows programok közt hányat láttál már olyat, amelyiknek saját
> telepít?je volt, és nem a szokásos M$ telepít? részeket használta, és nem a
> saját M$ féle .dll-eket, stb...???
>
> Magyarul, ha jól van kitalálva, akkor csak a megfelel? rendszerhez tartozó
> .dll-ben kellene simán lekezelni rendesen a dolgot, hogy most csinált-e a
> telepít? olyan elmeháborodást, ami miatt kell reboot.

Mittomen az adott telepito pontosan mely dll-eket hasznalja... Attol meg,
hogy mashogy neznek ki, v. kicsit mas az interfesz felepitese, akar
hasznalhatjak ugyanazon dll-eket backendnek, nem?

Es honnan tudod, hogy nincs jol kitalalva, mar ami az XP-t illeti? Ha
meg Win98-ban nincs ilyen dll, akkor az unblock (minden 32 bites Windozon,
esetleg '95 kivetelevel) "jol mukodes"-t mar cseszheted...

Asszem az M$-nel egy lecket jol megtanultak: azt, hogy a szoftverfejlesztes
olyan mint a szex -- ronstd el egyszer, nyogod a terhet egesz eletedben
(bocs, ha szakallas, de legalabb adekvat).

dzsekijo írta:
>
> Es honnan tudod, hogy nincs jol kitalalva, mar ami az XP-t illeti? Ha
> meg Win98-ban nincs ilyen dll, akkor az unblock (minden 32 bites Windozon,
> esetleg '95 kivetelevel) "jol mukodes"-t mar cseszheted...
>

s/unblock/en bloc/ :-)

On 2004-12-19, Tímár András <timar@fsf.hu> wrote:
>
> s/unblock/en bloc/ :-)

Uh, kosz! Ezt az egyet speciel sose tudtam hogyan kell leirni... mindig csak
szoban hallottam.

Gabu, ez mondjuk elegge termeszetes, nekem meg azert nem faj a fejem az OpenBSD-s bugok miatt mert Linuxot hasznalok, vagy barmely mas kombinacioban is el lehetett volna ugyanezt mondani ;-P

Hardware-es mindenfele MMU es vedelmi mechanizmus nelkul ha hiszed ha nem KONYEBB mikrokernelt irni mint monolitikusat. Tekintve hogy ilyenekkel sokat foglalkoztam fejelsztes szinten ebben talan nem kene velem vitatkoznod. A nehezseg pont ott van hogyha BIZTONSAGOS OS-t akarsz es van ehhez mondjuk hw supportalt memoria vedelem lehetoseg meg egyebek akkor mar elesebb kulonbseg lesz azonnal automatikusan a kernel space es user space kozott, ezek hianyaban jobban osszemosodnak eleve a kulonbsegek a mikro es monolitikus kernelek kozott, legalabbis nemely tekintetben.

Ja. Csakhogy van egy HATALMAS kulonbseg, tudod? Ugyanis meg olyan igen NAGY kerdesekben is (tehat viszonyalag alapveto kerdes ugy ertem) hogy a Windows kernele milyen felepitesu, akkor te azt mondod, hogy http://www.microsoft.com..... . En erre azt mondom: es? Ha moricka azt irja a blogjaban hogy az, el kene hinnem? BIZONYITSD hogy az. Forraskodot kerek. Ennyit errol. Ez foleg az m$ eseteben igaz, ui ugye mar NEM eloszor fordult elo hogy visszaelt a zart forraskod jelleggel, es olyasmi is van software-eiben aminek a legtobb ember nem orul (informacio kiszolgaltatasa stb).

Plusz ha a windoze belsejeben valahol gany van, azt szeritned KI fogja javitani? De oszinten? Ki veszi eszre? Nezz be a linux-kernel levlistra ellenben, es nezd meg hanyszor latsz olyan kezdemenyezest ami arrol szol, hogy kb "fiuk, ez igy allati gaz, es ronda, elkezdtem ujrairni ...". Open source eseten TELJESEN legalabbis nem tudod a dolgokat a szonyeg ala soporni mert ott a forras! Pont ez a lenyeg! Probald meg ezt win eseten :) Eleve ezt se tudnad hol van a forraskodban valami es konkretan MI az amit ujra lehetne irni :) masreszt ha tudnad is, kivancsi lennek mit szolna az m$ ha patch-et kuldenel neki, meg levlistan elkezdened masokkal megbeszelni :)

Ja. "komolyabb" cegnel olyan nevetseges dolgokra alapoznak hogy a "windows mikrokernel felepitesu" amit meg azota se bizonyitottal ez az evezred egese, ocsem :) Ezzel kezdodott az egesz, szoval BIZONYITSD be hogy az! Ez teljesen logikus keres nem? Minden tudomany (az informatika nem tudomany?) arra epul hogy BIZONYITANI kell. Szoval tedd meg kerlek, varom a buzonyitekaidat :)

Na mi kovetkezik mindebbol? Elarulom. Az hogy szerinted a komolyabb cegek nem ez alapjan valasztanak, akkor ezek szerint a komolyabb cegek a fentiek ertelmeben NEM tudomanyos alapon val;asztanak hanem pl marketing alapon. Azaz: informatikai celra nem informatikai dontes (tekintve hogy az informatika alapvetoen tudomanyos alapu ugye) alapjan operalnak.

Aztan meg hat tudnek mondani par szerinted ezek szerint komolytalan ceget. Legalabbis azok, mert szerinted komolyabb cegeknel maskepp hoznak dontest.

Ja es meg valami. Erdekes, hogy minden Win megszallott elobb utobb atmegy szemelyeskedesbe (mint te), de konkret indokakat erveket nem tud felhozni. Ismet es utljara megerdezem: mikrokernel felepitesu a windows? Eleg egyszeru kerdes? Akkor valaszolj ra kerlek. De indoklast is kerek, az NEM indoklas hogy mert az m$ aszondta, mert pl az en nagymamam meg nem azt mondta. Akkor most dontetlen? :)

Masreszt ha a "mert az m$ azt mondta" dontes es hasonlok amikre hivatkozol szerinted mervado, akkor OK elismerem: kar tovabb flame-elni mert te marketing/uzleti stb sikon mozogsz en meg informatika/uzemeltetes/fejlesztes, tehat kar vitatkoznunk mert nem ertunk egymas teruletehez. Ha viszont nem ez az abra akkor normalis SZAKMAI erveket kerek szepen.

Szerintem ez ilyen egyszeru.

Ize, mielott ezt is felreerti valaki inkabb valaszolok maganak :) Szoval az OpenBSD-vel semmi bajom, sot pl firewall celjara szivesebben hasznalom mint a LInuxot, viszont az az igazsag - mar amennyire en latom -, hogy azert ha a specialisabb hardwareket (de akar egyeb dolgokat, filerendszereket/protokolokat/stb) jelento server es desktop esetekben EGYARANT ugy jar az ember, hogy a Linux sokkal jobb tamogatotsaggal rendelkezik.Ettol persze NEM az OpenBSD a *****, hanem az a nagy igazsag hogy sokkal tobben fejlesztenek Linuxot szoval teljesen ertheto a helyzet, sot szerintem ha az aranyokat nezzuk akkor csoda hogy az OpenBSD egyaltalan igy tud fejlodni ahhoz kepest hogy hany ember dolgozik a projecten osszehasonlitva a Linux kernelt ...

Szal 1 nagy respect pl az OpenBSD fejlesztoknek, de nyilvan mast is lehetne emliteni.

A lenyeg az hogy ezt itt gyorsan le akartam irni NEHOGY valaki azt mondja hogy nem latok a Linuxnal tovabb, mert itt alapvetoen nem a LinuxBSD vagy barmi mas volt a vita targya ugye, amely vitat pl kisse ertelmetlennek tartom.

Erről eszembe jutott az a régi Windows IGMP bug, amivel kékhalált lehetett előidézni és az, hogy mennyire le volt húzva a Windows akkor is, hogy ilyen hiba található benne... ;)

Gyu :) Tudom, hogy téged még lángvágóval se lehetne elszakítani a Linuxtól és az OpenSource gondolkodástól, de lásd már be, hogy egy user sem fogja nézni a diff-eket, meg a cvs-t meg a changelogot, max. az a néhány geek, akik közé te is tartozol. Egy átlag felhasználó nem fogja megnézni, hogy a fejlesztők mit változtattak a programjukon (vagy a kernelen, mert ugye arról beszéltünk), nem fogja megnézni a sima user azt sem, hogy milyen sort milyen sorra cseréltek át. Viszont azt elvárja, hogy ha egy kritikus hibát javítanak, akkor arra hívják fel a figyelmet.

Sajnos az OpenSource projecteknél sem kürtölik szét a fejlesztők, ha biztonsági hibát találnak, max. ha már a bugtraq-on van kinn a hír és reagálni kell rá.

A másik észrevehető dolog pedig az, hogy a szép csendben javított biztonsági hibához nem azt írják a Changelogba, hogy "IGMP subsystem have remotely exploitable flaws", hanem, hogy "IGMP source filter fixes", amiből aztán abszolút nem tudod, hogy mennyire kritikus hibát javítottak.

Én az ilyen problémákról beszéltem, nem pedig arról, hogy meglehet-e nézni a változásokat vagy sem. Nagyon hülyének nézed a másikat, azt látom...

Következő linux konfon meg majd kérem a negrót a számba, rólad meg leveszem a szemellenzőt... ;)

A szabványokról még annyit megsúgnék, hogy azok nyíltak, hogy biztosítani tudják a kooperáció lehetőségét.

Ezzel mit szeretnél mondani? Melyik mondatom nem volt igaz? Nem szabványos a Windowsban lévő Kerberos vagy RDP? Akkor hogyan lehet Linuxon futó apache + mod_auth_gss_krb5 segítségével Kerberos alapú authentikációt összehozni Windows domain controllerrel? Véletlenül? Ebből nem az látszik, hogy "biztosítani tudják a kooperáció lehetőségét"? A Microsoft Office 2003 már XML alapú megoldást használ, talán az sem szabványos?

Jó lenne, ha a Linuxos közösség nem a Windows 95-öt venné alapul amikor a Windowst bírálja és nem az 5-10 évvel ezelőtti állapotok szerint bírálná a Microsoftot, mert jelenleg az MS igenis szabványos megoldásokat próbál használni és ha nincs egy adott megoldásra szabvány, akkor megteremti azt (akár más cégekkel közösen, lásd WPA).

Gyu, ne legyél anti-"M$" slashdot hippi...

BIZONYITSD hogy az. Forraskodot kerek. Ennyit errol.

ROTFL, ne legyél már ennyire nevetséges.

Ha lenne is forráskód, akkor sem te, Lénárt Gábor Felsőörsről tudnád megállapítani ránézésre, hogy mikrokerneles-e vagy sem... :))

> - Az emberek nagy resze nem hasznalja az IGMP-t, igy nem is forditja a kernelbe.

- Az emberek nagy resze egyaltalan nem fordit kernelt. ;)

> Magyarul egyprocesszoros gepen valoszinuleg nem mukodik, igy egy rakas gep elbol kizarva.

Ez a kijelentes csupan a "privilege elevation"-re igaz, DoS-ra nem.

Masreszrol tessek nyitottabban gondolkodni. Ihaquer nem azt irta, hogy egyprocesszoros rendszeren nem kihasznalhato a hiba, hanem hogy kell egy kis trukkozes ahoz, hogy azon is mukodjon. Egy tamado egyebkent se erre az egy hibara fog epitkezni...

"No good hacker just looks for one bug." - Halvar Flake

> - Harmadik kulonbseg, hogy mig itt orak alatt van javitas, ott joval tovabb tartott.

Lehet, hogy orak alatt meg van a javitas, de attol meg nem fogjak minden helyen fejvesztve lecserelni a jelenlegi kernelt. Arrol nem is beszelve, hogy ha ihaquer nem ir a kihasznalhato hibakrol advistoryt, akkor a kutya sem tudna roluk.

Egyebkent a Microsoft nem veletlenul figurazza ki a Linux eseten azt, hogy orankent kell kernelt forditani. Nagyon jo, hogy orankent kijonnek a hibajavitasok, de ki akar allandoan kernelt forditgatni es rebootolgatni (foleg egy mission critical rendszeren).

Akkor csak azt mond meg nekem, hogy az M$ _MIT_ csinal ilyenkor? Ui remek hogy fikazza a Linuxot hogy a hibajavitas miatt kernelforditas/reboot (bar mondjuk eleve "megfelelo" disztribucio eseten a disztributor nyilvan megteszi a forditast helyetted) kell, de ha Win* kernelben van hiba akkor ahhoz nem kell reboot? Vagy nem ertem, mit akartak ezzel mondani. Nem is olyan regen a winsux meg IP cim allitas miatt is rebootolando volt. Szal ez ongol az m$ reszerol, de nagyon. Szerintem.

Plusz errol jut eszembe: a kernel forditas ma mar nem kotelezo, hanem lehetoseg: a mai disztribuciok eseten kernel upgrade lehet ugyanaz csomagkezelovel mint barmely mas software komponens frissitese. Ha az m$-nek meg az a baja hogy itt te magad forithaTOD is, az meg azert nevetseges, mert ezek szerint az a bajuk hogy Linux eseten MEGTEHETI a user, meg egy atlag user csak varhat az m$-re de o maga nem fordithat windoz kernelt, mert nincs meg neki a forrasa, nyilvan.

Eleve a hozzaallasod megkerdojelezi a jozan itelokepesseget. Az ilyen "M$" es "winsux" megszolalasok egyertelmusitik, hogy teljesen mind1 milyen ervet hoznek fel szamodra, neked akkor is a Microsoft lenne a pokol, Bill Gates a satan es a Linux pedig a megvalto...

Erdekes, hogy minden Win megszallott elobb utobb atmegy szemelyeskedesbe (mint te), de konkret indokakat erveket nem tud felhozni.

LOL. Ha nem tünt volna fel, akkor te kezdted a személyeskedést azzal, hogy "M$ megszállottnak" meg "napellensoz"-nek hívtál, bár ez utóbbi nem is tudom mit jelent... ;))

az NEM indoklas hogy mert az m$ aszondta, mert pl az en nagymamam meg nem azt mondta.

Ehez a hozzászóláshoz már tényleg csak gratulálni tudok. :) Persze, tudom, mutassak forráskódot! Okos.

mert te marketing/uzleti stb sikon mozogsz

Hú, hát te nagyon ismersz engem! :)))

Mert mindenkinek a sajat kedve szerint forditott kernelhez eleg nehez lenne kesziteni egy univerzalis hotfix patchet amely minden esetben tokeletesen mukodik es nem csinal sosem rendszer osszeomlast. Kisebb mesterseges intelligenciara lenne szukseg, igy egyszerubb megoldas az ujraforditas + reboot ;)

Egyebkent a Windows 2003-hoz nemsokara megjeleno Service Pack 1 mar ugy fog telepulni, hogy nem lesz szukseg a szervereken ujrainditasra.

En mar elegge unom, hogy minden honapban egy vasarnap estembol azzal toltok 2 orat, hogy bemegyek a ceghez, kernel forditok, rebootolok, es minden szolgaltatast ellenorzok. Es ezt persze az osszes szerveren...

Raadasul elvileg ezt meg kene tennem most is a pre2-vel es ha kijon az uj akkor a veglegessel. Illetve hogyha kijon hozza a grsecurity patch akkor azzal is.

Kovetkeztetes: Mivel tavolrol nem vagyok sebezheto, ezert majd akkor fogok kernelt cserelni, hogyha kijon a vegleges 2.4.29 + hozza a grsecurity (+par nap).

Es remenykedem hogy a local usereim jo fiuk lesznek, illetve hogy nincs a rendszerben egy rosszfiu aki mar regebben szerzett local accot csak root-ot nem...

Ti hogy csinaljatok?

> Ezzel mit szeretnél mondani? Melyik mondatom nem volt igaz? Nem szabványos
> a Windowsban lévő Kerberos vagy RDP? Akkor hogyan lehet Linuxon futó apache
> + mod_auth_gss_krb5 segítségével Kerberos alapú authentikációt összehozni
> Windows domain controllerrel?

Gondolod, hogy csak akkor lehet két rendszert összehegeszteni, ha
mindkettő szabványos? Ha igen, akkor súlyosan tévedsz. Ha nem, akkor ez
esetben az, hogy az Apache-Kerberos-AD authentikáció összehozható, nem
érv amellett, hogy az MS Kerberos megoldása szabványos lenne.

> "biztosítani tudják a kooperáció lehetőségét"? A Microsoft Office 2003 már
> XML alapú megoldást használ, talán az sem szabványos?

Miért? Az? Az XML önmagában csak egy konténer. XML-hez baromi könnyű
igazodni, mert azon belül még bármit elhelyezhetsz, teljesen egyedi,
akár bináris típusokkal, amit viszont nem mondasz meg, hogy milyen
felépítésű.

--
--- Friczy ---
'Death is not a bug, it's a feature'

Szervernek !x86-ot hasznalok, es remenykedem hogy a script kiddieknek alphara nincs exploitjuk, mert "ugyis mindenki x86-ot hasznal" :]

probalj meg minnnel kevesebb serveren lokalis usereket tartani, es akkor a helyi root hibakra nem kell _allandoan_ odafigyelni _minden_ szerveren. ennyi konnyites belefer. egyebkent meg nemhiszem, h tudsz mast tenni ;-)

> Jaja, mert a Windows-t nem kell ujrainditani soha. :-D

Hat megkockaztatom, hogy egy Windows 2003 szervernel mostanaban kevesebbszer kell mar rebootolni egy hibajavitas utan, mint ahany Linux kernel bug jon ki... (Fentebb irtam mar, hogy pl. az SP1-nel sem kell majd ujrainditani a szervereket).

amit meg azota se bizonyitottal ez az evezred egese, ocsem :)

Én felmutattam 3 dokumentációt is, melyben a Microsoft micro-kernel felépítésűnek írja a Windows rendszerét. Ez mindenesetre nagyobb bizonyításnak tűnik, mint hogy te azt mondod, hogy "az én nagyanyám meg azt mondta, hogy nem az". Az évezred égése te magad vagy. ;)

Ha akeppen tekintunk a bugra, hogy DoS sebezhetoseg, akkor az architekturatol fuggetlenul kihasznalhato.

Najah. Viszont olyat sem teszek a kernelbe, amit nem hasznalok, igy pl IGMP DoS-ra sem vagyok sebezheto...

Az meg szinten hozza kell tenni, hogy ami x86-on DoS, az lehet hogy alphan nem. Pl integer overflow-k egy jelentos resze alphan igen-igen nehezen idezheto elo.. (Ebben az esetben speciel nem neztem meg, hogy alphan mennyire lehet elohozni; ha sebezheto lennek, akkor persze megneznem, de igy van jobb dolgom is)

Ezen megnyilvanulasod inkabb azt mutatja hogy nem tudnal ellenervet felhozni. Ciki ;-) Amugy nagyon egyszeru a dolog. Nyilvan az Windows-ban erlofordulo hibakat is ugyanugy forraskodot erintve javitjak. Nyilvan emiatt ujra is forditjak a windows bizonyos reszeit. Tehat SEMMI kulonbseg nincs itt WIndows es Linux kozott, csupan az hogy win eseten a vegeredmenyt latod (binaris "patch"-ek, SP-ek stb) mig Linux eseteben lehet hasonlo (disztributor kiad uj csomagot, ami lehet akar a kernel is), viszont itt meg PLUSZ megvan a lehetoseged, hogy mondjuk te csinald mert a forraskod is megvan. Szoval neveteges ha EZ az Microsoft szerint hatrany hogy megvan ua mint naluk csak meg pluszban van ezen kivul is jo par lehetoseged. Es most idrekt kerulni kivantam a sux es hasonlo szavakat mert ITT legalabbis nem feltetlenul az a lenyeg, bar ha a Microsoft ilyeneket allit (ami valotlan) akkor az megtevesztes, es akkor tenyleg Bill Gates a gonosz ;-)

Amugy egy dologban tenyleg fontos felfedezni egy tanulsagot: mindennek ara van. HA windows-rol beszelunk ahol pl csak annak gyartoja (Microsoft) altal kiadott pl kernel van, akkor mindenkinek a kernele ugyanaz (marmint ha egy verziot hasonlitunk ossze nyilvan), tehat akar binaris szinten is meg lehetne patch-elni. ALTALABAN Linux eseten EZT nem lehet megtenni, tekintve hogy van rengeteg disztribucio, arrol nem is beszelve hogy megint masok meg sajat maguk forditanak kernelt. Viszont nyilvan a szabadsagnak ara van, ha valaki EMIATT szidja pl a Linuxot az ugyanakkor fatalis baromsag, mintha azt mondana, hogy le a demokraciaval, mert ott nem egy kozponti akarat ervenyesul (mint pl a diktatura eseten). Szoval ha igy nezzuk vagy ugy nezzuk az sokat szamit nyilvan de nem szabad arrol sem megfeledkezni hogy tokeletesseg mint olyan nincs, csak afelo torekvo megoldasok esetleg. En pl a demokracia mellet szavazok meg akkor is ha tudom: a szabadsagan megvan a maga ara amit esetleg egy diktatura hatranykent probal lekommunikalni.

Nagy Gergely wrote:
> Az meg szinten hozza kell tenni, hogy ami x86-on DoS, az lehet hogy alphan
> nem. Pl integer overflow-k egy jelentos resze alphan igen-igen nehezen
> idezheto elo.. (Ebben az esetben speciel nem neztem meg, hogy alphan
> mennyire lehet elohozni; ha sebezheto lennek, akkor persze megneznem, de
> igy van jobb dolgom is)
Én sebezhetetlen vagyok mindennel szemben:
bra@japan[~]$ kldstat
Id Refs Address Size Name
1 15 0xc0400000 343aac kernel
2 2 0xc0744000 1d4fc sound.ko
3 1 0xc0762000 5844 snd_ich.ko
4 1 0xc0768000 6be8 umass.ko
5 4 0xc076f000 29190 usb.ko
6 1 0xc0799000 fffc geom_mirror.ko
7 1 0xc185a000 6000 geom_bde.ko
8 1 0xc188b000 6000 linprocfs.ko
9 2 0xc1891000 6000 pseudofs.ko
10 1 0xc18a7000 17000 linux.ko
11 1 0xc18c4000 5000 procfs.ko
12 1 0xc2000000 60D iddqd.ko

lgb wrote:
> Amugy egy dologban tenyleg fontos felfedezni egy tanulsagot: mindennek ara
> van. HA windows-rol beszelunk ahol pl csak annak gyartoja (Microsoft) altal
> kiadott pl kernel van, akkor mindenkinek a kernele ugyanaz (marmint ha egy
> verziot hasonlitunk ossze nyilvan), tehat akar binaris szinten is meg
> lehetne patch-elni. ALTALABAN Linux eseten EZT nem lehet megtenni, tekintve
> hogy van rengeteg disztribucio, arrol nem is beszelve hogy megint masok meg
Mégiscsak el....ta Linus. Mikrokerneles architektúrát kellett volna
használnia.

Mennyivel egyszerűbb lenne az élet:

apt-get install kernel-igmp

és már kész is, javítva a kernel hiba. :)

"...kiveve azt a kulonleges esetet, ha az On IP cime szamokat is tartalmaz. Ebben az esetben kerjuk inditsa ujra a szamitogepet."

;)

> Egyebkent a Windows 2003-hoz nemsokara megjeleno Service Pack 1 mar ugy fog
> telepulni, hogy nem lesz szukseg a szervereken ujrainditasra.

Viszont a jelenleg megjelenő _userspace_ javítópatchek telepítése után
még mindig rebootolni kell. De valóban jó lesz, ha egy service pack
telepítése már nem jár automatikusan reboottal.

--
--- Friczy ---
'Death is not a bug, it's a feature'

Friczy wrote:
> Viszont a jelenleg megjelenő _userspace_ javítópatchek telepítése után
> még mindig rebootolni kell. De valóban jó lesz, ha egy service pack
> telepítése már nem jár automatikusan reboottal.
A miértet is tudja valaki? Tehát azért nem kell újraindítani, mert:
- nem volt módosítás a kernelben
- volt, de a változtatást a futó kernelen végzi el
- volt, nem változtat a futó kernelen, csak a következő újraindításkor
(effektíve addig a user bár patchelt, de nem védett)

Melyik?

"Ezen megnyilvanulasod inkabb azt mutatja hogy nem tudnal ellenervet felhozni. Ciki ;-)"

Igy van, annyira eros jellem vagy hogy szohoz se jutok az erveleseid utan.

"Tehat SEMMI kulonbseg nincs itt WIndows es Linux kozott"

Te olyan alapveto kulonbsegeket hagysz figyelmen kivul, mint hogy a Windows alapvetoen micro kerneles felepitesu, a Linux pedig monolitikus. Barmennyire is hihetetlenul hangzik a windows eseteben a hibak joreszet a futo szolgaltatasokban talaljak, nem pedig a kernelben (magyarul nincs annyi kernel bug, mint Linuxban). Ennek kovetkezteben elmeletileg joval kevesebbszer kell egy hibajavitas miatt ujrainditani a rendszert. Az mas kerdes, hogy eddig (a konyebb utat valasztva) jonehany patchet ugy keszitett el a Microsoft, hogy az reboot utan keruljon telepitesre, de mint fentebb mar emlitettem ez mar a mult, a Windows 2003-hoz nemsokara megjeleno Service Pack 1 ujrainditas nelkul lesz telepitheto.

A Microsoft pedig nem azt allitja, hogy a Linuxnal a forrasbol valo telepites rossz dolog (bar egy atlag felhasznalonak nehogy mar ehez kelljen ertenie), hanem, hogy egy ilyen bug miatt egybol uj kernelt kell forditgatni es sokan - mint ahogy te is - ezt meg szinte pozitivumkent is ertekeli.

Na ez a lenyeg! Koszi bra ;)

Na, leallitom magam a flame-rol, mert az mondjuk igaz, hogy gaz ugy flame-elni ha az ember nem erzi sajatjanak azt a teruletet amirol a flame folyik ;-) Nevezetesen arra gondolok, hogy a Windows belso felepitese pontosan milyen. Amugy van egy ismerosom akinek teljes betekintese van Windows forraskodjaba, tobb egyetemen tanitott, illetve a UNIX vilagban is otthon van, es annyit hallottam tole, hogy "a Microsoft mikro kernel forlamanak ertelmezese egy vicc, es semmi koze ahhoz amit mikro kernelnek hivnak definicio szerint, inkabb monolitikus az is".

Most en nem akarom eldonteni hogy mi az igaz es mi nem, tekintve hogy nem lattam windows forraskodok es nem is valoszinu hogy fogok, mint foldi halando :)

Azzal viszont nem ertek egyet amit arrol allitasz, hogy "bug miatt egybol uj kernelt kell forditgatni es sokan - mint ahogy te is - ezt meg szinte pozitivumkent is ertekel". Ugyanis ez szerintem IGENIS elony! A Linux eseteben IGAZ, hogy a sokak altal szidott "nem stabil API, nincs binaris kompatibilitas kernel szinten" stb megnyilvanulasoknak VAN alapja, de pont ez az amiert a Linux dinamikusan fejlodik: nincsen hozzakotve ahhoz hogy neki kotelezo lenne a binaris kompatilitas. Ez megint az a tema, hogy a szabasagnak ara van, nyilvan ... De nekem pont ez tetszik es ez igenis elony szerintem, barmennyire nem erted. Ez megint ugyanaz amikor a demokraciat es a diktaturat hasonlitjuk ossze. Kell valami valtozast eszkozolni? Ditkatura -> egyszeru, diktator meghozza a dontest, kesz. Rovid ideig tart, olcso megoldas. Demokracia? Meg kell targyalni, egyeztetni, esetleg nepszavazni ... stb stb. Sokaig tart es sokkal dragabb. Megis hol szeretnel elni? Demokraciaban vagy diktaturaban?

Akkor se csinalhatnad meg egykonnyen ha a Linux kernel mikrokernel felepitesu lenne, mert a Linux ellentetben a Windows-zal _NEM_ egy termek. A legtobben hasznalunk ilyen/olyan disztribuciot amiben alapobol eleve nemcsakhogy mas verzioszamu kernelek vannak,

hanem azok is patch-elgetve vannak, stb.

De en ezt AKKOR IS elonynek fogom fel, mert maximum nyilvan ugy hozhato ki a rendszerbol ha nem kell merev hatarokhoz tartani magunkat, mert egy mikokernelnel ugye RENGETEG overhead van amiatt hogy vegulis "monolitikus ertelemben" egy csomo egymassal kommunikalo processzbol all az OS, amelyek a mikrokernel "alatt" futnak. Namost, ez rengeteg overhead-et es bonyolultsagot visz a rendszerbe, es legalabbis amennyire en tudom, manapsag is

azt valjak legtobben hogy a mikrokernel szep dolog ELMELETILEG csak gyakorlatilag *****, illetve legtobb ilyen dolog amolyan "meg kutatas targya" feeling korbe tartozik, ahogy en latom.

De ha kell hasznalj L4 mikrokernel ala portolt Linuxot vagy barmi mast ;) Megint ugyanarrol beszelek: itt a szabadsag mindenki azt haszal es azon amit akar, vagy portolja ha tetszik, de igy legalabb nincs ahhoz kotve hogy az van amit a Microsoft akar.

Persze, ismet leirom: a szabadsagnak ara van. Nyilvan ...

Viszont eddig legalabbis minden nagyobb innovacio a szabad forraskodbol fakadt (ha nem is mindeig kozvetlenul mondjuk) ilyen a legtobb vivmany amit szinte minden OS hordoz es a UNIX-bol szarmazik (a konyvtarszerkezet fogalma vagy a file deszkriptorok szemben a regi CP/M-es megoldasokkal), vagy maga az Internet kulcsfontossagu fogalmai es protokoljai stb ...

Ebbol a szempontbol en igenis "gononsznak" tartoma az M$-t mert szeretne monopoliumra torokedni, es ugy kifejleszteni sajat dolgokat hogy masoknak lehetosege se legyen veluk egyuttmukodo software-eket csinalni ...

Kisse bonyi mar a thread szerkezet, szoval ide irok :)

Tehat tisztazaskeppen: *NEM* az a bajom a Wingyozzal, hogy Wingyoz, vagyhogy az M$ irta, stb. A bajom az vele, hogy nem nyilt forrasu, az m$ mindent megtesz a kooperacio ellehetetlenitesere mas platformokkal stb ergo hihetetlen mertekben korlatoz a szabadsagban.

Nekem nyilt forraskod kell, kooperacio lehetosegese, eshogy lehetoleg standard megoldasok legyenek hasznalva. En ezt nevezem szabadsagnak. Es az nyilvanvalo viszont hogy ennek megvan az ara viszont. Amint kifejtettem mar fentebb.