Vlákno názorů k článku
Firefox na Windows 8 s ARM? Microsoft říká NE! od sj - osobně si myslím, že je to věc MS...

Pokud jsem si všimnul, tak řešení problematiky administrace stroje neprivilegovaným uživatelem je v Linuxu řešené velmi podobně jako na Windows. GUI se prostě zeptá na heslo admina. Ve Windows pokud jste admin, dotaz na heslo odpadá, a stačí akci potvrdit na secure desktopu (to je ta šedivá obrazovka, do které nemohou psát aplikace).

V XP (mimochodem 10 let starých) byla možnost spustit program v kontextu jiného uživatele. Nebo jste mohl otevřít další session pod adminem. UAC to pravda řeší elegantnějším způsobem.

Samozřejmě pro deset privilegovaných akcí musíte desetkrát potvrdit dialog. A samozřejmě si můžete spustit třeba Explorer nebo Total Commander pod adminem.

Ano, to máte pravdu, Windows Explorer ve Vistě nešel takhle spustit. Ve Win7 to jde. "Vlastní" přístup do Start Menu má každá aplikace, je to běžný adresář.

Světe div se - ve Windows můžete otevřít konzoli pod adminem, a pracovat v ní třeba týden.

Pokud chcete editovat soubor, ke kterému nemá neprovilegovaný uživatel přístup, dává spuštění Wordu pod adminem smysl. Samozřejmě i Wordu můžete spoustit jinou aplikace, chce to jen trochu invence ;)

Na Windows můžete na command line (ať už v cmd.exe nebo PowerShellu) dělat spoustu věcí. Pokud jste se naučil víc než ls a cat na Linuxu, jistě byste to zvládnul i na Windows :). Když jsme u toho, ve Windows můžete používat i ten bash.

"Windows jsou moderně navržený OS"

Proto je deravy jak cednik.

"Telnet a FTP posílaly hesla v plaintextu"

Nechapu co ma tohle spolecneho s Winhnus.

"předpotopní bitové masky místo ACL"

Viz muj komentar nahore.

"nemohou dělat "maličkosti" typu změny času (což má vliv na autorizaci v doméně), instalaci driverů (což má vliv na bezpečnost), změnu souborů v adresáři Program Files (což ovlivňuje všechny uživatele) apod. "

Takze de facto nic.

"UAC je celkem dobrá vychytávka, která se snaží do jisté míry vyřešit dilema uživatele: být či nebýt admin?"

Sam jiste vite, ze to byl takovy propadak, ze to M$ musel "trochu" uklidit hned v nasledujicim service packu. Navic si to kazdy hned vypina, to je taky bezpecnost jak noha :)

"vyrobila z něj MD5"

To uz se snad nikde nepouziva.

"User rights na úrovni API neexistovala."

Ano, zde jste spravne pouzil minuly cas.

btw, porovnavat Unixy ze 60. let a W(ind)ous je trochu smesne. Dnesni Unix-like systemy sou uplne nekde jinde.

Pokud jsem si všimnul, před nějakým časem lítaly inetem statistiky bezpečnostních chyb pro distra Linuxu. Celkem pravidelně jich bylo víc, než na Windows s Office. Totéž platí o web serverech.
http://www.eweek.com/c/a/Linux-and-Open-Source/Linux-vs-Windows-Which-Is-More-Secure/
http://www.crit.org/articles/96/1/Windows-More-Secure-than-Linux%3F

Ano, autorizace ověřováním MD5 hashe v /etc/pwd se asi už nikde nepoužívá. Nicméně to byl původně používaný způsob autorizace. Podobně s těmi user rights. Všimněte si na co jsem odpovídal. Mankind_boost tvrdil: "...unixove systemy, a tam byla bezpecnostni politika promyslena hned od zacatku". Proto srovnávám původní UNIXy s původními Windows NT.

No s tema bezpecnostnima chybama je to sporne (protoze vzdy naleznete jen cast, zalezi jak velkou a to nevypovida o celku), to bychom se mohli hadat do vecera. Pravdou je, ze linux bezi na kriticky dulezitych mistech (bankovni systemy, burza, ...) a to asi z nejakeho duvodu. Navic oproti Windows, na Linuxu (alespon na tech enterprise distrech) se aktualizace vytvari OKAMZITE po nalezeni exploitu. Kdezto na Windows muzu cekat pul roku. Podle meho, by M$ mel celej Windows NT zahodit a napsat ho znovu a poradne. (nejednou uz tu takova iniciativa byla, ale M$ to vzdy po chvili vyvoje odpiskal)

