Příspěvky

2836

Windows a jiné systémy / Re:Lze se vyhnout Active Directory DC?

« kdy: 22. 07. 2016, 12:34:21 »

Myslím jsme se nepochopili. Seznam s uživatelskými hesly by měl být jen jeden.  Mluvím o obezličce, že by šlo zařídit i to, aby se uživatel po přihlášení do svého profilu na počítači nemusel přihlašovat na CIFS (neboli SMB neboli sdílení windows neboli file server). Nebo jen jednou, prostě by si jeho uživatelský profil na jeho počítači heslo zapamatoval.

Proč složitě popisovat něco, co má název? Říká se tomu single sign on a jde to udělat bambilionem různých způsobů. AD není žádná magická hůlka, AD je (zprasený) kerberos. Pokud chceš stejnou funkcionalitu bez AD nad normálním LDAPem, je to instalace jednoho balíku (kerberos) a nastavení jednoho konfiguračního souboru. Nedělejte z AD zlatý tele.

(P.S. že může být složitý donutit různý windowsovský služby autentizovat proti něčemu jinýmu, než windowsímu prasokerberu, je jiná pohádka na jiné zimní večery, milé děti )

2837

Windows a jiné systémy / Re:Lze se vyhnout Active Directory DC?

« kdy: 22. 07. 2016, 12:29:09 »

Dobry, ale kdybys prihodil nejake nazvy softu, ktery to umi, bylo by to jeste lepsi.

reg, PowerShell, WPKG, ansible, salt, puppet, .... (následuje dlouhý seznam nástrojů pro cfg management)

Chceš si hodnoty, které se mají nastavit, načíst z nějakého http API? Není problém. Chceš to nastavovat podle JSONu zveřejněném na githubu? Není problém.

Ale jinak je GPO nenahraditelný. Zvlášť pokud dlouho dumáte nad tím, jak si přivodit syndrom karpálního tunelu.

2838

Windows a jiné systémy / Re:Lze se vyhnout Active Directory DC?

« kdy: 22. 07. 2016, 12:09:56 »

Prave ze GPO je to, co je hlavni vyhoda DC a neexistence obdobneho na platforme Linuxu

Neexistence čeho přesně? Pro Linux mám k dispozici asi tak sedm různých velkých nástrojů pro configuration management, které umí věci, o kterých se AD GPO ani nezdá. Jestli bych v něčem chtěl vidět problém, tak v různosti distribucí, ale tak to se řeší tím, že mám v rámci organizace pokud možno jenom jednu, maximálně dvě (stanice, servery).

Já tedy nevím, ale mě věci jako
- instalace tiskáren a aktualizace ovladačů pro tiskárny
- nastavení firewallu
- instalace/aktualizace softwaru ze sítě
- přesunutí uživatelských složek (dokumenty, obrázky...) na síť kvůli zálohování
- mapování síťových disků
- nastavení prohlížeče (IE, Chrome)
- instalace doplňků do prohlížeče (Chrome)
- asi miliony dalších nastavení podle potřeby

přijdou jako užitečné a určitě kvůli tomu nehodlám obíhat jednotlivé počítače jako magor.

Je potřeba to vzít od podlahy:

Co dělá GPO? Automatizovaně nastavuje registry. Jaké registry? Čert ví. V registrech se nikdo pořádně nevyzná a pořádně zdokumentované to není. Odkud bere informace, co má jak nastavit? Z jakési replikované databáze. Kdo a jak tu databázi replikuje? Jaké je její schéma? Co dělat, když se sync rozesere? To nechtějte vědět. Je to na podání výpovědi a zapálení baráku.

Takže pokud hledáme náhradu GPO, co hledáme? Nástroj, který umí nastavit registry na základě nějaké databáze.

A teď mi vykádej o tom, že nic takového neexistuje, nejde udělat, a pouštět se do toho je vyrábění zlata foukáním kouře do vody.

Mimochodem, když jsme u toho, znáš význam všech položek v AD LDAPu? Umíš je ručně spravit, kdyby došlo k nějakýmu problému. Já jo. Úplně v pohodě pomocí ldapvi.

2839

Vývoj / Re:Rozdíl mezi návrhovými vzory Přepravka x Obálka x Holder

« kdy: 21. 07. 2016, 01:24:34 »

