Torvalds a Vista-ról és a Mac OS X-ről

Vélemény

Linus múlt héten látogatást tett Ausztráliában, aholis a Melbourne-ben rendezett linux.conf.au rendezvényen járt. Egy interjúban felkérték, hogy mondjon véleményt az Apple Mac OS X vs. Microsoft Windows Vista kérdésben. Linus szerint a Mac OS X "Leopard" - a Mac OS X legfrissebb, 10.5-ös verziója - sokkal jobb operációs rendszer. De emellett, Torvalds szerint az OS X bizonyos szempontból rosszabb Vista-nál. A Linux kernel atyja szerint az OS X filerendszere teljesen rossz. A cikk itt olvasható.

( Emulgeator | 2008. 02. 06., sze – 10:52 )

Let the flameWar begin!
------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!

( Emulgeator | 2008. 02. 06., sze – 10:57 )

De ha nem kerik fel is alkothat velemenyt barmirol, bar nyilvan azert nagy felelosseg, mivel sok elvakult linux hiv vakon is ad a szavara, en nem kerdojelezem meg amit mond, mivel nem ismerem az OSX-et, de a Vistat sem, viszont nem is fogom fel bibliakent. De az tuti hogy sok embernekszurja ez a szemet az Apple fanatikusok kozul, es sok sok helyen baromi nagy flamek lesznek belole.

------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!

+1

Ha (elég rendesen) sarkosítva lefordítom a mai gépekre, akkor a C64 a Windows (minden suliban az volt), a ZX meg az altenatív :))))))

Utólagos hozzáírás: nem azért, de tök rossz helyre került a válaszom, hiszen én a ZX-re nyomtam (kertes-re válaszolva).....

( kikke | 2008. 02. 06., sze – 11:33 )

A Linux jobb mint az OSX? Ha igen, melyik Linux? A Vista meg az OSX elég konkrétak a Linux ideájához képest.

A Linux kernelről van szó mint operációs rendszerről.
Ha a kernelt portoltuk egy gépre, akkor gyakorlatilag akármelyik disztribúciót rá lehet rakni.
Egy másik hírportálon bővebben volt a dologról szó. Linus azt mondta (állítólag), hogy az oprendszernek az átlag felhasználó felé nem is kellene látszódnia, azaz az a dolga, hogy a felhasználói programok fussanak rajta.
A grafikus felület pedig ugyanolyan program, mint a többi. Ezért nem tetszik neki a Vista és az OSX, mert ott egy operációs rendszerként árulják, ami nem az, és szerinte ennek nyilvánvaló gazdasági okai vannak.
Az OSX-re még azt mondta, hogy sz.r a fájlrendszere. Erre én pl. nem tudok mit mondani, sose volt vele dolgom. :)

Nu ja... felrakok egy Ubuntut és pünkt úgy bejön a grafikus rendszer mint a vindózban. Látszólag. És pont ez a lényeg, erről beszélt Linus. Maga az oprendszer a *NIX rendszerekben valójában független a grafikus héjtól, csak a user ezt nem látja.

Jelen pillanatban 4-5 féle kernellel (inkluzive Solaris), 20-30 disztribúcióval tudsz úgy rendszert installálni, hogy bekapcsoláskor ugyanaz a Gnome desktop néz szembe a userrel, megy rajta az OpenOffice.org és annyit nem kell bepötyögnie a usernek, hogy startx...

Magyarul a felhasználói felület és az oprendszer teljesen független egymástól. És akkor még nem beszéltünk arról, hogy vindózra is felrakhatsz egy X szervert és bejelentkezhetsz vele egy távoli gépre.

Linus a kernelrol beszelt. Szamra az az Operacios rendszer.
"
To kind of explain what Linux is you have to
explain what an Operating System is
And... the thing about Operating System is
you, I mean...
you're never ever supposed to see it.
Because...
nobody really uses an Operating System,
people use... programs... on their computer
And the only mission in life
of an operating system is to help
those programs run.
So an operating system never does
anything on its own
It's only waiting for the programs to
ask for certain resources or,
or, ask for a certain file on the disk
or ask for the programs to
connect them to the outside world.
tries to make it easy for people
to write programs.
"

Én használok OSX-et, Vista-t és olykor linux alapú operációs rendszert többnyire GNOME-mal. Az első kettő sokkal jobban "összecsiszolt" rendszert alkot, mint a harmadik. Ez az érzés alapvetően akkor alakult ki bennem, amikor valamit be akartam állítani, konfigurálni. Linux alapú rendszereknél sokkal több időt kellett a rendszer beállítására szánni sokkal több utánolvasással, google nyúzással. És sokkal többször találkozni olyan problémákkal, amit az adott disztribúcióban található alkotóelemek adott verzióival éppen nem lehet megoldani, de majd a következővel (vagy az azutánival) igen. (példákat nem sorolok, nem akarok bizonyítani semmit)

Ave, Saabi.

Hja. Mivel gnome altalanos celu desktop kornyezet nem csak Linux kernel/miegymas fole, hanem egy rakat mas rendszer felett is, nyilvan nem lehet akarmennyire osszehozni mert akkor mar nem lenne hordozhato vagy teljesen Linux specifikus lenne. A hordozhatosagnak is van ara, marmint egy adott celrendszerre osszecsiszolt valami az valoszinu jobb lesz azon az egy celon, mint egy altalanosabb celu. Persze javitani itt/ott azert mindig es minenhol lehet ettol meg ...

Ez így van én arra próbáltam válaszolni, hogy:

A grafikus felület pedig ugyanolyan program, mint a többi. Ezért nem tetszik neki a Vista és az OSX, mert ott egy operációs rendszerként árulják, ami nem az, és szerinte ennek nyilvánvaló gazdasági okai vannak.

Miszerint a Vista és az OSX esetében a grafikus felület nem olyan program mint a többi, sokkal jobban integrált, mint linux alapú operációs rendszerek esetében bármely desktop kezelő. Vagy ha nem is integrált, mindenesetre az operációs rendszert és a grafikus felületét egyszerre, egymásra hatva fejlesztették. Míg a linux, a gnu tools, az X és a desktop/window managerek között nem látok hasonló egymásrautaltságot, összecsiszolást.
(Persze ez csak az én véleményem és természetesen tévedhetek is.)
Amit én a "linux-os" megközelítésből hiányolok, az a rendszer beállítási lehetőségeinek mélysége. Ismereteim szerint a Vista "Control Panel"-jén vagy az OSX "System Preferences" alatt sokkal több beállítási lehetőséget találok mint a GNOME vagy a KDE megfelelő felületein (sajnos ezek nevére nem emlékszem). Talán kivételt képez a YaST, igaz az nem a desktop manager része, de ez talán nem feltétel.
Persze tudom, hogy az OSX és Vista esetében is vannak olyan "advanced" beállítások amire a GUI nem ad megoldást, de talán kevesebb mint a linux disztribúciók esetében. Vagy legalábbis több "triviális" beállításra adnak lehetőséget az OSX/Vista tool-ok.

Ave, Saabi.
ps: a fentiek a saját véleményemet tükrözik és a tévedés lehetőségét nem tudom kizárni...

Értem én az értem - hányan használtunk GNOME-t HP-UX-on? - csak az ellen próbálok érvelni (ezekszerint nem túl jól) - hogy az OS és a GUI egybegyúrása hibás irány. Mert szerintem nem az. Problémát inkább azokban a megoldásokban látok, ahol az OS és a GUI egymástól függetlenül, vagy legalábbis kevésbé egymásrautalva fejlődik.