Všimněte si na co jsem odpovídal. Mankind_boost tvrdil: "...unixove systemy, a tam byla bezpecnostni politika promyslena hned od zacatku". Proto srovnávám původní UNIXy s původními Windows NT.

Ano, chapu, ja jen rekl, ze je to trochu zcestne :) To taky muzeme porovnavat Windows pre-NT a dnesni Linux.

Jistě bychom se mohli dlouho dohadoat, ale situace je dnes taková, že Linux není nijak výrazně bezpečnější. Jeho uživatele chrání jen menší rozšíření jejich systému, a větší zkušenost průměrného uživatele s administrací stroje. Jinak Linux běží typicky na webových serverech. Uvnitř firem je jeho použití spíše výjimečné.
Zahodit a přepsat bych chtěl spíš Linux. Dnešní Linux, vyvíjený od začátku chaoticky, s nepreemptivním monolitickým kernelem, má s těmi zmíněnými Windows 9x řadu společných prvků. Windows NT jsou naopak velmi dobře navržený systém. Modifikovný mikrokernel (oproti monolitickému kernelu Linuxu), podpora více subsystémů (včetně POSIXu), multithreading (který se do Linuxu dostal až v kernelu 2.6, a výsledek je pořád pomalejší než v NT nebo na Solarisu), rychlá synchronizační primitiva (velká bolest Linuxu), modularita (oproti špagetovému kódu a ifdef hell na Linuxu), objektový interface, moderní FS (včetně žurnálování, které se na Linuxu dodělávalo dlouhé roky), asynchronní API (na UNIXech velká novinka), plná podpora UNICODE (oproti sadě špinavých hacků s UTF-8 na Linuxu) atd.

Ještě k rychlosti oprav: jeden z linkovaných článků se týkal právě tohoto tématu. Linux propadl. Mluvíme samozřejmě o distrech typu RHEL a SLES, ne o nevyzkoušených night buildech.

1. Window ma hybridni jadro ne mikrokernel
2. Ve Windows neni kernel moc vyhra - kdyz padne driver padne to cely (jako u monolitickyho), vykon to ma malej zase jako mikrokernel. Pokud neni vyrobce driveru idiot tak vpodstate neni mikrokernel potreba. Naopak, monoliticke jadro Linuxu mam rad, protoze potrebuji plnou silu procesoru (a ne plejtvat procesorovej cas komunikaci modulu jadra)
3. multithreading (který se do Linuxu dostal až v kernelu 2.6, a výsledek je pořád pomalejší než v NT nebo na Solarisu)

Dukaz?

4. moderní FS
Dobrej for. NTFS je snad ten nejhorsi FS co kdy byl vytvoren. Staci vypadek site a mate z xGB souboru 0B soubory. A kolikrat to ani ta Windousacka obdoba fsck nespravi.

5 Zahodit a přepsat bych chtěl spíš Linux.
S timhle castecne souhlasim. To je obecne problem opensource softwaru. Kazdej chce pridavat features, nikdo nechce opravovat bugy a prepsani velke casti kodu nepripada v uvahu.

6. Uvnitř firem je jeho použití spíše výjimečné. To proto ze firemni PC (kde pracuji zamestnanci) pouziva take Windblows, a synchronizace je jednodussi. Moje osobni zkusenost je take takova, ze admini Windblows nemaji dostatecne znalosti pocitacu na administraci UNIXovych systemu, kolikrat ani poradne neumi s CMD (a priznejme si, ze u firemniho sitoveho serveru graficke rozhrani asi nema vyznam). Dnesni IT skoly uz nemaji uroven co driv.

1. From the start the Windows NT architecture has fallen squarely into the modified microkernel or macrokernel camp. http://technet.microsoft.com/en-us/library/cc750820.aspx
2. Zjistěte si něco víc o architektuře Windows řady NT. Architektura čistého mikrokernelu byla při designu zavržena právě kvůli problémům s výkonem.
3. Zkuste si to.
4. Pokud vám vypadne network a máte z něčeho 0B soubory, asi bude problém jinde.
NTFS je naopak velmi dobrý FS. Ještě jsem neviděl nic na Linuxu, co by se mu alespoň blížilo.
5. Souhlas.
6. Admini jsou jen lidi, a je jich potřeba veliká spousta. Kde byste vzal do každé firmy adminy, kteří umí zpaměti stovky příkazů a jejich syntaxi, znají umístění stovek konfiguráků, umí skriptovat, kompilovat, hrabat se ve zdrojácích atd?
Firmy používají Windows na deskopech i serverech. Je to jednoduché, ve srovnání s profi UNIXy velmi levné, nabídka aplikací je obrovská, administrace snadná, proškolených lidí je dostatek, vývoj SW je levný a efektivní.

