Szerintem meg nem kene szetcseszni ami eddig hozta a bevetelt. Ok, hogy toljak az uj cuccokat a mobil platformra, de ezzel egyutt meg kene tartani a meglevo, jol mukodo dolgokat is mint Windows/Office/stb.. Amit csinaltak a Windows 8-al es Office 2013-el az egy szanalom. En sokkal szivesebben nyulok egy Windows 7-hez es Server 2008 R2-hoz, mint barmi mas modern szarjukhoz. Pl. tragedia hogy egy Server 2012-on bekapcsolom az RDP-t, es a szerver manager 1 perc mulva frissit csak disabled-rol enabled-re.
Ezzen nagyon meg fogjak utni a bokajukat, mert az Enterprise vilag el fog fordulni toluk, es ok hozzak ugyebar a nagy zset.
Hát reméljük nem nagyon fog megújulni már. Az Office-nál elismerem, hogy nincs jobb, de a Win a mai napig annyira gagyi az *x világhoz képest, hogy az hihetetlen.
"Win a mai napig annyira gagyi az *x világhoz képest, hogy az hihetetlen. "
Ja hogy ne: *x világ gagyiságai: - joker karakterek kibontását a shell végzi, ennek hála a dos-os move *.txt *.bak parancs okosabb, mint a mv *.txt *.bak utasítás, illetve bizonyos fájlnevek kapcsolóként viselkednek - kevés hiba ellenõrzés illetve hiba esetén szereti elsunnyogni a dolgot - a dll hell itt született és ma is köszöni szépen meg van - X szerver: lassú a sok felesleges kontext váltás miatt, fordított kliens-szerver model, kifordított RDP szerû viselkedés, helyi gépen is TCP/IP-ét használ IPC-re, mondjuk LPC-ét nem is adnak a *x kerneleid, feleslegesn túlbonyolított architectúra (X szerver, Xlib, xtoolkitek, Windows Manager, GTK, Qt, stb.), de legalább eddig szabványos volt, még egy kicsi és az X szerver mellett 2 másik hasonló fogja egymást akadályozni - 20 év után kezd szabványossá válni, de hasonló IPC szerûvel küszködik, mint az X és hasonszõrû társai - mindenki maga hozzá tákolt parancsokat, amik néha bekerültek az alaprendszerekbe: rengeteg parancs, rengeteg inkompatibilis kapcsolóval, más más stdin és stdout kezeléssel. A megtanulása a kínai írásjelekkel vetekszik, bár a kanjik erõsen a logikára épül. - Owner/Group/World Read/Write/Execut/SetUID/SetGID sudo biztonsági modell, bár az utolsó három OGW/RWX model hiányosságai kiküszöbölésére született - az RFC-és szabványokat a unix-os protokoll megvalósításokhoz kellett igazítani, mert a unix elterjedt volt akkoriban és fütyült a szabványokra - NFS magic cookie - NFS UDP tetején van - Moris worm - Elsõ vírus az ncurse lib tetején *x világ pozitívuma: - alaposan scriptelhetõ
És megjegyzem, hogy Windows alatt: - Win8-ig ha akarsz Enterprise/Ultimate/Server verziókig tudsz unix futtató alrendszert telepíteni - van a sokkal erõsebb, objektum orientált: Power Shell - létezik Windows Host Script (ami Javascripttel illetve VBScripttel programozható) és elérhgetõ a teljes WMI belõle - 32biten létezik a "gagyi" DOS-os command.com által értelmezhetõ batch (.bat) fájlok (kb. ez az amirõl tudsz) - létezik a valamivel fejlettebb cmd.exe által támogatott parancs fájlok(.cmd/.bat kiterjesztéssel) - ACL biztonsági modell - Az executive kezdetektõl fogva tervezetten tartalmazta a biztonsági alrendszert, támogatást a Domain/AD központosításra (a registry léte is ennek a következménye) - a kernel és az executive támogatást nyújt minden futtó alrendszer szolgáltatásaihoz pl.: az NtCreateProcess támogatja a Win32 CreateProcess-t, a unixos fork() illetve vfork() hívásokat, természetesen az exec* utasításokat is, illetve OS/2 DosIExecPgm rendszer hívásra, továbbá az NtCreateThread is hasonlóan, illetve a memória megosztást, memory mapped fájlokat. - központi management (AD) - SMB ACL alapon
Amiket itt felsoroltál, köszönõviszonyban sincsenek a win olyan alapvetõ end-user fogyatékosságaival mint az eszközfüggõ meghajtó-betûzés (egyáltalán minek??), a rendszerpartícióba belehányt home könyvtár vagy a dosból örökölt EXE formátum. A registryrõl nem is beszélek.
- A joker karakterek kezélése miért probléma? Ha jól van megírva a program, képes több fájl paramétert kezelni. - Milyen hibáról beszélsz? - Dll? Megnézem majd, hányat találok a rendszeremen, szerintem egyet sem. - Ehhez nem értek, de nekem mûködik rendesen, úgyhogy le is sz*rom. Mellesleg már nem csak X van. - A parancsok nagy hányada nem az alaprendszer része, hanem a GNU parancskészlete. A kapcsolók általában ugyanazt jelentik, nyilván különböznek ezeknek a segédprogramoknak a funkciói. De mivel ilyenek eleve nincsenek a Win alaprendszerben, felesleges errõl vitázni :) - Ez a biztonsági rendszer sokfelhasználós rendszerek mllióit szolgálja ki, ha neked nem felel meg, nyújts be egy jobbat Linux Torvaldshoz :)
"- NFS magic cookie - NFS UDP tetején van - Moris worm - Elsõ vírus az ncurse tetején" Ugye ne soroljam a Win vírusait? :)))
"Amiket itt felsoroltál, köszönõviszonyban sincsenek a win olyan alapvetõ end-user fogyatékosságaival mint az
"eszközfüggõ meghajtó-betûzés (egyáltalán minek??)" Mountolás minek? /dev-ben minek léteznek az eszközök fájlokként?
(Amúgy is csak a Win32-öt látod, Az ntkernel a memóriában(!) létezõ Object Manager structuráját követi a C: meghajtód nevezetesen: \Device\Harddisk0\Partition1 mögé van elbújtatva)
"a rendszerpartícióba belehányt home könyvtár" *x rendszerek is csinálnak ilyet, amúgy röhögni, fogsz, de környezeti változóval, át rakható a user könyvtárad
"vagy a dosból örökölt EXE formátum." LoL! Ha enyíre nem tudsz valamit, legalább ne írj róla! A DOS-os csonk, csak annyít tartalmaz, hogy nem futtatható DOS-ból, utánna viszont egy Portable Executable formátumú végrehajtható található. http://en.wikipedia.org/wiki/Portable_Executable
"A registryrõl nem is beszélek." /etc husz millió különbõzõképpen értelmezett szöveges és bineáris állománya a registry meg a domain/AD központi confighoz kellett. Hogy miért? Egyszerû: egyszerûbb az ntuser.dat-ot leszedni illetve az ntuser.pol és system.pol fájlokat mint husz millió kis fájlt a /etc-bõl. Na ez az egyik oka nannak, hogy *x-ed alatt nem megy még most sem valami AD vetélytárs.
"- A joker karakterek kezélése miért probléma? Ha jól van megírva a program, képes több fájl paramétert kezelni. " Az hogy a SHELL bontja ki és nem a program magan egy library segítségével, ez könyen ilyen esetekhez vezet pl.: adott egy könyvtár szerkezeted és létezik benne egy -r fájl, és mondjuk törölni szeretnél a fõ könyvtárban tartozó fájlokat, de az alkönyvtárakat meghagyva, a -r fájlol nem tudsz és kiadod a rm * parancsot utánna meg nézel egyet, de nem csak az rm ilyen veszélyes.
"- Milyen hibáról beszélsz?" Teszem azt nem sikerül lérehozni egy fájlt, megtelt a lemez, nem sikerült lockolni egy fájlt vagy recordot, nem szól egy parancssori program róla egy mukkot sem, hanem szép csendben adatvesztést okoz
"- Dll? Megnézem majd, hányat találok a rendszeremen, szerintem egyet sem Mondom én, hogy nem sokat tudsz, attól még, hogy valamit .so-nak hívnak még funkcióját tekintve dll. És tele van vele a rendszered /usr/lib, /usr/X11/lib, /usr/local/lib meg még egyéb helyeken, és igen jön az újabb so csinál szép kis biztonsági mentést az elõzõrõl, aztán felül csapja, majd az új program, amihez kellett megy a régik meg mindenféle fúrcsa üzenetekkel elhalnak.
"- Ehhez nem értek, de nekem mûködik rendesen, úgyhogy le is sz*rom. Mellesleg már nem csak X van." Írtam is: "még egy kicsi és az X szerver mellett 2 másik hasonló fogja egymást akadályozni"
"De mivel ilyenek eleve nincsenek a Win alaprendszerben, felesleges errõl vitázni :)" CMD-hez tartozó programok, Windows Host Script, Power Shell, ja végül is
"- Ez a biztonsági rendszer sokfelhasználós rendszerek mllióit szolgálja ki, ha neked nem felel meg, nyújts be egy jobbat Linux Torvaldshoz :)"
ACL, már elé dobbták, beletette, csak semi nem támogatja szinte, és az ACL egy kicsit finomabb hangolást és több lehetõséget tartalmaz. Különben is a *x nem csak Linux ám!
"Ugye ne soroljam a Win vírusait? :)))" Nem arra van, csak annak a bizonyítása, hogy bizony *x alatt születtek, mert olyan jó biztonságos rendszer.
Informatika és tudomány
