Vlákno názorů k článku
Chorvatsko ušetřilo díky open-source informačnímu systému od pp - Připomeňme si Drábkův pr*ser, kdy zajetý systém s...

Jenže ten bič právěže nebude fungovat - z důvodů uvedených výše.

Navíc, když tohle řeknete, tak výkon dodavatele nezlepšíte, spíš naopak:-)

Za další: směšujete 2 různý věci - výrobu aplikace (a následný modifikace a dodávání novejch fčností - což je vlastně taky "výroba") vs. support (ve smyslu administrace uživatelů, kontrola logů, hlídání místa na disku, záloha starejch logů, restarty apod.).

Zatímco jednoduchej support (údržbu) může dělat "libovolnej" admin, tak úpravy stávající aplikace holt může udělat (efektivně) jen původní dodavatel. Taková je realita:-(

To samozřejmě nevylučuje situaci, kdy ten původní dodavatel to neskutečně zprasil, protože zákazník nebyl schopen dát dostatečný zadání a dodavatel ve snaze získat zakázku slíbil modrý z nebe ("to není problém"), aniž by o business doméně zákazníka měl nějaký ponětí. A v takový situaci, pokud se najde někdo, kdo má o business doméně zákazníka "inside" informace (např. protože v tom oboru on nebo jeho rodinný příslušník dřív pracoval), tak v takový situaci ten novej dodavatel může teoreticky dodat nový řešení, který má víc fčností, lepší spolehlivost (a možná i nižší cenu), i když si to musel napsat celý znova. Ale tahle kombinace se příliš často nestává:-)

Jenže Windows NT jsou z roku 1993; už v roce 1995 jsem objevil NT 3.51, a byl jsem nadšený.

U unixů mi nesedí administrace, API a řada dalších aspektů, takže pro mě jsou hnusné, nafouknuté a smrduté mrsiny právě unixy. S důrazem na Linux, protože ten je v rodině unixů poněkud slabším kouskem.

Nevim, co mate furt s tim API. Vy snad programujete?

Ano. Specializuje se na brainwashing.

Já tomu rozumím. Když se administrace dělá snadno z GUI, je to hrozná nuda. Správný admin se neučí principy, ale memoruje se stovky příkazů a konfiguráků, plus se samozřejmě učí ovládání vi :)

API je zásadní pro vývojáře, a nepřímo i pro uživatele.
Živil jsem se kdysi i programováním, ale dneska píšu kód jen pokud není zbytí. Jako dítě jsem si hrál s BASICem (dokonce jsem pár aplikací prodal - dětská práce je jasné svinstvo :D), a postupně pokračoval v 8080, 8048/8051 a 8086 ASM, různých Pascalech, okrajově v C a C++, pak v různých VB, Javě a C#, plus samozřejmě průběžně ve skriptovacích jazycích. Co mi fakt nepřirostlo k srdci je Perl (kód působí jako náhodná změť znaků a čitelnost je velmi špatná), a pak většina neprocedurálního programování (Prolog, Erlang - bolí z toho hlava).

Když jsem tu popisoval, jaký je na Unixech bordel v API, a že nelze zjistit například seznam daemonů, nebo zjistit jestli nějaký daemon běží, tak to bylo zrovna z praxe. API UNIXů je obecně desítky let zastaralé, spousta věcí v něm chybí, cokoliv mimo POSIXu na systému může a nemusí být, implementace spousty věcí se liší UNIX od UNIXu. Když v Adobe portovali hloupý plugin browseru na Linux, museli u toho mimo jiné ohýbat GCC - to snad mluví za vše.
http://www.root.cz/clanky/proc-trva-vyvoj-flash-9-pro-linux-tak-dlouho/

Klikání se blbě cpe do skriptu. Je často efektivnější den nebo dva googlit příkazy a lepit skript a pak už konfigurovat automaticky spuštěním skriptu stroje co pět minut jeden, než na každé mašině dvě hodiny klikat. Nehledě na to, že když náhodou nějaká periferka ve Widlích dostane od PnP jinou identifikaci (a tu, co jsem viděl, dostávají periferky na stejným železe náhodně), jde předpřipravený image často do popelnice.