Firmy používají Windows na deskopech i serverech. Je to jednoduché, ve srovnání s profi UNIXy velmi levné, nabídka aplikací je obrovská, administrace snadná, proškolených lidí je dostatek, vývoj SW je levný a efektivní.

Ve všech klíčových oblastech dynamického rozvoje výroby jsme splnili plán, a to i v složitých podmínkách výstavby nového závodu. Rozpor je příkrý, rezervy nemalé, opatření dílčí, iniciativa široká, připravenost kompexní a zkušenosti bohaté.

4. Tim sem myslel elektrickou sit, ne ethernet :D
Navic az bude BTRFS pripraven, NTFS si muze se svym ubohym navrhem hodit masli

6. Pokud to neumi, nema si rikat admin (btw kompilovat by se naucila i cvicena opice)

k tomu dovetku:
Nevim jak vy, ale ja potrebuji system, u ktereho si muzu vymenit nebo i upravit jakoukoliv komponentu, abych dosahl maximalni uzitecnosti pri maximalnim vykonu

muj dovetek:
Nevite, pro jakou instr. sadu je kompilovan Windblows? (i?86, mmx, sse?, 3dnow)

4. BTRFS má některé zajímavé features. Například transparentní kompresi, online defragmentaci, změnu velikosti za běhu atd. Jenže většinu jeho features mělo NTFS v roce 1993 :). Navíc dodělat BTRFS bude asi ještě chvilku trvat :)
http://www.root.cz/zpravicky/btrfs-v-ubuntu-12-10/418050/
BTW v čem konkrétně je podle vás návrh NTFS ubohý? Jde o vágní pocit, nebo máte i nějaký technický argument?

6. Vám se někdy podařilo něco zkompilovat napoprvé? Mě tedy ano, ale většinou jsem to štěstí neměl.

Note 1: předpokládám, že v autě máte dva kniply místo jednoho volantu, a pokud vlastníte nákladní vůz, tak mu po večerech přestavujete motor a měníte převodovku :)

Windows jsou, na rozdíl od Linuxu, optimalizované pro více procesorů. Dělá se to tak, že se udělá profiling, a výkonově kritické části se optimalizují pro různé CPU. Například syscall se realizuje pomocí int 2Eh, ale pokud CPU podporuje instrukce SYSENTER nebo SYSCALL, použije se alternativní implementace. U multimédií se prostě používá ta verze kódu, která je optimalizovaná pro daný CPU. Proto není potřeba Windows překládat zvlášť pro každou verzi x86(64) architektury. Autoři Linuxu by se mohli učit.
http://www.summitsoftconsulting.com/SysCallOpts.htm

Je pěkné, že NTFS to mělo v roce 1993, když online defragmentaci nebo změnu velikosti za běhu nešlo používat ve Windows do Visty.

Linux samozřejmě SYSENTER a SYSCALL podporuje. Multimédia řeší user space a různé optimalizace pro různé procesory ty běžně používané knihovny mají.

Mimochodem když jsou Windows tak optimalizované, umí už konečně IRQ balancing?

Online defragmentace je k dispozici minimálně od NT 3.51. U Visty je změna jen v tom, že se operace provádí s nízkou prioritou I/O.

Otázka není jestli Linux SYSENTER a SYSCALL podporuje. Otázka je, jestli zvládne s jednou binárkou syscall pomocí SW interruptu, SYSCALL a SYSENTER, bez nutnosti rekompilace.

Windows samozřejmě umí IRQ balancing, včetně podpory NUMA (například nechávat IRQ zpracovávat jen na procesoru, který je "blízko" danému zařízení). Na Linuxu nebyla implementovaná ani prioritizace IRQ, a obshula interruptu byla nepreemptivní. Ještě pořád je to takhle domršené? Ono opravit špatný návrh chvíli trvá. Zvládli to za těch 20 let? :)

Linux samozřejmě podporuje všechny možnosti, které jsou na dané architektuře k dispozici, takže je mu jedno, jestli ta binárka bude používat int, SYSCALL nebo SYSENTER. Klidně to může střídat.

Podle MS Knowledge Base to třeba XPčka bez restartu neuměla (plus je tam dobrý ten vtip, že MS je nedoporučuje používat jako PnP systém), novější informace jsem tam nenašel, tak proto se ptám.

Linux je preemptivní už poměrně dlouho, včetně obsluh interruptu, s výjimkou fast interruptů, kde je to zakázané by design (přesněji řečeno: interrupt handler může přerušit jen interrupt s vyšší prioritou, přičemž fast interrupty mají nejvyšší prioritu). Pokud však chcete opravdový real-time systém, existuje RTLinux. Prioritizaci IRQ umí Linux od verze 2.0 (je pro to příkaz irqtune).