Mám za to, že v každém dynamickém jazyce, tedy i v JS, není obecná implementace monád problém.

V nějaké podobě určitě jo, ale když tam není ta typová kontrola, tak to dost postrádá tu eleganci ... degraduje to pak na celkem prostý skládání funkcí, přičemž složenina možná bude fungovat a možná vyhodí nějakou obskurní výjimku někde uprostřed Na těch promises v JS je to vidět dobře.

2840

Vývoj / Re:Rozdíl mezi návrhovými vzory Přepravka x Obálka x Holder

« kdy: 20. 07. 2016, 18:22:43 »

Nutnost používání monád je také problém, který v jiných jazycích neexistuje.

Monády nejsou problém, monády jsou řešení. Velice efektivní způsob, jak pomocí vysoké abstrakce řešit spoustu rozdílných věcí jednotným způsobem. "Být monádou" je vlastnost nějaké struktury (ta struktura splňuje "monadické zákony") - buď tyto abstraktní vlastnosti umíš využít pomocí obecného kódu, nebo neumíš. Když neumíš, je to vždycky horší, ne lepší.

Třeba ty mnou už x-krát zmíněné promisy v JS taky monadické zákony splňují, ale JS nemá pořádný aparát na práci s obecnou monadickou strukturou. X let zkoušeli dělat asynchronní věci přes callbacky, až je konečně napadlo použít monadický přístup. Ale bohužel ad hoc, ne obecně.

Žádná "nutnost" používání monád ani v Haskellu není. Ale je to asi nejefektivnější způsob, jak spoustu různých problémů vyřešit pomocí jedné abstrakce.

Je to jako bys měl spešl fci mapint na mapování fce přes integery a spešl mapstr pro mapování přes stringy. Není to zbytečný? Není lepší použít jednotnou abstrakci "mapuju přes jakýkoli typ, který funkce přijímá jako parametr"? S monádama je to přesně stejný. Nemusíš je používat, ale byla by to veliká hloupost, pokud to jazyk umožňuje.

2841

Sítě / Re:Neobvyklý projekt - pokrytí WiFi signálem

« kdy: 20. 07. 2016, 17:51:02 »

ale zadavatel vysloveně nechce aby WiFi signál dosáhl na okolní budovy

Řekl bych mu: a dovedete si představit dát na to náměstí osvětlení tak, aby v okolních budovách byla černočerná tma?

2842

Odkladiště / Re:Som rozcarovany z IT

« kdy: 20. 07. 2016, 09:15:56 »

Návrh systémů, řízení projektů, analýza dat, UX, grafika, ...

Jo a ještě embedded. Což by mohla být zajímavá možnost, pokud tě trápí (ne)kvalita kódu. Běž zkusit programovat nějaké kritické systémy, kde jsou jasně dané garance, omezení a verifikace. Ale silně pochybuju, že by tě to ve finále bavilo o moc víc. Spíš bych to viděl na normální vyhoření...

2843

Odkladiště / Re:Som rozcarovany z IT

« kdy: 20. 07. 2016, 09:09:14 »

Databáze, správa systémů, bezpečnost, aplikační podpora, HW... zapoměl jsem na něco velkého?

Návrh systémů, řízení projektů, analýza dat, UX, grafika, ...

2844

Studium a uplatnění / Re:Vaha vysokej skoly

« kdy: 19. 07. 2016, 09:49:56 »

... a ak by som Bc dal na nejakej praktickejsej skole a ing prisiel dokoncit na teoretickejsej muni? Je to realne alebo mozem snivat? Velmi nadvazoval Ing na Bc ?

To bych nedělal. Jednak se teoretičnost FI MUNI za posledních deset let postupně snižuje a pak taky v Bc. byla ještě celkem teorie, která se dá občas využít, minimálně jako inspirace (když nepočítám matiku - ta byla v podobě, v jaké jsem ji měl já, podle mě z velké části zhola zbytečná, ale zas to byly myslím jenom 4 semestry, což se prostě musí přežít no). V magistrovi se ta teorie trošku prohlubuje, čili se dostáváš do věcí, které už nejsou v normální práci využitelné prakticky vůbec. Čili přechod z Bc. na praktické škole na Mgr. na MUNI by mohl být docela šok