Klasický příklad: připojený USB-RS232 adaptér a BT. Pokud má widlácký image připraveno nastavení portů pro BT na COM1-COM5, záleží jenom na tom, jestli PnP dřív najde BT modul nebo zařízení na USB. Unix skript to definuje celkem jasně.

By the way, nedávno jsem koukal zrovna na porty ve Win. Proč když otevírám sériák COM1 jako soubor musím zadávat "\\\\.\\COM1"? Je v tom nějaká logika, nebo "protože Bill"?

Cokoliv se dá udělat z GUI, dá se v principu udělat i bez GUI. Pokud hovoříte o deploymentu Windows, tak tam máte v principu dvě možnosti:
A. Instalace Windows s předvolenými parametry,
B. Pořízení image a jeho rozkopírování.

Scénář A nemá s HW žádné problémy. Scénář B vyžaduje použití utility Sysprep, díky které se provede re-detekce HW.

Ke COM portům: na Unixech máte major number a minor number, které specifikujete v defice files (například /dev/sda3 má major no 8 jako "driver 8", a minor no 3 jako "device 3"), a ty přes device files pak "mountujete" přístup k driveru do stromu. Použití major a minor number bylo super v sedmdesátých letech, ale dnes přináší problémy s počtem driverů, počtem zařízení adresovaných těmi drivery apod.
Kernel Windows NT nepoužívá písmena jednotek, protože je stavěný tak, aby nad ním běžely různé subsystémy (Win32, POSIX apod). K adresování zařízení interně používá NT namespace, kde jména začínají na \. například \Device\Harddis­kVolume4 nebo \Device\Serial0. Pro POSIX subsystem se používá POSIX name space, kde je všechno přimountované v jednom stromu.

Ve Win32 se běžně používá Win32 File Namespace, kde například E: je symlink na \Device\Harddis­kVolume4. Prefixem \\?\ můžete cestu předat rovnou driveru, takže můžete použít třeba cestu \\?\Volume{26a21bda-a627-11d7-9931-806e6f6e6963}\

Pro přístup k zařízením se používá Win32 Device Namespace, kde názvy začínají na \\.\ . Například \\.\TAPE0, \\.\Changer0, \\.\COM1. Pro COM1-9 navíc existuje z důvodu zpětné kompatibility možnost adresovat je přímo pomocí COM1-9, bez \\.\ .

Resources:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365248(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724826(v=vs.85).aspx
http://technet.microsoft.com/en-us/sysinternals/bb896657.aspx -- utilita WinObj, která ukazuje celý NT namespace (pokud je puštěná pod adminem)

BTW čekal bych, že pokud píšete něco pro Windows, tak tyhle základy znáte. Na Linuxu snad také více k čemu je defice file, major a minor number.

Ano, na jednom SCSI řadiči můžete mít maximálně 15 partitions, a to často nestačí. Navíc když máte dva SCSI řadiče, a pak jeden odeberete, může se tomu zbývajícímu automaticky změnit major number, a tím se zneplatní device files. Navíc těch major a minor numbers je omezený počet, a hrozí kolize. Neoficální seznam je tady:
https://www.kernel.org/doc/Documentation/devices.txt

Tisíce disků na notebooku nemám, a šneka si namydlete sám :)

15 oddilu na disk, ne na radic - jj

Tedy to me zrovna moc nervy nedrasa - mě je to celkem drásalo, když mi po odebrání jednoho RAIDu zmizel obsah toho druhého, musel jsem zjišťovat proč, a ručně to opravovat. BTW jak se mountují disky přes GUID? Na Linuxu jsem to ještě neviděl (na Windows to tak samozřejmě mám udělané).

Vy si neuvědomujete, že major a minor numbers se používají pro adresování *všech* zařízení, nejen disků. Na systému například nemůžete použít dva drivery se stejným major number. Těch čísel je pár, a číselné řady samozřejmě nikdo nespravuje. BTW to místo na několik desítek disků tam je (bylo) jen pro některá zařízení. Pro RAID tuším jen když jste provedl nějakou úpravu a oželel možnost použití driverů s kolidujícími čísly. Jinými slovy tohle je jedna z ukázek unixového pravěku, která se díky bezmyšlenkovému opisování dostala do Linuxu.