Btw. umí už Windows preemptivitu vypnout? V mnoha situacích (např. server s jednou 10Gbps síťovou kartou) to totiž jenom zdržuje.

To si asi nerozumíme. OS samozřejmě může nabídnout syscall přes SW interrupt i přes SYSENTER. Nicméně syscall provádějí většinou systémové knihovny (na unixech libc). Použijí na jednom CPU SW interrupt a na jiném SYSENTER? Na Windows ano, protože se funkce pro volání syscallu (na unixech syscall()) při spouštění OS dynamicky přemapuje na SW interrupt nebo SYSENTER.

Ehm... Ptal jste se na load balancing IRQ, což se týká primárně SMP a cc:NUMA systémů. Najednou se dozvídám, že máte na mysli PCI sharing. Ve WinXP s klasickým PIC používá IRQ sharing, protože všechny jiné přístupy byly nespolehlivé.
BTW nastavení "Pnp OS" v BIOSu se týká výběru zařízení, které má BIOS před bootem nakonfigurovat. U PnP OS inicializuje jen nejnutnější HW, zbytek dělá OS.

Linux je preemptivní? Fakt? A co Big Kernel Lock? Teď nedávno ho pánové nově rozdělili na více Big Locků (code locks), s tím že je snad jednoho krásného dne zlikvidují. Jak jsem už psal, špatný návrh se opravuje dlouho a těžko.

Od Win2008 je k dispozici TCP receive window auto-tuning. Navíc už dávno negeneruje každý packet svůj interrupt. Používá se interrupt coalescing, a s jedním interruptem se vybere více packetů. Těch technik je více. Pokud vás to fakt zajímá, přečtěte si Windows Networking Deployment Guide.

To záleží na té které knihovně a jak je zkompilovaná. Třeba glibc to většinou dělá (ale dá se zkompilovat jenom s přerušením), ulibc vždycky používá přerušení.

If you change to an incorrect IRQ setting or I/O range for the bus that a device is on, Windows XP cannot compensate by rebalancing the resource that was assigned to that bus Bez toho je (re)balancing takový hodně omezený.

BKL se týkal jen některých částí systému a v současnosti se granularita zamykání zmenšuje. Spousta částí je už dlouho bezzámkových nebo se spinlocky. Jinak co s tím mají co code locks co dělat? Když něco vleze do code lock, tak to může přerušit jen interrupt s vyšší prioritou a ten tam nepoleze, protože bude řešit něco úplně jiného.

To samozřejmě vím, jinak by to těch 10 Gbps nikdy nezvládlo, ale i tak ta vynucená preemptivita zbytečně žere procesorový čas.

Jak jsem psal, ve Windows se syscall provádí přes INT 2EH pouze pokud není k dispozici SYSCALL/SYSENTER. Rekompilace není potřeba.

U sběrnice PCI se IRQ běžně sdílí. Rebalancing IRQ byl potřeba u ISA karet, nebo pokud byl HW navržený v rozporu se specifikací PCI. Jak jsem psal, podle dotazu se zdálo, že mluvíte o obsluze přerušení v cc:NUMA systémech (balancingu IRQ mezi CPU). Tam je dobré, když CPU obsluhuje přerušení od zařízení, které je mu "blízko", tedy ke kterému má rychlý přístup. Tohle Windows samozřejmě umí.

BKL se původně týkal celého kernelu, jako u původních UNIXů. A bohužel i po dvaceti letech vývoje je granularita zamykání v kernelu Linuxu mizerná.

Preemptivita žere čas CPU? Detaily, prosím.

Na Linuxu samozřejmě rekompilace není potřeba, pokud máte x86_32 a distribuční glibc, tam si to detekuje (na x86_64 je všude SYSCALL, dle specifikace, ostatní architektury jsem nestudoval). Akorát máte možnost si to zkompilovat, aby to fungovalo jinak, pokud chcete. ulibc to má natvrdo, protože se snaží být co nejmenší.

Vzhledem k tomu pravidlu o omezené preemptivitě (přerušit může jen interrupt s vyšší prioritou) dlouho nebyl s BKL problém. Až při nástupu vícejádrových ne-NUMA systémů to začalo být vážné (paralelní běh více interrupt handlerů bez oddělené paměti), tak se s tím začalo taky víc počítat. Současný stav je takový, že by to na existujícím hardware mělo zvyšovat latenci maximálně na hranici měřitelnosti.