Spíš běž klidně i na Bc. na MUNI, ale počítej s tím, že praktičtější dovednosti budeš muset získávat jinak/jinde. Buď na částečný úvazek pracovat úplně jinde, nebo se aspoň zapojit do nějaké laboratoře na MUNI. Myslím, že to není špatná varianta - škola ti dá trochu obecnější náhled na věci a praxe tě naučí, jak se reálné problémy doopravdy řeší. To první je prevence toho, aby z tebe nebyla tupá lopata navrhující jenom hloupá "inženýrská" (bez urážky) řešení, to druhé je prevence toho, aby z tebe nebylo namistrovaný pako, který je úplně mimo a vymýšlí vzdušný zámky.

2845

Studium a uplatnění / Re:Slušná firma v Ostravě pro Javistu?

« kdy: 18. 07. 2016, 16:21:00 »

Podle průzkumu platů těch 40 tisíc je asi reálných, ale asi pro klíčové zaměstance. Já jsem po 10 letech u stejné firmy k té částce jen přiblížil.

Jenom tak pro zajímavost: ty částky píšete v hrubým, jo? (Blbá otázka, ale jsou tady experti, co jsou schopní říkat čistej a ještě na tom trvat...)

2846

Studium a uplatnění / Re:Vaha vysokej skoly

« kdy: 17. 07. 2016, 23:17:54 »

skoro kazda IT fakulta si robi reklamu na tom, ako skvele pripravuje absolventov na prax.

Jistě. A každá soukromá škola v okresním městě, udělující titul MBA, připravuje skvělé manažery. A každý čistící prostředek dokáže odstranit skvrny, na které se jiné prostředky vůbec nechytají. A ještě je k nim deset šéfkuchařských nožů zdarma. A když každý den sníš jednu bobuli lisovaného zeleného ječmene, budeš skály lámat.

Ber to tak, jak to je: tohle je reklama. PR. Jako každé jiné.

Skutečnost je spíš taková, že

• v podstatě neexistuje způsob, jak s dobrou jistotou zjistit, nakolik studium pro pozdější praxi pomůže - nejrozumnější je asi dívat se na mzdy absolventů, ale to má taky spousty háčků. Největší je ten, že škola může fungovat čistě jako filtr inteligentních lidí a co učí je celkem jedno, hlavně že je to těžké a zaměstnavatel má jistotu, že absolvent je chytrej, protože to dal.
• se může stát (a netvrdím, jak často tomu tak je), že učitelé vůbec neví, co se skutečně v praxi děje. Z jednoduchého důvodu: oni v té praxi nejsou. Jsou na škole. A jsou placeni za jiné věci než za jaké jsou placení lidé v praxi. (Nehodnotím to a nikoho neobviňuju, jenom konstatuju, že výzkum, výuka a praxe jsou velmi rozdílné oblasti lidské činnosti)
• příjmy škol jsou velice málo (prakticky vůbec) závislé na tom, jestli učí využitelné nebo nevyužitelné věci - školy mají velmi malou motivaci zjišťovat si, co se doopravdy v praxi děje, a výuku tomu aktivně přizpůsobovat.

Asi nejrozumnější, co bys mohl udělat, je promluvit si s nějakými lidmi z praxe, co jim osobně škola dala a jestli by ti ji doporučilli taky. I tak si ale budeš muset to, co ti řeknou, vydělit dvěma, protože lidi typicky nemají chuť přiznávat, že  na nějaké velké investici prodělali, spíš máme potřebu si to racionalizovat - že to vlastně k něčemu bylo... naučilo nás to myslet, poznali jsme život na koleji, naučili jsme se jíst příborem a používat rozvité věty a tak.