Widle bezi leda tak na PC a ty na tohle nemaji kejsy a ani ne moba s dostatecnou konektivitou - viděl jste někdy kartu SCSI řadiče, víte kolik se jich vejde do serveru, a kolik disků se vejde na řadič? A viděl jste někdy nějaký FC SAN?

Jak jsem psal, i jen na stovky disků se dostanete jen za předpokladu, že provedete drastickou lobotomii kernelu.

A já tu potřebu zrovna měl, protože na serverech to prostě může být potřeba. Přičemž omezení na 15 oddílů není taková tragédie, jako fakt, že mi při pokusu o vytvoření šestnáctého oddílu každá utilita házela jinou (a pravidelně naprosto nesmyslnou) chybu, místo aby byť jediná z nich napsala, že maximální počet partition je na daném zařízení omezený na 15. Ale co člověk může čekat, je to open source.

K čemu, smím-li se optat, potřebujete stovky disků spravovaných jedním kernelem? Kromě toho, že jde o prakticky neadministrova­telnou strukturu datových úložišť (mám na mysli plně odpovědnou správu), v dobré společnosti je dobrým mravem pracovat jen s tím, co jsem schopen efektivně spravovat a využívat. Hádejte, proč a za co si v Oracle nechávají za svá systémová řešení tolik platit navzdory implementovaným heteroplatformním prvkům, diky nimž šetří... O API to je jen když na tom někteří trvají a jinak to neumí. Ostatně, současný linuxový kernel je asi hodně problematický, když je jako optimální masově nasazován v kritických běhových prostředích ve finančním a technologickém světě... Inu, zbastlit nějaký kód a myslet si něco o sežrání Šalamouna mluví samo za sebe.

Stovky disků spravovaných jedním kernelem můžete potřebovat. Mě šlo ale primárně o 16+ partitions na jednom disku. To jste fakt nikdy nepotřeboval?

O API to je jen když na tom někteří trvají a jinak to neumí - na co konkrétně reagujete?

Současný linuxový kernel je asi hodně problematický - řekněme že má své technické problémy. Na druhou stranu je to Unix-like systém pro levný Intel HW, a navíc je zdarma nebo levný, takže jsou celkové náklady daleko nižší, než u Solarisu, HP-UX nebo AIXu.
BTW nějakého masového nasazování Linuxu v kritických běhových prostředích ve finančním a technologickém světě jsem si nevšiml. V některých aplikacích nahradil ty předražené tradiční UNIXy, používá se na webu (protože tam je cena prakticky jediným kritériem), ale jinak nic moc.

Čemu nerozumíte na tomhle? Mě šlo ale primárně o 16+ partitions na jednom disku. To jste fakt nikdy nepotřeboval?

Technicky jde o GPT, tedy GUID Partition Table. Nicméně problém podle všeho neřeší, protože ty partitions musíte adresovat na úrovni storage driveru. A tam je to o major a minor number. Všimněte si, že v devices.txt máte major number pro osm RAID řadičů většiny typů (jedno major number na řadič), na každém může být 32 disků, a na každém disku 15 partitions (partition 0 je celý disk). Samozřejmě když vám přibydou další drivery (HW je na světě spousta), nejspíš pro ně nebudete mít major numbers, protože jde o 8-bitové číslo.
http://www.lanana.org/docs/device-list/devices-2.6+.txt
http://www.tldp.org/HOWTO/Partition/devices.html

Takže pokud nedošlo k nějaké výrazné změně ve správě zařízení v kernelu, podle všeho se na 16 partitions na jednom disku nedostanete, a to ani při použití GPT. Udev to také neřeší - podle všeho jen dynamicky vytváří linky v adresáři /dev.

No vida. Konečně pořádný technický argument, podložený linkem. Upřímně děkuji, dokonce jsem se dozvěděl něco nového. Popsaný systém je sice pořád záplatou nad starým systémem major/minor numbers, a dále to má jistá omezení (například to že stávající drivery používají statické major numbers), ale jednoznačně je to pokrok.