Čím více preemptivní, tím typicky buď musíte více zamykat nebo je práce na netriviálních strukturách méně efektivní. Zajímavé pojednání o tom je například tato práce.

S BKL nebyl problém? Po dobu provádění syscallu všechny další pokusy o syscall končily zablokované. To výrazně zvyšuje latency, což bylo (a je) vidět u audia, přepínání režimů video karty atd. Samozřejmě na SMP a cc:NUMA strojích je to ještě horší, protože škálovatelnost takového kernelu je tragická (s počtem CPU klesá výkon per CPU).

Čím více preemptivní, tím lepší latency. Samozřejmě musíte na správných místech zamykat, a na jiných používat synchronizované struktury. Velké zámky typu BKL mohou mít o nepatrně nižší overhead na single CPU strojích, ale latency je mizerná. Navíc servery jsou už pěkných pár let SMP nebo cc:NUMA, a tam velké zámky vedou k tragickému (ne)škálování výkonu. Bohužel když napíšete kód bez zamykání, a efektivně nemáte představu, kde kdo do které struktury sahá, dodělává se fine-grained locking velmi těžko.

Většina odborníků na vývoj OS za sebou má nějakou historii. Samozřejmě se do toho může pustit i někdo naprosto nezkušený, jako Linus. Výsledek pak podle toho vypadá. Neproběhne klasický návrh klasický systému, opíše se něco existujícího, nadělá se hromada chyb (absence threadingu, big kernel lock, příšerné zpracování driverů a vůbec celého I/O), a pak se lepí, přepisuje, lepí a přepisuje.

A pokud jste někdy četl The Cathedral and the Bazaar, tak víte, že ve výsledku to nakonec funguje lépe, než když se to blbě navrhne jako megalomanský projekt a pak se škrtá a škrtá ;-)

Btw. Linus prakticky jen opsal návrh od Andrewa Tannenbauma, což je pan Návrhář operačních systémů.

Pokud byste místo The Cathedral and the Bazaar četl informace o rozšíření SW, tak byste věděl, že ten komunistický pamflet nemá pravdu. Dům také neprojektujete tak, že přinesete cihly, dobrovolníky, a začnete stavět. Když to tak uděláte, dům vám spadne na hlavu stejně, jako už douho autorům padá na hlavu vývoj kernelu Linuxu.

Linus psal terminálový emulátor, a pak se rozhodl psát OS, inspiroval se MINIXem, a opisoval API klasických UNIXů podle jejich dokumentace. Plus on a jeho lidé kopírovali kusy zdrojáků jiných UNIXů, ale to je jen detail. Andrew Tannenbaum je podle všeho dobrý pedagog, jeho MINIX je zajímavý výukový systém, a podílel se na řadě zajímavých projektů. Nevím ale nic o tom, že by (na rozdíl třeba od Davida Cutlera) stál za architekturou nebo vývojem nějakého rozšířeného OS.

Hmm, ano, Linux neběží na dvou třetinách serverů, Apache a nginx na sedmdesáti procentech webů a několikasetleté statky na venkově padají jak hrušky, zatímco nové pečlivě naprojektované budovy ne. Asi jste z nějaké jiné reality.

Btw. fakt si to přečtěte. Třeba vám dojde, že jde o popis reálných událostí, nikoliv o nějaký pamflet jako je microsoftí popis, jak navrhnout hybridní jádro.

Linux běží na velké části internetové infrastruktury jen proto, že je zdarma.

Co si mám fakt přečíst? The Cathedral and the Bazaar? Celou knihu jsem nedal, připadá mi to jako ztráta času. Zajímá mě spíš technika, než politický manifest. Navíc Raymondovy argumenty v realitě moc nesedí.

Fakt si myslíte, že Google, Facebook, Twitter nebo Seznam používají Linux jen proto, že je zadarmo?

Ano, to si myslím. Oni těch počítačů mají velkou spoustu, takže by je licence vyšly na dost peněz. Minimálně před uvedením Windows Server Web Edition, kdy ty firmy svoje serverové farmy zřizovaly.

Fakt si myslíte, že když dají za jeden server kolem 5 000 USD, tak už nebudou mít 200 USD (s multilicencí by to dost možná bylo i míň než 100 USD) na licenci? A proč tedy ty servery nemigravali, když by se jim to tak vyplatilo?

Btw. v Seznamu jsem pracoval a tam o cenu určitě vůbec nešlo.

ak sú tých serverov tisíce, tak sa to prejaví. 100€ za server nie je veľa, ale myslím, že sa sa k tomu pripočítajú aj iné veci. A ide aj o hotové riešenia.