Más kérdés persze, ha egy OS-t GUI nélkül használunk, de ez desktop-on vajmi kevéssé volna népszerű.

Ave, Saabi.

Én már jártam úgy, hogy - az akkor egyetlen - otthoni gépemen lefagyott az X. Mivel se soros terminál, se hálózat nem állt rendelkezésemre, teljesen mindegy volt, hogy a lefagyott X alatt működik-e az OS, ha azt nem tudtam elérni, mivel a billentyűzetkezelést is meghiúsította a lefagyott X.
Ellenben még nem láttam olyat, hogy OSX vagy Windows 2000/XP/Vista esetén csak a GUI rohadt volna le. Persze az egybeépítés miatt egy ilyen eset a teljes OS elhalását okozza és én nem válogattam ki, hogy mely alkotóelem volt az összeomlás valódi oka.

Ave, Saabi.

Ebben a szent pillanatban sz@rta ossze magat a hfs+ loapardon, teljesen normal hasznalat mellett...
a disk util csak annyit nyog: "Invalid number of allocation blocks. Volume check failed"

Na, ha most engem kerdezel milyen a filerendszere a leopardnak...
Persze lehet hogy a disk ment gallyra viszont 20! csavart (es minegyik specko) kell kiszedni hogy kivedd a disket.

Amugy nem feltelen kell HFS+-t hasznalnod, lehet UFS-t es experimental ZFS-t is :)

Ebben a szent pillanatban sz@rta ossze magat a hfs+ loapardon, teljesen normal hasznalat mellett...
a disk util csak annyit nyog: "Invalid number of allocation blocks. Volume check failed"

DiskWarrior. Ha ez sem nyert, akkor gondolkodj el a vinyocseren, es hogy a tovabbiakban az a device mennyire alkalmas ajto/ablak kitamasztasara. :)

Persze lehet hogy a disk ment gallyra viszont 20! csavart (es minegyik specko) kell kiszedni hogy kivedd a disket.

Ez az x86 "vervonal" ota a tizedere esett vissza. Elotte valoban remalom volt.

---
pontscho / fresh!mindworkz

Eleg erdekes problema volt, kicsereltem a PowerBook G4-emben a vinyot egy 7200 RPM Seagatre, es problamak voltak a sleep-bol valo wakup-al.

Aztan elkezdett problema lenni a boot-al is.

Hal istennek masnak is elojott ezzel a diskkel: a jumpert a gyari defaulton hagytam, ami slave volt, es ezt nem szerette a renszer (persze ha konzisztensen viselkedett volna akkor elobb rajovok), amint at tettem masterra minden franko lett.

Szoval se HFS+ se vinyo hiba: operator error :)

( turul16 v | 2008. 02. 06., sze – 12:52 )

Na, ezert kell az applenek a zfs notebookra :)

( Pontscho | 2008. 02. 06., sze – 13:54 )

Csak egy tapasztalat: OSX-en meg sosem lattam meg HFS+-t megborulni, pedig jelen pillanatban 5 ilyen gepet hasznalok nap mint nap. Ebbol az egyik alol naponta van lecsapva az aram, mert az aram halozat azon a helyen szar. Ilyen aram "event"-tol viszont szamtalan ext2/3, reiser es xfs kombot lattam elpusztulni. Egy idoben a cegnel ertekesitett termeken reisert majd ext3-at hasznaltunk fs-kent. Kb. minden heten volt ket eset, hogy megdoglottek. A problema csak akkor szunt meg, mikor ro fs-t kezdtunk hasznalni...

Szoval nem erzem, hogy van jogalapja beledumalni a dologba :)

---
pontscho / fresh!mindworkz

Valószínűsítem, hogy ha a Linux filerendszerek csak ennyire lennének megbízhatóak, mint amit te itt elő szeretnél adni (hetente magába dőlnek), akkor már ember fia nem használna Linuxot. Esetleg tudnék javasolni megbízhatalan áramellátás esetén szünetmentes tápegységet.

--
trey @ gépház

Otthoni desktop gepek altalaban nem szunetmentes tapon vannak. Tavaly itt volt egy het amikor estenkent allandoan aramszunetek jottek (par percesek, de a fel varosban, kozvilagitas is), a harmadik utan az ubuntu linux ext3 particioja teljesen megadta magat.(pedig az egyik legjobban belott linuxom volt :( ). De a problemat megoldja, hogy OSX86(Hackintosh) rendszerrel sok a gond, Mac-re meg nincs penzem :)

Érdekes módon nálam az ext3 még sosem borult meg.
Itthon, desktop gépen csak ext3 van, nincs szünetmentesem és azért előfordul áramszünet, mint mindenhol máshol nagyritkán. Még egyszersem döglött be miatta.
Szerveren reisert használunk. Ott sem volt még semmi probléma az fs-el.
::sumo.conf::

A tűzzel játszol, ha Reiser 3-at így használsz. Lehet, hogy neked valami időzítési sajátosság miatt soha nem fog tönkremenni, de a Reiser3 hajlamos volt más fájlokból származó darabokat beírni azokba a fájlokba, amik nem voltak lezárva az elhalás pillanatában. És ezt a hibát nem az elhalás okozta, hanem a következő reboot utáni journal visszajátszás.

Az a gond hogy ezt SZVSZ igen sok munka jol lemerni. Legalabb 10-szer (es akkor meg optimista vagyok) kell megcsinalnod a teljes procedurat, vagyis az X kihuzogatast minden egyes rendszerre (mondjuk lehet parhuzamosan), ez meg ez sem biztos hogy jelenteni fog valamit. Pl. erosen fugg az eredmeny attol hogy milyen programok futnak eppen, virtualis gepen fut-e az OS vagy a vason, etc. Nem azt mondom hogy nem lehet megcsinalni, csak azt hogy nagyon sok munka.

A filerendszer tesztek mindig sok munkát jelentenek. Körülbelül három hete tesztelek 7 filerendszert. Minden egyes teszt előtt reboot, mkfs, mount, sync hogy ne a legyenek dirty pufferek. Tudom miről beszélsz :)

Egyébként nyilván úgy lenne értelme, hogy mondjuk közben valami erőteljes filerendszeri tevékenység folyna. Akkor van mit visszagörgetni.

Mondjuk én továbbra sem hiszem, hogy a filerendszereknek kellene azt tolerálniuk, hogy kirántják alóluk az áramot. Ezt a lemezek sem tűrik sokáig. A szünetmentest és a rendszeres mentést nem pótolja semmilyen filerendszeri varázslat. Mindig a legrosszabbra kell felkészülni, azaz arra, hogy egyszerűen ne álljon le a gép szabálytalanul. UPS és ha látszik, hogy az áram nem jön vissza időben, akkor megkezdeni a szabályos leállítási procedúrát úgy, hogy azt még be is lehessen fejezni addig, amíg van kakaó az UPS-ben. Illetve komolyabb helyeken a dízel, gáz, stb. generátorokat beröffenteni.

Aki arra játszik, hogy a filerendszer majd lekezeli ezeket az _üzemeltetési hiányosságokat_ az elveszett ember.

--
trey @ gépház

Nyilván kell a filerendszerekbe valami minimális hibatűrés, de szerintem amit meg lehet tenni file-rendszer szinten azt miért ne tegyék meg. Ha megoldható elvileg, hogy egy filrendszer konzisztens maradjon egy "durva" leállás után, (már az is valami) akkor miért ne csinálják meg. Attól függetlenül teljesen egyetértek én is, hogy bolond aki egy filrendszer hibatűrésére bízza a rendszerét. Mint tudjuk nincs bug-free software.