ZFS bych pro řadu věcí nepoužil ani na Solarisu. Na Linuxu se přidávají další problémy: At the moment zfs will build in a 32-bit environment but will not run stably... in the Linux kernel most memory is addressed with a physical address and use of the virtual address space is strongly discouraged... Using the virtual address space on 64-bit Linux kernels is also discouraged... This change is also expected to improve how efficiently zfs utilizes the systems memory. And can be further leveraged to allow tighter integration with the standard Linux VM mechanisms... Additionally, it should be made clear that the ZFS on Linux implementation has not yet been optimized for performance.
http://zfsonlinux.org/faq.html
https://github.com/zfsonlinux/spl/issues?state=open
http://open-zfs.org/wiki/Features#Feature_Flags

Jinak technicky by jistě bylo možné ZFS portovat na Windows. Nicméně ve Windows máme dobře fungující I/O stack, a není důvod ho značný kus nahrazovat pomocí ZFS. Navíc Windows mají NTFS, který je proti většině unixových FS výrazně vyspělejší. A pak je tu samozřejmě nové ReFS.

No a co se týče bootování z GPT, v tom má být jaký problém - o žádném nevím. BTW proč mi linkujete článek týkající se FreeBSD?

FreeBSD je z licenčního hlediska daleko lepší než Linux, a řada detailů implementace je (resp. bývala) lepší. Samozřejmě je to koncepčně pořád zastaralý UNIX, ale to už se asi nezlepší :)

ZFS má na Windows jako obdobu ReFS. Nicméně u ZFS vidím jako problematické to, že nahrazuje některé vrstvy vlastním kódem. Proč má FS nahrazovat storage manager? To je přece i proti unixovým konceptům. Ve Windows jsou Storage Spaces, a nad nimi můžete mít NTFS, ReFS, případně jiné FS.

Deduplikaci ve Windows neprovádí ReFS. Má to na starosti File Deduplication filter driver, který lze použít nad různými FS. Ochrana proti silent corruption je částečně implementovaná v ReFS (checksumy na metadata a volitelně i data, detekce a oprava bit rot atd.), a částečně ve Storage Spaces. Storage Spaces řeší obdobu RAIDu 5 a 1, automatický rebuild pomocí hot spare, případně volného místa na dalších HDD z poolu, intelligent error correction, storage tiers (hodně používaná data na SSD, málo používané na HDD), write-back cache (malé náhodné zápisy končí na SSD a až později jsou přepsány na HDD) atd.
http://technet.microsoft.com/en-us/library/hh831739.aspx
http://technet.microsoft.com/en-us/library/hh831739.aspx

Sun byla čistě unixová firma, a přesto místo rozdělení problému na více komponent vytvořila veliký BLOB jménem ZFS. Technicky k tomu přitom není důvod. Jenže když na Unixech čekáte víc modularity, než utility na command line, může vás to ošklivě zklamat.

Mě ne, ale Sunu by mohla, a dokonce měla.

Ejhle, další chycený na skvělé reálné fungování RAIDu při některých úkonech správce a při jakékoli poruše řadiče v té správné platformě :))) Dobrý den!

No pokud je 90% v unix trhu slabsi kousek, tak nevim ;-))

LOL tady je nekdo fakt mesuge ... a API se jmnuje posix, na wozdil od windows je k tomu i jasna dokumentace a je to normalizovane, tedy vse popsano, vcetne includu temer vsech unixu, casto i zdrojaku ... mi teda k DIGITAL unixu i Tru64 zdrojaky dostali ;-))

Moje dlouhodobá paměť mi říká, že stroj s výkonem X jsem mohl mít na UNIXu za částku Y, nebo na Windows za částku Y/10. Pouhá podpora na ten unixový stroj vyšla stejně draho, jako HW pro ty Windows. Jinak Windows samozřejmě můžete provozovat i 20 let, ale stejně jako ty staré unixy je budete mít bez podpory a plné bezpečnostních děr. Jestli považujete za normální provozovat systémy takovýmhle způsobem, jedná se o chybu na vašem přijímači.

Ohledně LSE by mě především potěšilo, kdybyste vy nebo někdo jiný přišel s tvrdými daty. O mých znalostech architektury Windows do verze 7 netušíte vůbec nic, takže mi uniká, proč se do nich opíráte.