Já měl za to, že právě tyhle firmy minimálně zpočátku jely na běžném desktopovém HW instalovaném na policích. USD 5000 mi na cenu takového stroje nesedí. A Windows Server jste tehdy za USD 200 fakt nepořídil.
Máte představu, co by znamenala migrace třeba Facebooku na Windows? Znamenalo by to mimo jiné vyměnit personál (část možná přeškolit), protože s Windows nemá zkušenosti. MS migroval třeba Hotmail, a dalo mu to dost práce. Migrace z Windows na UNIXy je ještě drsnější věc, protože často na UNIXech nenajdete SW, který jel na těch Windows.

UNIXy používají tradičně (a většinou dodnes) předpotopní bitové masky místo ACL.

Protože evidentně na většinu věcí pořád stačí. Plné ACL je ale samozřejmě dostupné.

Autorizace původně fungovala tak, že aplikace nějak dostala heslo v plaintextu, vyrobila z něj MD5, a tu ověřila proti /etc/pwd. Velmi pokrokové, tedy kdysi v šedesátých letech

Ano, kdysi dávno. Kdysi dávno taky Windows žádnou autentizaci nedělaly. Zřejmě ještě pokrokovější, protože to bylo v devadesýtých letech.

Kvóty některé FS neumí dodnes

Například exFAT.

A šifrované protokoly? Telnet a FTP posílaly hesla v plaintextu.

Taky je už používají jenom windowsáci. Telnet a (autentifikované) FTP se na Unixech přestaly používat ve stejné době, kdy windowsí SMB přestalo posílat hesla v plaintextu.

NFS se dokonce autorizovalo (a dodnes autorizuje) jen nastavením GID a UID v požadavku

Pokud danému serveru důvěřujete a proti podvrhům se umíte ochránit, je přeci zbytečné to dělat jinak. Pokud ne, tak NFS už od roku 1995 podporuje Kerberos.

User rights byly "tradičně" řešeny tak, že root smí všechno, a utilitám se přidával suid, aby běžely pod rootem. Neprivilegovaný uživatel pak mohl mít právo utilitu spustit. User rights na úrovni API neexistovala.

Což je osvědčený koncept pro naprostou většinu situací. Když má totiž někdo třeba právo instalovat ovladač nebo přepisovat globální aplikace, tak už veškerá další oprávnění dokáže získat snadno. Ale tak to funguje i na Windows.

typu změny času

Na to máme v Unixu NTP. A na změnu časové zóny přeci nepotřebujete administrátorská práva. Jo, počkejte, na Windows je vlastě potřebujete. Velmi pokrokové.

změnu souborů v adresáři Program Files

To řeší PackageKit. Případně to můžete udělat pomocí sudo, ACL ap.

UAC je celkem dobrá vychytávka, která se snaží do jisté míry vyřešit dilema uživatele: být či nebýt admin?

Možná by bylo lepší se zamyslet, kde ještě je potřeba získávat speciální oprávnění a kde už ne.

Plné ACL je dostupné jen někde. Spolehnout se můžete jen na klasické bitové masky.

Windows NT samozřejmě autentizaci řešily.

ExFAT kvóty neumí proto, protože na paměťové kartě je fakt nepotřebujete.

Ano, NFS podporuje Kerberos. Celkem vtipné s Kerberem to musí být ve chvíli, kdy do takovéhoto GUI přijde všech sto tisic uživatelů z realm (ve Windows domény):
http://rofi.roger-ferrer.org/eiciel/?s=5

Bohužel ten "osvědčený" koncept utilit se SUID vůbec neřeší použití API. Fakt si nemyslím, že ve většině situací stačí jen pouštět utilitu, která má veškerá práva v systému. Ve Windows je problematika řešená na úrovni API, a uživatelům lze přiřadit libovolnou kombinaci user rights.

Ve Windows probíhá synchronizace času samozřejmě také automaticky. A na změnu časové zóny admina nepotřebujete. Změnu souborů v Program Files potřebovat můžete a nemusíte, záleží na situaci. Pochopitelně i ve Windows máme installer a možnost spouštět pod jiný muživatelem. Bavíme se ale o tom, že pro uživatele Windows 9x je nezvyk, když nemohou dělat kdekoliv cokoliv.

Ano, otázka defaultních práv uživatele je celkem důležitá. Ve Windows existují bezpečnostní templates, které shrnují nastavení user rights a ACLs (a o kterých nezkušení uživatelé pochopitelně nevědí). Defaultní template ve Windows Vista vyžadoval admina i na věci, které uživatelé provádějí celkem často. Ve Win7 byl ten template změněn.

Plné ACL je dostupné jen někde. Spolehnout se můžete jen na klasické bitové masky.