Na to, co zajímá HR, se vykašli úplně. To je naprosto irelevantní. V HR zhusta sedí pitomci, kteří o té práci nemají vůbec šajnu a jejich úlohou je jenom udělat hrubý předvýběr, aby skutečně kompetentní člověk nemusel ztrácet čas se zjevně úplně nevhodnými adepty. A hlavně: stačí být jenom trochu schopný a žádné přijímací pohovory nikdy absolvovat nemusíš, protože si prostě jenom budeš ty vybírat, kterou nabídku přijmeš (pořád ještě žijeme v situaci velkého převisu poptávky a v nejbližších 10-20 letech se to pravděpodobně moc nezmění.

2847

Server / Re:Zkušenosti s cloudem v ČR

« kdy: 13. 07. 2016, 10:45:44 »

jinak by mne zajimalo, jak si firma, ktera by v cloudu provozovala cely svuj business [...] by si mela zajistit dostupnost sluzeb 99,999999999%

Musela by na aplikacni urovni dosahnout garanci, ktere se jinak (treba u nejakeho mainframu apod.) dosahuji na nizsich urovnich. Podle typu aplikace to muze byt ruzne slozite. Taky skoro u kazde aplikace jsi schopny tolerovat nejakou degradaci funkcnosti sluzby - nepotrebujes, aby ti s extremne vysokou dostupnosti jelo porad vsechno a v cele parade. Nejake to obcasne zahozeni nedulezitych zprav, pozdrzeni zpracovani zprav apod. ti typicky nevadi, pokud to mas dobre rozmysleno. Takze problem nezni "jak dosahnout deviti devitek", ale spis "jak dosahnout takovych garanci, ktere pozadujeme".

jak se zajistit proti zmene VOP (nejdriv nabrat klienty kdyz ptacka lapaji ..) a nutnosti nasledne migrace na jiny cloud, neochote firmy provozujici cloud soustavne snizovat ceny poskytnute sluzby tak jak vseobecne v case klesaji ceny za prenos dat atd ...

To je jednoduche: nijak. Cloud = vendor lock in. Tecka.

2848

Vývoj / Re:Má Python budoucnost?

« kdy: 16. 06. 2016, 00:23:47 »

Aha, já to tam nevidím :-)

To se stává, že člověk sem tam něco nevidí.

2849

Vývoj / Re:Má Python budoucnost?

« kdy: 16. 06. 2016, 00:06:31 »

Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?

Kromě toho tam vidím neplatné zobecnění "co platí pro Spring, platí pro Javu". Proto jsem ho korigoval.

2850

Vývoj / Re:Má Python budoucnost?

« kdy: 16. 06. 2016, 00:03:48 »

Ja myslim, ze hlavni vlakno neblokuje, ale sada aktoru sdili jedno vlakno - muze tedy blokovat jine aktory. Future, co jsem alespon cetl, se moc nedoporucuje a lepsi je pouzivat docasne actory (pripadne v jinem thread poolu blokujici aktory).

Nejvetsi rozdil oproti ostatnim pristupu jeto rozdeleni dat mezi aktory - zadny (nebo minimalni) globalni stav.

Řekl bych, že v téhle oblasti se ty pojmy dost melou a těžko se dá říct něco, co by bylo úplně zjevná ověřitelná pravda

Ideální stav je samozřejmě takový, jaký má Erlang, jak jinak - každý actor může mít bez problému vlastní (zelené) vlákno a zároveň jich nemůže mít víc. I tak se ale nedá vyhnout tomu, že actor, který čeká na nějakou externí událost (EDIT: nemusí být ani externí, stačí nekonečný výpočet nebo cyklus vzájemných čekání), může blokovat další actory. Čistě proto, že čekají na zprávu od něj. Pokud čekají synchronně (blokovaně) a bez timeoutu, je z toho deadlock. Pokud s timeoutem, je potřeba nějak ošetřit chybový stav. Pokud čekají asynchronně, je to relativně ok, ale vyžaduje to neúměrné množství logiky kolem zjišťování, na co všechno vlastně ještě čekám, jak dlouho na to mám čekat, co mám udělat, až se to stane atd., takže tohle se uvnitř actoru prakticky vůbec nepoužívá, pokud ta funkcionalita není ze své podstaty asynchronní (není svázaná s žádným stavem, proto si k ní nemusím nic pamatovat, jenom ji odpálím a až přijde odpověď, tak na ni reaguju pořád stejně).

Takže shrnuto podtrženo, ani v (reálně dosažitelném) ideálním stavu nemůžu mít žádné silné garance o tom, že nedojde ke stavu, který si moc nepřeju (deadlock nebo chyba). Čili pokud actory poháním nějakým poolem threadů, může to (imho) fungovat docela dobře, pokud je to dobře navržené a dobře dimenzované.

Typicky i v té první "ideální" situaci chci mít věci, které můžou blokovat, uzavřené do samostatného actoru, takže pokud je tohle řešení doporučované[1] v Akka, není to žádná velká ostuda

[1] http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management