6
-
A1274815 #6 "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. -
Ferrer #5 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? :)))
-
A1274815 #4 "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 -
Ferrer #3 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. -
Chriss745 #2 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. -
M2 #1 "Összpontosíts Boborján! Megugrod a világrekord!"