Plné ACL je dostupné všude, kde je implementován POSIX. Samozřejmě na exFAT to není.

Bohužel ten "osvědčený" koncept utilit se SUID vůbec neřeší použití API. Fakt si nemyslím, že ve většině situací stačí jen pouštět utilitu, která má veškerá práva v systému. Ve Windows je problematika řešená na úrovni API, a uživatelům lze přiřadit libovolnou kombinaci user rights.

Problém je, že tohle krásné oddělení funguje jenom na čistém mikrokernelu, kde se ACL vynucuje i mezi jadernými procesy. Pokud ve Windows (a i v Linuxu) omezíte uživatele jen na načítání ovladačů nebo jen na změnu systémových aplikacích, tak mu můžete rovnou dát všechna práva, protože pokud je alespoň trošku schopnější, tak si je dokáže opatřit.

K plným ACL je potřeba například jejich podpora u FS. exFAT on removable media nemá ACL, protože každý počítač má jinou user base, takže ACL nemá na jiném stroji kontext. Tenhle problém uvidíte při mountu ext2/3 volume na jiném systému. Jak má ten systém vědět, který uživatel má UID 12345, když tuhle informaci nemá? exFAT je navíc určený pro spotřební elektroniku, má být co nejjednodušší k implementaci, a ono nemá valný smysl implementovat ACL ve foťáku.

To samozřejmě není pravda. Můžete uživateli dát práva neprivilegovaného uživatele, a k tomu mu umožnit provádět zálohu dat (tedy obejít ACL, s tím že soubory zašifrované přes EFS dostane jen v šifrované podobně). Nebo můžete uživateli povolit remote shutdown systému, změnu času stroje nebo management stránkovacího souboru. Když to uživateli povolíte, může ty akce provádět pomocí API, a samozřejmě i utilit, které jsou spouštěné v jeho kontextu.

Podporu ACL taky všechny běžně používané unixové FS mají, stejně jako je má NTFS. Těch pár, co je nemá, jsou potom na stejné lodi jako exFAT.

Tohle můžete dělat v Linuxu samozřejmě taky a není na to potřeba žádné speciální API. Pro zálohování stačí povolit čtení blokového zařízení oddílu, pro vzdálené vypnutí stačí v ACL nastavit, aby mohl spuštět příkaz halt s právy roota, pro změnu času stroje příkaz date a pro management stránkovacího souboru příkazy swapon a swapoff. Libovolným utilitám pak stačí používat tyto příkazy (což dělají stejně).

Vy zálohujete tak, že vydumpujete blokové zařízení? A co třeba částečná nebo inkrementální záloha?
To fakt chcete z aplikace místo volání API používat utility? Nejlépe v tradičním UNIXovém duchu přes fork/exec (tj. na Linuxu to bez memory overcommitmentu to sežere hromadu paměti, s ním vám bude v systému řádit OOM Killer)? A na změnu času si "pro jistotu" pustíte utilitu s právy roota? To jsou samé skvělé věci.

Inkrementální zálohy samozřejmě dělat lze i tak, třeba přes LVM. Částečné zálohy lze dělat podle hranic souborových systémů.

Vzhledem k tomu, že tak fungují Unixy už dlouho a ve výsledku to funguje lépe, než windowsí systém API, tak ano. Pokud vám vadí fork/exec, můžete použít třeba vfork nebo D-Bus.

OOM killer je zřejmě hrozný bubák, kterým se straší malí windowsáci před spaním :-)

Podle hranic FS? No tomu říkám granularity :)

Takže když máte jen command line utility a žádné API (POSIX pro spoustu operací stejně API nespecifikuje), tak je to vlastně OK. To chce gratulaci k chytrému návrhu :)

OOM Killerem se straší admini systémů, na kterých jedou produktivní aplikace.

Úplně dostačující.

Tak prostě Unix už čtyřicet let funguje, zatímco Microsoft své detailně promyšlené systémy tak jednou za osm let kompletně přepisuje.

Já jsem teda žádného admina (pokud to nebyl certifikovaný Windows Server Administrator) vystrašeného OOM killerem nikdy neviděl.

Když něco UNIXy neumí, není to potřeba. Podle mě API je potřeba širší API, nakonec náznaky najdete i v Linuxu (bohužel ne v POSIXu).

Microsoft své detailně promyšlené systémy tak jednou za osm let kompletně přepisuje? Nevšiml jsem si. Detaily, prosím.

Ono také není moc adminů, kteří by měli Linux na produktivních serverech, snad s výjimkou webů.

No aby zálohy k něčemu byly, je potřeba mít kompletní zálohy. Proto zálohy na hranici souborového systému stačí.