rosszul gondolom, hogy az is befolyásolja milyen állapotban kapjuk vissza a fileredndszerünket, ha mondjuk éppen irunk rá? mert szerintem olvasás róla nem olyan nagy gáz, ha simán kihúzom a tápkábelt, és nem ment valami őrületesen nagy adatmozgatás a disken(copy, move..), akkor elvileg ki kellene birnia, nem? nálam még nem döglött el filerendszer, pedig már volt úgy, hogy karbantartó beszólt: fiúk, 5 perc múlva áramszünet!- és mire kimondta már offline volt a desktop gépem (későn szólt..) Szerencsére minden server UPS-re van kötve, és 10 perc után automatikusan és szabályosan leállitja a servereket.

Esetleg bootolás közben (pl. fsck futása közben), illetve frissítés / valamilyen dpkg művelet pl. hogy egyben marad-e a csomaglista, vagy korrumpálódik / közben is meg lehetne nézni... hogy mi történik...teszem azt egy marhagyors kill -9 $vmware_pid vagy hasonló. gondolom virt. gépben csinálod majd.

viszont érdekes lehet az eredmény...

Bootolás közben - asszem egymás után kétszer ? - kidőlt rendszer / reiserfs / után már kellett egyszer néhány évvel ezelött hegeszteni init.d/* fájlt. Mert a birka 2 fájlból ollózott össze egy használhatatlant. Persze ez már jópár éve volt, azóta jelentősen változott, stabilizálódott a kód, de egy tesztet talán ma is megér.

--------

Nem a zsömle kicsi, a pofátok nagy...

Biztos én vagyok nagyon ostoba, de ha már így szóbajöttek a filerendszerek hibái:
ext3 filerendszerre torrentelek, ezért nyilván lassan íródnak fel az adatok, de a helyet elvileg már lefoglalja a kliens, de:
Ha megnézem a partíció kihasználtságot csak a felírt adatokat veszi figyelembe, azonban ha összeadom a fileméreteket akkor akár több is mint a partíció mérete. (120 Gb-s partíción 160GB) adat, ami kissé furcsa.
El is szállt a rendszer, bár nem biztos hogy ettől ( http://hup.hu/node/48945#comment-481432 )
Ez hiba, vagy én bénáztam?
Tudna valaki mondani valami okosat?
_
SuSe 10.3 Semmi cicó.

szerencsefia! ...photoshop menti a 1,5Gb-os filet és közben áram el... A G5-ös basz*k felálni segitség nélkül és ez nem az elsö eset. Persze bennem van némi apple ellenérzés ami 93-óta szép lassan alakult ki a folyamatos használat eredményeként. Ezért lehet, hogy rosszindulatú vagyok.

ext3-on is javíthatna valaki olyan irányba, hogy ha törlök egy több tíz gigás állományt valamelyik könyvtárban, akkor mellette (párhuzamosan vele) még kilehessen listázni azt a könyvtárat, mert jelenleg addig kell várni a lista eredményére, amíg be nem fejeződik a törlés...

Egy unlink :) Na ne mar.

dd if=/dev/zero of=testfile bs=3M count=1k
1024+0 records in
1024+0 records out
3221225472 bytes (3.2 GB) copied, 248.47 s, 13.0 MB/s
build test # sync
#time rm testfile

real 0m1.953s
user 0m0.001s
sys 0m1.816s

#hdparm -tT /dev/sdd

/dev/sdd:
Timing cached reads: 298 MB in 2.01 seconds = 148.53 MB/sec
Timing buffered disk reads: 40 MB in 3.10 seconds = 12.89 MB/sec

#uname -a
Linux build 2.6.16.50 #2 SMP Tue May 15 11:21:30 alpha EV56 Rawhide GNU/Linux

#mount
/dev/sdd1 on /mnt/test type ext3 (rw)
Ez fostalicska regi kernel. regi egyszem vinyojaval (4GB), regi vezerlovel. Semmi specko.

Te neked miert tart addig ?

(bocs. drop cachest kifeldtem)

Lowend gép:

ext3:
-----

trey@fstest:~$ dd if=/dev/zero of=foobar bs=3M count=1k
1024+0 records in
1024+0 records out
3221225472 bytes (3.2 GB) copied, 71.6581 s, 45.0 MB/s
trey@fstest:~$ sync
trey@fstest:~$ time rm foobar

real 0m3.346s
user 0m0.010s
sys 0m0.290s

ext4:
-----

root@fstest:/data# dd if=/dev/zero of=foobar bs=3M count=1k
1024+0 records in
1024+0 records out
3221225472 bytes (3.2 GB) copied, 43.1828 s, 74.6 MB/s
root@fstest:/data# sync
root@fstest:/data# time rm foobar

real 0m0.512s
user 0m0.000s
sys 0m0.300s

Mingyá megnézem valami izmosabbon is :)

--
trey @ gépház

echo 3 >/proc/sys/vm/drop_caches -el + umount mount

time rm testfile

real 0m6.909s
user 0m0.002s
sys 0m0.917s

ps:

while true ; do date; ls >/dev/null; done |uniq
Neztem 3 sec hinayzik.
..
Wed Feb 6 19:52:13 CET 2008
Wed Feb 6 19:52:17 CET 2008
..

mikozben:
time rm testfile

real 0m5.399s
user 0m0.003s
sys 0m0.910s

Kicsit erősebb vas:

ext3:
-----

root@fusitest:/data# dd if=/dev/zero of=foobar bs=3M count=1k
1024+0 records in
1024+0 records out
3221225472 bytes (3.2 GB) copied, 39.3579 seconds, 81.8 MB/s
root@fusitest:/data# sync
root@fusitest:/data# time rm foobar

real 0m1.889s
user 0m0.000s
sys 0m0.730s

ext4:
-----

root@fusitest:/data# dd if=/dev/zero of=foobar bs=3M count=1k
1024+0 records in
1024+0 records out
3221225472 bytes (3.2 GB) copied, 36.0626 seconds, 89.3 MB/s
root@fusitest:/data# sync
root@fusitest:/data# time rm foobar

real 0m0.631s
user 0m0.000s
sys 0m0.620s

--
trey @ gépház

~$ cd big
~/big$ dd if=/dev/zero of=izebigyo bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 134.997 seconds, 79.5 MB/s
~/big$ time rm izebigyo

real 0m3.607s
user 0m0.000s
sys 0m1.330s
~/big$ mount | grep big
/dev/sda3 on /mnt/big type ext3 (rw,nodev)

Hmm, most kevesebb.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Csak halkan súgok, hogy ezt ebben a szálban mindenki beszopta (vagy az elmúlt 10 évben minden linuxos FS meggárgyult), ugyanis *normális* FS esetén, (nagyon leegyszerűsítva) amennyiben egyszerre 1 FS-blokknál nagyobb mennyiségű 0-kból álló adatot írunk a diszkre, akkor azon egy rohadt bitet sem ír senki (le se lesz foglalva az FS-blokk), csak a i-node -ban a fájl mérete nő, és az erre a blokk-ra mutató blokk pointer (sztem) NULL értékkel tárolódik le. Azaz minél nagyobb "bs"-sel hívjátok a dd-t, annál nagyobb esély van rá, hogy túllépitek az FS blokkméretét. Szóval mondjuk inkább /dev/random -ból töltsétek föl azt a pár G-s fájlt, akkor lesz valódi adatblokk foglalás is, tehát lesz mit törölni annak az rm -nek. Merthogy azért az az egy szál unlink el kell, hogy takarítsa a felszabadított adatblokkokat is - a szabad adatblokkokat föl kell venni a szabad blokk listába, be ell jegyezni a superblock-ba, hogy ezek már szabadok, stb, stb. Van vele munka. Kivéve, ha egy baromi nagy "SPARSE FILE" törlése történik - mint a ti jó kis tesztetekben.
Szóval lehet a teszteket újrafuttatni.

trey@fstest:~$ dd if=/dev/urandom of=foobar bs=3M count=1k
1024+0 records in
1024+0 records out
3221225472 bytes (3.2 GB) copied, 850.787 s, 3.8 MB/s
trey@fstest:~$ time rm foobar

real 0m3.855s
user 0m0.000s
sys 0m0.330s

root@fusitest:/data# dd if=/dev/urandom of=foobar bs=3M count=1k
1024+0 records in
1024+0 records out
3221225472 bytes (3.2 GB) copied, 833.137 seconds, 3.9 MB/s
root@fusitest:/data# time rm foobar

real 0m1.884s
user 0m0.000s
sys 0m0.880s

Hát azt hiszem, hogy ebbe nem pusztulunk bele, amíg kivárjuk.

--
trey @ gépház

Akkor homályosíts fel. Én úgy tudtam eddig, hogy a sparse az olyan fájl, amelyikben "lyukak" vannak. Attól vannak lyukak, hogy a fájl vége után pozícionálunk (kb) FS-blokk-nél nagyobb távolságra, majd oda írunk valamit. *Vagy* pedig attól, hogy csupa \0 -t írunk jó nagy egységben, és az FS réteg ezt optimalizálja a fentire.

3221225472 bytes (3.2 GB) copied, 248.47 s, 13.0 MB/s
Timing buffered disk reads: 40 MB in 3.10 seconds = 12.89 MB/sec

dd azert lehetett gyorsabb, mert meg nem kerult tenyleges kiirasra , amikor dd mert.
A te elmeleted szerint sokkal gyorsabbank kellett volna lennie.

Nem tunik tul okos dolognak minden blokk scanelese, hogy vegig nulla -e. Valoszinuleg rosszabb eredmenyt hozna altalanos tesztben.

(reiser, device level soft raid 0, no cache kill)
time dd if=/dev/zero of=sparse bs=1 seek=10G count=1
1+0 records in
1+0 records out
1 byte (1 B) copied, 9.1996e-05 s, 10.9 kB/s

real 0m0.119s
user 0m0.001s
sys 0m0.104s

time rm sparse

real 0m0.219s
user 0m0.000s
sys 0m0.203s

Nagyon jó a teszt XFS-en és 10 gigás (vagy mégkisebb) fileokkal, de én ext3-at írtam és több tíz gigás filet (tíz többszörösét: mondjuk egy 80 gigás filet), ráadásul nem a törlés idején volt a hangsúly, hanem hogy amíg megy az unlink() addig ugyanabban a könyvtárban nem megy (várakozik) a readdir()

( gyrgyvrs | 2008. 02. 06., sze – 19:07 )

Fúúú!
a két fenti operációs rendszerhez képest elhanyagolható piaci részesedéssel rendelkező
Főleg a mac-hez képest, ugye... véletlenül sem rosszindulatú!
Torvalds, akinek kernelét egyébként már másfél évtizeddel ezelőtt is elavultnak minősítette az egyik legismertebb operációs rendszer-elméleti professzor,
Ja, elméleti professzor. Meg egy. Hatalmas minta :-)Ha gpl licensz alatt adja ki a minixet, most nem lenne linux. Most meg megy Linus után... mikrokernel, meg a f***om.Érdekli a tökömet, hogy mennyire modern, van egy jó telepítő pl.: Suse Linux alá, kiválaszthatok egy csomó progit, oszt felmegy. Meg ingyér van. Nekem. Most küzdöttem egy WinXP+Ati Radeon 9600-al: Ati Catalyst-ben vissza kellett venni az agp-t 4x-re, hogy játékok menjenek. Túrtam érte a google-t, mint állat. Engem ez érdekel, nem hogy monolitikus vagy mikrokernel van alatta.
Minix: virtual gépre fel akartam rakni, inkább abbahagytam. Hiába olyan fejlett op.rendszert használ.

De a vitából ez jött ki! Ezért lett elavult a Linux kernel. A "vitában". Mondom, engem nem érdekel ez: Linux disztrib (általam favorizált) remek telepítővel rendelkezik, minix meg gagyi valamivel. Mit választok: Linux. Nem érdekel, hogy elavult...stb. Meg mikrokernel sem.

Nekem tetszene a minix, kár, hogy mind a hardver, mind a szoftvertámogatása vacak. Ha a debian project felkarolná... :)

Én, mint laikus, csak annyit mondhatok, hogy adott hardveren minix nagyságrendekkel gyorsabban futott, mint egy linux vagy egy bsd vagy egy windows 95 (jó, ez utóbbi grafikus felülettel futott, talán emiatt éreztem lassúnak. :)). Lehet, hogy ennek semmi köze nincs a mikrokernel/monolitikus kernel koncepcióhoz, hiszen a memóriahasználat is fontos tényező lehet például, de ettől függetlenül nekem a minix egy szimpatikus project.

Egyszerűen nagyságrendekkel kisebb méretű a minix kernel. Ez már önmagában gyorsabbá teszi.

Volt erről a témáról 1-2 éve egy vérre menő vita, amikor az űrhajókat vezérlő valamilyen UNIX származék kontra Linux volt a flame tárgya, mert hogy emnnyire borzasztóan stabil az űrhajós program. Persze, csak nem tud futtatni 25 architekturán openoffice-t.:-)

Gyerekek... A microkernel pont azért nem terjedt el mert iszonyat lassú volt. ezen az L4 javított egy kicsit, de azért nem véletlen hogy a Windows alapja is hibrid kernel (azaz van benne monolitikus rész is, pl a grafikai alrendszer). A Linux pont azért gyorsabb társainál mert monolitikus.

windoznak es makkosiksznek is sikerult egyesitenie a mikro es a monolitikus kernelek osszes hatranyat. ez fokepp a windozra igaz. mikrokernelen ha egy driver betojik, jobbik esetben az OS ujrainditja, rosszabbik esetben a device amit meghajtott elerhetetlen lesz. Windozpistanal meg sir a microsoft hogy igy a driverek meg ugy a driverek minosege miatt instabil szar az egesz. Viszont a message passing miatt sok a context switch, ami miatt lassu az egesz, mondjuk a context switch koltsege sokat csokkent az i386 ota, de akkor is.

Makkosiksz meg a masik architekturalis torzszulott. ott egy mach3-on egy komplett freebsd kernel fut mint egyetlen task. Hat gartulalok, ennek sok ertelme volt. ugyan ugy bedol ha valamelyik driver valami csunyat csinal mint ha egy sima monolitikus kernel. Ipod touchon ennek valami embedded verzioja fut, hat hasal ossze-vissza lepten-nyomon a draga.

Egyszer mar veszem a faradtsagot es elkezdek qnx-et hasznalni, az elvileg igazi mikrokernel. Mondjuk teny hogy windozzal karacsonyfaizzot se eleg biztonsagos vezerelni, qnx-re meg atomeromuveket is szoktak bizni.

A GNU meg osszeszedhetne vegre magat es a ket hadosztalynyi evangelista melle toborozhatna legalabb fel hadosztalynyi szoftvermernokot hogy kiadhato legyen mar vegre a HURD is, ne csak a GPLV3.

Sajnos jeleneleg az összes használható kernel egy toldozott foldozott izé. Ez ugyan úgy igaz Linuxra mint Windowsra és OSX-re is.
Engem egy valami bánt. Linus beszélt itt össze vissza user friendly magatartásról, meg nem kell semmit látnia a usernek. Kérdem én, melyik oprendszerben lehet kb 2 kattintásból workgroupoknak wiki-t és közös naptárat létrehozni web-re. Mindezt ofkorsz 1 gombnyomásos apache on megoldással? Leo server. Melyiket tudom távolról normális felületen(nem terminal) menedzselni? Leo server. Aláírom, hogy sok minden sőt, server fronton a legtöbb mindenben egy jól configolt linux viszi a pálmát, de ne bassza már meg a szent, hogy desktop gépnek a linuxokat hozzuk ki győztesnek. Egy nyomorult user baszik nagyívben a driver install-ra és baszik nagyívben a jogosultság kezelésre. Mitőbb szarik bele a kernelbe. Működjön kész pont. Rádugja a nyomtatóját? 90%-ban menjen magától. Feldugja a fotó masináját? Egyből kezelje. Böngészni akar? Tudjon vírus nélkül.
Pusztán ezekből az apró gondolatokból kifolyólag állítom és továbbra is tartom azt, hogy desktop gépnek OSX való, servernek pedig egy tökösen configolt Debian.

PS: Többen le mekósesikszezik az Apple operációs rendszerét. Jelzem az az x, egy tizest akar takarni. H már fonetikusan eröltetjük a dolgokat íme: mekóeszten. Köszöntem.
PS2: Mielőtt nekifogna mindenki a köpködésnek, hogy így apple fanatikus úgy apple fanatikus. 3 debian servert menedzselek a Macbook Pro-mról, illetőleg a PowerMac-em egyik winyóján bizony néha-néha egy linux kernel duruzsol. Sőt mitöbb rendelkezem a MBP-n egy windows partícióval is tesztelési célokra. :)

MacBook Pro 2.2 OSX 10.5 - PowerMac G4 Dual 450 OSX 10.4 Server - TimeCapsule(márciustól)

"Engem egy valami bánt. Linus beszélt itt össze vissza user friendly magatartásról, meg nem kell semmit látnia a usernek. Kérdem én, melyik oprendszerben lehet kb 2 kattintásból workgroupoknak wiki-t és közös naptárat létrehozni web-re. Mindezt ofkorsz 1 gombnyomásos apache on megoldással? Leo server. Melyiket tudom távolról normális felületen(nem terminal) menedzselni?"

erröl beszél Linus, hogy az oprendszer (kernel) és a user-space az két külön fogalom, lehet szar kernelre jó user-space-t irni és fordítva is ...

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.18-rc0-szami1

"erröl beszél Linus, hogy az oprendszer (kernel) és a user-space az két külön fogalom, lehet szar kernelre jó user-space-t irni és fordítva is ..."

Hehe, hát akkor meg nem tökmindegy hogy milyen a kernel? :)

--
"There are two kinds of people in this world, and you're not one of them."

Bar tudom hogy ez itt nem szokas de megprobaltam a temanal maradni. A 3 kulonbozo rendszert mint operacios rendszert nezni. Es bizonybizony definicio szerint (wikipedia.hu):

Operációs rendszernek (rövidítése gyakran OS az angol operating system forma alapján) nevezzük a számítástechnikában a számítógépeknek azt az alapprogramját, mely közvetlenül kezeli a hardvert, és egy egységes környezetet biztosít a számítógépen futtatandó alkalmazásoknak (például szövegszerkesztők, játékok stb.).

Ez meg szerintem (is) mai divatos kifejezessel elve a kernelt jelenti. Es abban egyet kell ertsek linusszal hogy mind a windoz mind a makkosiksz kernele egy architekturalis szornyszulott. Jomagam erosen mikorkernel parti vagyok a biztonsagossauk miatt, de teny hogy az ilyen osszeganyolt se nem ez-se nem az vacakoknal egy tisztan megvalositott monolitikus kernel is sokkal jobb megoldas. A Linux az tiszta monolitikus kernel (egy address spzce az egesz, kernelen beluli hivasok nem message passing-gel valosulnak meg) mig tiszta mikrokernel a hurd, qnx, minix. Mind3 sokkal jobb megoldas mint a makkosix vagy a windoz hibrid kernele.

GUI-rol meg user experience-rol nem beszelek, a grafikus shell tudtommal meg nem az operacios rendszer resze.

>> a grafikus shell tudtommal meg nem az operacios rendszer resze

nem mintha a wikipedia hivatkozási alap lehetne bármire is, de kár, hogy csak odáig idézel, ameddig neked szimpatikus

ugyanaezen az oldalon az iso-féle definíció: „Olyan programrendszer, amely a számítógépes rendszerben a programok végrehajtását vezérli: így például ütemezi a programok végrehajtását, elosztja az erőforrásokat, biztosítja a felhasználó és a számítógépes rendszer közötti kommunikációt.”

avagy az angol oldalon a 6.pont neve GUI

nagyonbutan megtervezett rendszerek eseten esetleg: mondjuk windoz. nt4 ota van olyan belso hasznalatra szant utilitynk ami meg xp-n is kekhalalba rohasztotta a gepet nem privilegizalt user alol inditva. ez az eredmenye ha a gui az OS resze. felreertes ne essek, a utility celja nem a gep lerohasztasa, ez csak egy mellekhatasa.

Ez azért tud szívásokat okozni rendesen. Vegyük a legegyszerűbb esetet: van egy fullscreenben futó programunk. A program lefagy. Windowson nyomsz egy ctrl+alt+del-t, de a feladatkezelő az alkalmazás mögött marad. Azaz nem tudod kilőni. Nem marad túl sok választás, power gomb, jobb esetben szabályosan leáll a rendszer, rosszabb esetben nem szabályosan.
Ugyanez linux esetében nem fordulhat elő, átválthatsz másik tty-re, vagy ha ez nem megy, akkor ctrl-alt-backspace. Gyorsabb, mint újraindítani a rendszert...

most félretéve a személyes megítélést (a piac ezt már megtette helyettünk)

A piac mar megitelte helyettunk a kornyezetvedelem fontossagat, az uveghazhatasu gazok kibocsajtasa visszafogasanak fontossagat es meg rengeteg mindent. A piac az az isten. Legallabis a skorpiok szerint akik a piac nelkul sose lennenek majd az uralkodo eletforma ezen a planetan. Kulonbenis szazmilliard legy nem tevedhet...

akkor egyetérthetünk benne, hogy a shell (légyen az akár grafikus) az o/s része

No ezt vajon hogyan vezetted le? Nekem valahogy az ugrott be elsore a logikadrol hogy vajon van-e akvariumod? Az hogy egyes elb@szott design-ok az operacios rendszer reszeve teszik, meg nem jelenti azt hogy ez lenne a helyes ut. Szoval nem, ebben (s|n)em ertunk egyet.

Az hogy egyes elb@szott design-ok az operacios rendszer reszeve teszik, meg nem jelenti azt hogy ez lenne a helyes ut.

Azokban az elbaszott operációs rendszerekben _ilyen szinten_ semmivel sincs jobban integrálva a GUI, mint a te kedvenc, megfelelő design-okkal rendelkező rendszeredben, csak kevésbé értesz egyikhez, mint a másikhoz, ezért egyiknél nem tudod hogyan távolítható el és miképp használható nélküle. Egy sima user számára - aki se a Windows, se a Linux belső világát nem ismeri -, ugyanannyira a rendszer részét képezi (mondjuk) Ubuntu alatt is a GUI, mint Windows alatt. Ha viszont mélyebb szinten vizsgáljuk a dolgot, akkor Windows alatt is gond nélkül eltávolítható a GUI és megy nélküle az alap rendszer, csak senkinek sincs ilyen jellegű perverziója, hogy így használja (bár Windows 2008 Server Core már kicsit elment ilyen irányba, de teljesen más okok miatt).

Torvalds Úr bizonyára ott téved, hogy a grafikus felület jórésze bár ugyanolyan programként fut mint a többi (más rendszereken is), de a grafikus megjelenítéshez szükséges alrendszer egy része nem. Unix/Linux alatt sem véletlenül kell közvetlen memóriahozzáférés az X-nek. Ha pedig egy program direkt képes írni/olvasni a memóriát (X esetén ráadásul az egészet, korlátozások nélkül), akkor a lehető legkevésbé sem nevezhető sima felhasználói programnak. Ha egy sima user képes írni/olvasni a /dev/mem által a teljes fizikai memóriát, akkor nem sima user többé. Az OpenBSD annyiban tér el ettől a többi *nix rendszerhez képest, hogy ott az X nem tudja a teljes fizikai memóriát (/dev/mem) írni/olvasni, hanem van egy külön device (/dev/xf86) amelyen keresztül korlátozottan elérhető a VGA framebuffer, vagy nagyobb allowaperture beállítás esetén a fizikai memória első 1 megabyte része. Sajnos a problémát ez sem oldja meg rendesen, de legalább nem a teljes memória címezhető az X által, mint Linux vagy más *nix esetében.

> Unix/Linux alatt sem véletlenül kell közvetlen memóriahozzáférés az X-nek.

Értem. Jelenleg a dosemu és az X az OS részei, mert hozzáférhetnek a teljes memóriához. Ha pedig már nem lesz lehetőségük hozzáférni a teljes memóriához, akkor már nem lesznek az OS részei.

http://lkml.org/lkml/2008/1/30/473 


config NONPROMISC_DEVMEM
bool "Disable promiscuous /dev/mem"

  The /dev/mem file by default only allows userspace access to PCI
  space and the BIOS code and data regions. This is sufficient for
  dosemu and X and all common users of /dev/mem. With this config
  option, you allow userspace access to all of memory, including
  kernel and userspace memory. Accidental access to this is
  obviously disasterous, but specific access can be used by people
  debugging the kernel.

Értem. Jelenleg a dosemu és az X az OS részei, mert hozzáférhetnek a teljes memóriához. Ha pedig már nem lesz lehetőségük hozzáférni a teljes memóriához, akkor már nem lesznek az OS részei.

Ha nem tűnt volna fel, akkor a "grafikus felület mint sima felhasználói program" témakörben írtam, hogy mit nevezünk egy OS részének nem taglaltam.

config NONPROMISC_DEVMEM

Ó, 2008/1/30? Ezekszerint pár napja került be, sajnos elkerülte a figyelmemet. Gyakorlatilag ugyanaz, mint az OpenBSD /dev/xf86, csak itt nem külön device, hanem a /dev/mem kerül korlátozásra... A problémát sajnos nem oldja meg, de ügyesek, hogy sok évvel később végülis lemásolták az obsd megoldását...

a te kedvenc, megfelelő design-okkal rendelkező rendszeredben, csak kevésbé értesz egyikhez, mint a másikhoz

Vicces, hogy anelkul hogy halvany fingod lenne mit csinal es mihez ert a vitapartnered, felepitesz magadban rola egy kepet, es meg el is hiszed hogy igaz. Csak hogy lasd mennyire melletrafaltal: napi 8 oraban windozra hakkolok olyan szoftvert amit esely van ra, hogy akar te is nap mint nap hasznalsz. Szoval az hogy nem ismerem a windozt annyira mint a linugzot kicsit erdekesen hangzik, leven kb '90 ota elek abbol hogy erre a platformra fejlesztek, linugzzal meg cca 2000 ota "jatszadozom". Es nem, nem "kedvencem" a linugz kernel, mert kifejezetten mikrokernel parti vagyok, de ha valasztanom kell a bableves es a toltott kaposzta kozott, akkor azt valasztom amelyiket jobban szeretem (legyen mondjuk a bableves), viszont ha a toltott kaposzta es a toltott kaposztas bableves kozott kellene valasztanom, jo esellyel a toltott kaposzta vinne el a palmat. Erted a hasonlatot vagy magyarazzam el mi micsoda benne?

Egy sima user számára - aki se a Windows, se a Linux belső világát nem ismeri -, ugyanannyira a rendszer részét képezi (mondjuk) Ubuntu alatt is a GUI, mint Windows alatt.

Lehet az a baj, hogy nem vagyok sima user? Mondjuk "Torwalds ur" sem nevezheto annak. Sima usernek a hacker pl az aki rendszereket tor fel es ezzel mondjuk bankokat foszt ki. Azert mert a sima usernek teves elkepzelesei vannak arrol hogy mi is az az operacios rendszer, azoknak akik szakmajukbol adodoan erteni kell hozza, nem hinnem hogy kovetniuk kellene ezt az elkepzelest.

A Grafikus alrendszerre a unixos/linuxos megoldas is messze van a tokeletestol (leven meg nem nagyon volt olyan hogy GUI amikor a unix megszuletett) de sokkal kevesbe veres a nyaka mint a windoz elgondolasnak, ahol mar a GDI es beleepult kernelbe, es emiatt egy gdi bug miatt omlik ossze adott esetben az egesz rendszer. A unix az ellenkezo veglet, itt meg a grafikus kartya regisztereinek a kezelese (uzemmodvaltas, stb) sincs a kernelben, ami ugyan hiba, viszont sokkal kevesbe eletveszelyes mint az elobbi. Idealis design az lenne ha a kenel kezelne a grafikus kartya hardverenek lehetosegeit (ahogy mondjuk DRI eseten ez mar erosen kozelit) es egy szabvanyositott API-n keresztul tenne ezeket elerhetove a felhasznaloi program(ok) -mondjuk xserver- szamara. Egy probalkozas erre linuxon a framebuffer device, de mivel letezo kartyak lehetosegeinek kozos metszetet fedi csak le, ezert nem neveznem igazan hasznalhatonak. Ezzel szemben a MaSik oldal nagyszeru designja kb olyan megoldast alkalmaz, mintha unixon a teljes xservet a kernel reszeve tennenk. Agyrem.

Mellesleg ez a vita egy mellekvagany, a windoz design-ja nem ezert szar igazan. Az igazi gaz hogy se nem mikro, se nem monolitikus a kernel (azaz toltott kaposztas bableves).

Vicces, hogy anelkul hogy halvany fingod lenne mit csinal es mihez ert a vitapartnered, felepitesz magadban rola egy kepet, es meg el is hiszed hogy igaz.

Amikor valaki Windows témakörben olyanokat ír, hogy "message passing" vagy hogy MacOSX-ben a Mach3-on egy komplett FreeBSD kernel fut mint egyetlen taszk, akkor azért kialakul valamiféle kép arról, hogy ért-e ahoz, amiről beszél... Ez már csak ilyen.

Csak hogy lasd mennyire melletrafaltal: napi 8 oraban windozra hakkolok olyan szoftvert amit esely van ra, hogy akar te is nap mint nap hasznalsz.

Az hogy valaki Windows alatt programoz még nem jelenti azt, hogy érti hogyan működik (sajnos tapasztalat). Persze ha mondjuk kernel hibákra írsz exploitokat, akkor előfordulhat, hogy tudod mi hogyan működik alacsony-szinten a kernelben, de sima userland alkalmazás-fejlesztésnél ezeket a mai magasszintű nyelveknél kevésbé kell tudni és sajnos legtöbben nem is tudják.

Szóval mit is fejlesztesz? ;)

Es nem, nem "kedvencem" a linugz kernel, mert kifejezetten mikrokernel parti vagyok, de ha valasztanom kell a bableves es a toltott kaposzta kozott, akkor azt valasztom amelyiket jobban szeretem (legyen mondjuk a bableves), viszont ha a toltott kaposzta es a toltott kaposztas bableves kozott kellene valasztanom, jo esellyel a toltott kaposzta vinne el a palmat. Erted a hasonlatot vagy magyarazzam el mi micsoda benne?

Nem szeretem az ilyen jellegű hasonlatokat, mert általában kevésbé tükrözi azt, amihez a hasonlatnak hasonlítani kellene. A mikrokernel pártiság persze jó dolog, ha technikailag kisebb kompromisszumokkal kellene megküzdeni, mint a jelenleg elterjedt architektúrákon.

A unix az ellenkezo veglet, itt meg a grafikus kartya regisztereinek a kezelese (uzemmodvaltas, stb) sincs a kernelben, ami ugyan hiba, viszont sokkal kevesbe eletveszelyes mint az elobbi.
[...]
Ezzel szemben a MaSik oldal nagyszeru designja kb olyan megoldast alkalmaz, mintha unixon a teljes xservet a kernel reszeve tennenk. Agyrem.

Mint írtam, ezen a szinten teljesen mindegy, hogy az X hol fut, ha direktbe írja/olvassa a teljes fizikai memóriát...

Amikor valaki Windows témakörben olyanokat ír, hogy "message passing" vagy hogy MacOSX-ben a Mach3-on egy komplett FreeBSD kernel fut mint egyetlen taszk, akkor azért kialakul valamiféle kép arról, hogy ért-e ahoz, amiről beszél... Ez már csak ilyen.

Mar megbocsass de a message passing reszt nem en szoptam be, te mast erthetsz message passing alatt, hogy en mit ertek azt leirtam. a Mach3/freebsd makkosiksz kernelrol pedig olvassal pottyet inkabb mielott minositeni probalsz: http://rutherglen.ics.mq.edu.au/~steffen/old/talks/DarwinMachKernel.pdf

Szóval mit is fejlesztesz? ;)

Azt hiszem ez nem olyan informacio amit megoszthatnek anelkul hogy onnantol minden hozzaszolasom ala 3 oldalas idiota "ez a hozzaszols nem tukrozi az xyz inc. velemenyet blablabla..." szarsagot kellene fuznom, szoval legyen annyi eleg hogy tavoli elereshez van koze es Abszurdisztanban fejlesztjuk a cuccot.

Mint írtam, ezen a szinten teljesen mindegy, hogy az X hol fut, ha direktbe írja/olvassa a teljes fizikai memóriát...

Annyibol piszkosul nem meindegy, hogy azt megakadalyozni hogy a teljes memoriat irhassa az X szerver sokkal kisebb feladat mint a GDI-t "kiemelni" a kernelbol, vagy meghagyva kernelkomponensnek megoldani hogy a kernel tobbi reszevel ellentetben ne erhesse el a teljes memoriat es I/O tartomanyt. Amugy ha hiszunk brekeke kollega infojanak (es miert ne hinnenk) a picipuha is belatta vegre hogy az NT 4.0-tol elcseszte a GDI design-jat es a vistara helyrepofozta, es tobben jeleztek hogy linuxon meg bsd-n is megoldottak mar a hozzaferes korlatozasat. Szemely szerint nekem a Vista fele megoldas design szempontbol jobban tetszik, de ez izles/eroforrasok kerdese.

Azt hiszem ez nem olyan informacio amit megoszthatnek anelkul hogy onnantol minden hozzaszolasom ala 3 oldalas idiota "ez a hozzaszols nem tukrozi az xyz inc. velemenyet blablabla..." szarsagot kellene fuznom, szoval legyen annyi eleg hogy tavoli elereshez van koze es Abszurdisztanban fejlesztjuk a cuccot.

Csak nem a LogMein...

---
pontscho / fresh!mindworkz

Ej Pontscho ez nem volt szép... / azért nem a te "HSZ száladba" teszem, hogy ha kedved van, törölhesd /

Azt hiszem ez nem olyan informacio

Most miért kellett ?? végül is nem akarta megosztani az infot. / bár kétségtelen hogy hozzzászólásával kb. 1szereplősre szűkítette a "lehetőségek" körét.

------

Nem a zsömle kicsi, a pofátok nagy...

Bocs, de nem is ismerem az uriembert, mindossze tippeltem a hazai szoftverfejlesztes osszetetelebol es beloktem egy felig kerdest, felig kijelentest. Ugytunik beletrafaltam. Ha nem akarja, hogy tudjak hol melozik, akkor meg csak ne is utaljon ra. Raadasul csak az anyavallalatukat emlitettem meg, nem a fejlesztest vegzo hazai ceget.

---
pontscho / fresh!mindworkz

bár Windows 2008 Server Core már kicsit elment ilyen irányba, de teljesen más okok miatt

MEGJGEYZÉS: (tényleg csak az!)

Én feltettem valami korai béta akármilyen verziót belőle, és volt benne grafikus részleg, egyedül az explorert vágták ki úgy mindenestül. Tehát volt szép grafikus bejelentkező winlogon, csak bejelentkezés után a hátteren nem szép start menüt, hanem egy command-prompt os ablakot kaptál a "grafikus asztalon", hogy akkor nesze. Ahogy inditgatni próbáltam különféle külső programokat, azokkal se nagyon volt gond, amíg nem volt "internet explorer x.x verzió" minimum függőségük. mert az is repült ugye.

-------

Nem a zsömle kicsi, a pofátok nagy...

windoznak es makkosiksznek is sikerult egyesitenie a mikro es a monolitikus kernelek osszes hatranyat. ez fokepp a windozra igaz.

Haj-haj, nagyon buták ezek a Microsoft-os fiúk... :)

mikrokernelen ha egy driver betojik, jobbik esetben az OS ujrainditja, rosszabbik esetben a device amit meghajtott elerhetetlen lesz.

Ez nem mikrokernel specifikus... Monolitikus kernel esetén is újraindítható a driver, feltéve hogy nem szemetelte tele a kernel memória többi részét, amikor elhalálozott. Windows esetén egy sok esetben meg is történik (pl. egy végtelen ciklusba került drivert a kernel egy idő után leállít és újraindít), amikor kékhalált látsz az már annak a jele, hogy a rendszer működése nem biztosítható tovább stabilan. Pl. a driver nem csak a saját memóriaterületét írta felül, hanem mást is.

Windozpistanal meg sir a microsoft hogy igy a driverek meg ugy a driverek minosege miatt instabil szar az egesz.

Pedig igazuk van, de nem csak Vista esetén, más Windows-nál is ez a helyzet.

Viszont a message passing miatt sok a context switch, ami miatt lassu az egesz, mondjuk a context switch koltsege sokat csokkent az i386 ota, de akkor is.

Huh, valamit te nagyon keversz. Windows-nál a hagyományos értelemben vett message passing nincs. Illetve van, de csak a Windows Compute Cluster Server esetén a node-ok között (tehát nem a hagyományos értelemben vett :).

Makkosiksz meg a masik architekturalis torzszulott. ott egy mach3-on egy komplett freebsd kernel fut mint egyetlen task.

Ezt a baromságot inkább ne terjeszd. Tanulj inkább egy lánytól. Lucy baba előadása a Mac OSX kernelről elérhető innen. ;)

mikrokernelen ha egy driver betojik, jobbik esetben az OS ujrainditja, rosszabbik esetben a device amit meghajtott elerhetetlen lesz.

Ez nem mikrokernel specifikus... Monolitikus kernel esetén is újraindítható a driver, feltéve hogy nem szemetelte tele a kernel memória többi részét, amikor elhalálozott. Windows esetén egy sok esetben meg is történik (pl. egy végtelen ciklusba került drivert a kernel egy idő után leállít és újraindít), amikor kékhalált látsz az már annak a jele, hogy a rendszer működése nem biztosítható tovább stabilan. Pl. a driver nem csak a saját memóriaterületét írta felül, hanem mást is.

Naja. felteve ha. De a lehetosege megvan ra hogy teleszemetelje. Ha nem lenne ra lehetosege akkor nem lene "ha". hahahahaha
Masreszrol valoszinuleg nem lattal meg "IRQL_NOT_LESS_OR_EQUAL" feliratu BSOD-t. Ehez meg xp-n is mindossze annyi kell hogy egy kerneldriver olyan kernelfuggvenyt hivjon meg ami szamara az adott runlevelen nem elerheto.

Windozpistanal meg sir a microsoft hogy igy a driverek meg ugy a driverek minosege miatt instabil szar az egesz.

Pedig igazuk van, de nem csak Vista esetén, más Windows-nál is ez a helyzet.

Abban hogy minden windoznal ez a helyzet, nagyjabol meg egyet is egyetertunk. Ha maradtak volna a klasszikus mikrokernel design-nal akkor a lenagyobb szopas amit egy szarul megirt driver okozhatna, az kb annyi, hogy nem mukodne az adott eszkoz. Ha irtal mar valaha windoz kerneldrivert akkor tudnod kene hogy ott vannak azok a kotelezoen meghivando kernelfuggvenyek, amik arra szolgal(hat)nanak hogy az adott driver csak azt a memoria/io teruletet erhesse el amit valoban az altala vezerelt eszkozhoz tartozonak nyilvanit. csak eppen semmi haszna az egesznek, mert a teljes IO es memoria cimtartomany ugyan ugy elerheto bermelyik driverbol.

Viszont a message passing miatt sok a context switch, ami miatt lassu az egesz, mondjuk a context switch koltsege sokat csokkent az i386 ota, de akkor is.

Huh, valamit te nagyon keversz. Windows-nál a hagyományos értelemben vett message passing nincs. Illetve van, de csak a Windows Compute Cluster Server esetén a node-ok között (tehát nem a hagyományos értelemben vett :).

Huh, sajnalom hogy ki kell abranditsalak, de kettonk kozul nem en vagyok az aki nagyon kever valamit. Monolitikus kernel eseten az egyik driver (mondjuk filerendszer) egyszeru "call"-lal belehivhat egy alatta levo (mondjuk block device) driverbe mert egy contextben futnak. Mikrokernel eseten az egyik driver nem latja az OS mas contextben futo reszeit, ezert kuld a kernelmagon keresztul egy uzenetet a megcelzott drivernek hogy mit is szeretne. Ezt hivjak message passing-nek, es emiatt van teljesitmenyhatranyban a mikrokernel a monolitikushoz kepest, mert ami mono kernelen egy fuggvenyhivas, ahoz mikrokernelen minimum 2 context witch kell (driver1->kernel->driver2) (Ajanlott irodalom: Stalling - Operating Systems). Windozon ugyan ugy tunik egy context a teljes kernel egy adott runlevele, azonban megis message passing-gel kommunikalnak a kernel egyes reszei, nem tudni miert.

( Oscon | 2008. 02. 07., cs – 09:46 )

Azért csak úgy érdekességképpen és kiváncsiság képpen az itt hozzászólók közül hányan használnak/tak Windows Vista-t + Linuxot + MacOS X-et ?

Oscon egy korona, két koponya :))) - + - .

Amúgy a C64 vs Spektrumos szálhoz C64 +1. Mert arra volt bard's tale II és bard's tale III is. A spektrumra meg csak bard's tale I-ről tudok, és az sem volt az igazi. :-)

PC-re is van a játék, de rossz az implementáció. Pl. A játékban a tárgyak nem azt csinálják amit kell. Ki látott már olyan kőpengét (Stoneblade), ami sikeres találat esetén nem változtatja kővé az ellenfelet. :D

---------

Nem a zsömle kicsi, a pofátok nagy...

( saabi v | 2008. 02. 24., v – 08:21 )

Kezdek egyetérteni Torvalds-al. Alább látható egy syslog részlet. Az első bejegyzés idején még volt 250GB adatom, az utolsónál már nem volt. Ami durva, hogy az adatok akkor vesztek el, amikor egy külső disk-ről egy másikra másoltam és hogy eközben az a filerendszer pusztult el, amelyikről olvastam az adatokat. 


Feb 23 20:47:43 moria kernel[0]: jnl: flushing fs disk buffer returned 0x5
Feb 23 20:47:45 moria kernel[0]: jnl: flushing fs disk buffer returned 0x5
Feb 23 21:01:32 moria kernel[0]: jnl: close: flushing the buffer cache (start 0xdc0000 end 0xdc2000)
Feb 23 21:02:07 moria kernel[0]: USBF:	1608.586	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:02:38 moria kernel[0]: USBF:	1639.587	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:02:40 moria kernel[0]: jnl: journal start/end pointers reset! (jnl 0x48acbb4; s 0xdc2000 e 0xdc2000)
Feb 23 21:03:38 moria kernel[0]: hfs: WARNING - blocks on volume Backup HD not allocated!
Feb 23 21:03:48 moria kernel[0]: jnl: close: flushing the buffer cache (start 0xde2000 end 0xde4000)
Feb 23 21:04:23 moria kernel[0]: USBF:	1744.591	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:04:54 moria kernel[0]: USBF:	1775.591	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:05:25 moria kernel[0]: USBF:	1806.592	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:05:56 moria kernel[0]: USBF:	1837.595	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:06:27 moria kernel[0]: USBF:	1868.596	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:06:59 moria kernel[0]: USBF:	1900.597	AppleUSBEHCI[0x4556800]::Found a transaction past the completion deadline on bus 253, timing out!
Feb 23 21:08:02 moria kernel[0]: hfs: WARNING - blocks on volume Backup HD not allocated!
Feb 23 21:08:31 moria kernel[0]: hfs: WARNING - blocks on volume Backup HD not allocated!
Feb 23 21:13:40 moria launchd: Server 0 in bootstrap 7f03 uid 501: "/System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/mdimportserver"[620]: exited abnormally: Abort trap
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:14:42 moria kernel[0]: hfs_swap_BTNode: invalid forward link (0x00360031)
Feb 23 21:14:42 moria kernel[0]: node=27 fileID=4 volume=Backup HD device=/dev/disk1s3
Feb 23 21:16:27 moria kernel[0]: jnl: close: flushing the buffer cache (start 0xadb000 end 0xadf200)

Tanulság? Nem várhatok tovább egy külső, FW diskdoboz beszerzésével.

Ave, Saabi.