DOS -> Windows 9x -> Windows NT 5 -> Windows NT 6 -> WinRT

A co tam teda mají? Solaris? BSD? AIX? Všechno to má obdoby OOM Killeru. Snad jedině HP-UX, ale ten se místo toho uswapuje. Windows na takových strojích fakt nespouštějí.

Aby zálohování bylo co k čemu, musíte mít možnost si vybrat, co chcete zálohovat. Nakonec i na UNIXech se běžně používají backupy, které pracují per-file, nikoliv per-FS. Rozdíl je v tom, že ve Windows můžete mít dedikovaného uživatele, který má právo provádět zálohy (a obcházet tím ACL pro čtení), ale nemá práva pro administraci systému.

DOS, Windows 9x a Windows NT jsou různé produkty. Windows NT jsou po celou dobu velmi konzistentní, nejde o žádné velké změny konceptu. Ani s WinRT se toho moc nemění; architektura zůstává stejná.

Solaris má obdobu OOM Killeru? To by mě překvapilo. Nepoužívá totiž memory overcommitment.

Solaris overcommitment používá, a to pro anonymní mmapy nebo sdílenou paměť (a stejně tak pro fork). Pro malloc už snad nepoužívá overcommitment ani Linux.

http://developers.sun.com/solaris/articles/subprocess/subprocess.html
The Solaris OS does not use any heuristics or guessing of any kind. Therefore, it never needs to kill random processes when it runs out of memory.

Linux pokud vím dále zvesela memory používá overcommitment, a když pak paměť dojde, tak OOM Killer losuje a odstřeluje procesy.

Ano, Solaris vždycky sestřelí ten proces, kterému dojde paměť. Velmi inteligentní, když používá overcommit prakticky pro všechno kromě mallocu (resp. sbrk). Znamená to totiž, že při nedostatku paměti se už ani root nepřihlásí.

Linux používá heuristický overcommit, který dokáže spoustu problémů odhalit včas. Odstřelování se snaží být inteligentní a vychází z pravidla „zachovat přístup rootovi“, potom „zachovat interaktivní procesy“ a nakonec „zachovat hodně používané služby“, takže losování je tam minimální; pokud se vám ale líbí víc přístup Solarisu, můžete klidně použít ten (/proc/sys/vm­/oom_kill_allo­cating_task). Mimochodem OOM Killer jsem v akci neviděl už roky, zatímco třeba Eclipse mi na nedostatek paměti (malloc failed with ENOMEM) padá i dvakrát týdně.

Solaris vrátí chybu tomu procesu, který se snaží o alokaci. Jak proces s chybou naloží, to už je jeho věc. Pro vzdálené odstřelení procesu, který sežral paměť, nepotřebujete snad ani na UNIXech terminálové přihlášení.

Problém je v tom, že zatím co ENOMEM může aplikace v pohodě ošetřit (opakovat malloc s menším bufferem, dealokovat nějakou paměť apod), tak OOM Killer může nadělat pěknou paseku. Není totiž co zachytit. Proces dostane paměť, pak jí zkusí použít, a najednou je tenhle nebo jiný proces odstřelen bez možnosti cokoliv po sobě uklidit. Jestli vám to připadá jako dobré řešení, tak mě ani řadě jiných lidí rozhodně ne.

Pro vzdálené odstřelení procesu se hlavně musíte autorizovat. Což bez paměti jde hodně těžko. Linux sice vyhrazuje ¹⁄₃₂ adresního prostoru pro roota nebo cache, ale i ta se může při problémech celkem rychle vyčerpat.

Takže znovu: Solaris ten proces odstřelí, pokud ten proces získává paměť jinak než přes malloc (např. přes RW mmap souboru, na kterém potom pracuje). Sestřelí jej pomocí SIGBUS (OOM Killer sestřeluje pomocí SIGTERM). Chci vidět, jak tohle dokáže ta aplikace ošetřit lépe, než v Linuxu.

Pokud vím, OOM Killer posílal vždy SIGKILL, nikoliv SIGTERM. Vizte zdroják, mm/oom_kill.c.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=mm/oom_kill.c#l524
do_send_sig_in­fo(SIGKILL, SEND_SIG_FORCED, p, true);

Kolik potřebujete paměti na obsluhu RW mmap-ovaného souboru? Pokud vím, tak jen tu stránku, se kterou aplikace právě pracuje (plus nějakou paměť kernelu). Pokud není paměť, změny se prostě zapíšou do mapovaného souboru. Jinak při použití mmap() obecně můžete dostat SIGBUS (například při přístupu za konec mapovaného souboru), takže by ho aplikace měla být schopná obsloužit.