Příspěvky

7096

Vývoj / Re:Pár otázek ohledně unixu a programování

« kdy: 01. 03. 2013, 10:54:54 »

ale zásadní výhoda proti striktně funkcionálnímu přístupu je že toto je volitelné.

Tak to já si myslím přesný opak. Když to řeknu obecně, čím víc omezení na kód kladu, tím silnější tvrzení pak o něm platí. Konkrétně už jsem příklad dával: pokud mám v jazyce *jenom* neměnná data, potom se mi zjednodušší GC, protože o datech s jistotou vím určité věci. Pokud ta omezení jsou volitelná, už o kódu (obecně) neplatí nic víc než co by platilo, pokud by tam ta omezení nebyla vůbec. Čili mi to žádnou výhodu tohodle typu nepřinese.

7097

Distribuce / Re:Služba se nechce automaticky spouštět

« kdy: 01. 03. 2013, 07:52:12 »

Docela hezky položený dotaz. Jenom jsem nějak nepochopil, co je to "job pro upstart"

Zaprvé pokud to chápu správně, porovnáváš spouštění přes upstart s ručním spuštěním. To jsou dvě různé metody a pokud dávají různé výsledky, potom bude chyba s velkou pravděpodobností v upstart skriptech.

Na konci bumblebeed.conf je napsano: "don't use --daemon as Upstart gets confused by that" - musíš teda spouštění přes upstart zkoušet v době, kdy bumblebeed neběží (ověřit pomocí "ps aux | grep bumble").

Pošli výpis, co udělají příkazy:

Kód: [Vybrat]

# sudo /etc/init.d/bumblebeed start
# sudo service bumblebeed start
# sudo start bumblebeed

+ po spuštění každého z těchto příkazů se koukni do logu, jestli se tam neobjevila nějaká informace o tom, co je špatně.

Dokumentace upstart:
http://askubuntu.com/questions/19320/whats-the-recommended-way-to-enable-disable-services
http://upstart.ubuntu.com/cookbook/

7098

Vývoj / Re:Pár otázek ohledně unixu a programování

« kdy: 01. 03. 2013, 07:18:14 »

OK budeme se věnovat neměnným datům.

Já bych už spíš to OT ukončil

7099

Vývoj / Re:Pár otázek ohledně unixu a programování

« kdy: 28. 02. 2013, 18:13:45 »

P.S. z toho referování "odkudkoli kamkoli" plynou ještě další nepříjemnosti, např. pro konstrukci GC. V Erlangu každá data můžou referovat jenom do starších dat, což GC výrazně zjednodušuje A mimochodem, tímpádem se - aspoň teoreticky - i GC dá paralelizovat. A o tom to právě je - pokud jazyk vynucuje nějaké chování se k datům, ta paralelizace je najednou úplně jiný příběh...

7100

Vývoj / Re:Pár otázek ohledně unixu a programování

« kdy: 28. 02. 2013, 18:10:32 »

Koncepce neměnitelných dat je validní argument, ale to neimplikuje potřebu funkcionálního programování.

To už je jenom terminologická debata, do které se nepouštím. Říkejme tomu, jak chceme, podle mě způsob programování s neměnnými daty má budoucnost, ať se mu bude říkat jak chce.

naopak velké množství vláken přímo znemožňuje škálování, kvůli masivnímu přepínání kontextů úloh.

Pokud jsou to vlákna OS. Což v Erlangu nejsou.

To stejné můžeš mít v C/C++/C#/Java, dokonce Windows to od W2K má přímo v jádře.

Jistě. I v C se dají používat funkcnionální principy (neměnnost dat, izolované moduly bez přehnaných vzájemných závislostí). Jak říkám: je to terminologická debata a slovíčkaření, které je k ničemu. Pointa je v tom, že současný OOP-styl, kde jakákoli data můžou být referovaná kdekoli, nemusí být do budoucna to pravé ořechové.

7101

Vývoj / Re:Pár otázek ohledně unixu a programování

« kdy: 28. 02. 2013, 17:20:59 »

Ak si zoberies konvencne napisany program, ktory nejakym sposobom skusa rozne moznosti na styl
for (int i=0; i<VELKA_KONSTANTA; i++) { if (rob_neco(i)) { printf("Hledane cislo je %i!\n", i); }}
tak potom to nemusi byt problem paralelizovat a moze to skalovat pomerne dobre.

To je výborný příklad. Pokud to budeš chtít paralelizovat, musíš to udělat explicitně - přidat tam něco ve stylu "if(fork()...){rob_neco()}" - a pak jeste ty vlakna musis zpatky zesynchornizovat, abys vedel, ze probehlo vsechno.

Funkcionálním stylem uděláš něco jako map(rob_neco(X),List) - a tu paralelizaci máš zadarmo, ten program škáluje sám, bez toho, abys na to myslel. A rovnoměrně vytíží všechny jádra (pokud jich není víc než položek seznamu).

Na tohle nemá klasické nebo funkcionální programování ale přeci vůbec žádný vliv! Když budu mít dobře paralelizovatelný algoritmus, pustím si imperativně spoustu threadů (kolik změřím že mi OS efektivně zvládá na daném hardware), rozdám jim práci a posbírám výsledky. Zbývá jen pečlivě hlídat místa kde musím přistupovat ke sdíleným datům z více threadů

No právě - musíš se rozhodnout, kam paralelizaci explicitně dáš a jak. Oproti tomu software, který je napsaný způsobem, který je sám o sobě "paralelní" (jako jsou Erlangové procesy nebo třeba nějaké ty agenty), škáluje "sám o sobě". Nemusíš ho přepisovat, když ti někdo daruje speciální hw se sto jádry. Prostě vezmeš existující kód, který jsi provozoval na jednojádru a spustíš. (samozřejmě takhle úplně ideálně to fungovat nemusí, ale v principu jo)

7102

Vývoj / Re:Pár otázek ohledně unixu a programování

« kdy: 28. 02. 2013, 15:46:25 »

Od začátku to byl akademický projekt, který nikdy neměl analogii v reálném technologickém světě. Všechny komerčně úspěšné počítače na světě jsou hardwarově zařízeny na imperativní programování.

Prosím v následujícím mě nechytej za slovo: pro mě z praktického hlediska, pokud nebudu nějak moc hledět na teorii, filosofii apod. je funkcionální programování především o tom, jak se pracuje s daty - hlavní koncepcí je omezení/neexistence měnitelných dat. V čistějších formách potom omezení/neexistence funkcí s nedlejším efektem. To potom snadno umožňuje dekompozici na úplně samostatné jednotky, protože neexistují dílená data.

...no a tohle mi nepřijde vůbec v kontrastu s imperativním programováním. Jasně, z teoretického hlediska jsou to odlišné koncepty, ale prakticky ne. Třeba ten Erlang je vyloženě "imperativně laděný" - když v něm píšeš, myslíš v krocích, které se mají udělat. Pokud je FP s něčím v rozporu, tak právě s tím OOP a ani to neplatí doslova (procesy v Erlangu mi přijdou jako nejčistější OOP, které znám - nejenom, že se jim posílají zprávy, ale navíc každý běží s vlastním "vláknem").

Ony ty paradigmata jsou jenom taková teoretická typologie - třeba takové multiagentní programování. To je podle tebe něco jiného než imeprativní?

Celkovým rozšířením, drtivá většina aplikací na světě jsou imperativní programy. Zastoupení Erlangu je mizivé, to se dostáváme do čísel Algolu a Prologu, ty jsou také stále zastoupeny v těch nejrenomovanějších firmách :-)

Tak to jo. Rozšířením jo. Dneska je asi většina programů OOP*, ale to nemusí být navěky, že...

* zmršené okleštěné OOP ve stylu C++

No jenže to spolu právě úzce souvisí. Může se lehce stát, že objektové programování tu mnohojadernost nebude moc dobře zvládat... I když těžko říct, jestli to s tou mnohojaderností bude tak žhavé - spíš bych možná čekal pomalé vracení kyvadla zpátky - spíš směrem k úsporným a malým zařízením.

Imperativní programování zvládá mnohojadernost od samého počátku více než 30 let a nezdá se že by s tím byly nějaké zásadní potíže.

Jistěže s tím jsou potíže. Konvenčně napsané programy nemůžou škálovat a neškálují ani zdaleka lineárně k počtu vláken. U programů napsaných funkcionálně (z hlediska práce s daty - viz nahoře) by to aspoň teoreticky mohlo být daleko lepší - a praktická měření tomu celkem odpovídají viz např. http://kth.diva-portal.org/smash/get/diva2:392243/FULLTEXT01 - obrázek 4.1 na straně 58 (vytištěné číslování). (jasně, je to jenom benchmark, vím)

Mnohojadernost samozřejmě leze i do mobilních zařízení, viz 3/4 nových mobilů je vícejaderných a nic nenasvědčuje k nějaké větší změně.

Tady si asi nerozumíme ve slovu "mnoho". Člověk podle mě není živočich s mnoha nohama stejně jako dvoujaderný proocesor není mnohojaderný. Pokud řeknu mnoho, představuju si něco jako třeba 10, 60 nebo 1000... Chtěl bych vidět, jak by konvenčně napsaný (třeba OOP) program škáloval od jednoho po tisíc vláken...

7103

Vývoj / Re:Pár otázek ohledně unixu a programování

« kdy: 28. 02. 2013, 11:15:44 »

Sorry za OT, ale funkcionální programování nemůžu nechat hanět!

To je normálka, funkcionálnímu programování se konstantně prorokují zářné zítřky více než 25 let

Co přesně máš namysli? Já mám pocit, že cool bylo v souvislosti s přehnanými očekáváními v době zlatého věku AI (60.-70. léta) a potom bylo převálcováno objektovým, protože se asi mělo za to, že objekty líp odpovídají lidskému myšlení.

, ale ani za tak dlouhou dobu vůbec ničeho nedosáhlo

To je ale otázka, čím bys to chtěl měřit. Popularitou? Jasně, máš pravdu. Úspěšnými projekty? Tady už to začíná být trochu vachrlaté - třeba v Erlangu je napsaných pár slušně renomovaných a používaných softů průmyslové kvality (třeba ejabberd, RabbitMQ).

Budoucnost je když tak v paralelním programování z důvodu mnohojadernosti dnešních CPU a GPU.

No jenže to spolu právě úzce souvisí. Může se lehce stát, že objektové programování tu mnohojadernost nebude moc dobře zvládat... I když těžko říct, jestli to s tou mnohojaderností bude tak žhavé - spíš bych možná čekal pomalé vracení kyvadla zpátky - spíš směrem k úsporným a malým zařízením. Výkonu už je všude až zbytečně moc... Takže možná bude světem hýbat spíš embedded segment... Nevím, těžko říct.

7104

Server / Re:Samba 4: primární a sekundární doménový řadič

« kdy: 28. 02. 2013, 01:44:26 »

Čistě NT4 domény jsou zaříznuty už od W7. Viz.

Je možný, že mám zmatek v pojmech, do Windows fakt moc nevidím, klidně se mi smějte ale W7 normálně v doméně se sambou 3 mám, takže to pro mě problém není. Problém by to začal být až ve chvíli, kdy by Windows X začaly vyžadovat AD. Což zatím nenastalo (AFAIK). Jakej je rozdíl mezi NT4 doménou, ne-AD doménou (samba3) a AD doménou fakt nehodlám řešit, dokud jsem schopnej počítač s W7 přidat do domény s PDC samba3, uživatel se přihlásí a má k dispozici všechno, co má uživatel Win XP.

Ahoj Davide, k té první otázce.. Tohle jde udělat i se starší Sambou v3.x [...] Kvóty už si řešíš na úrovni filesystému v linuxu. Na automatické vytváření složek při prvním přihlášení  existuje tušim PAM modul, nebo jedině napsat skript..

No to je právě otázka toho, o co vlastně Davidovi jde. Pokud chce primárně rozchodit takovéhle věci, tak si bohatě vystačí se starou sambou a běžnými unixovými postupy. Pokud si to ale chce někde naklikat, nebo chce, aby se to chovalo přesně jako Win Server, tak to už jsme trochu někde jinde...

* aby měl každý uživatel svůj H:, to je prehistorická záležitost, která funguje x let.
* pokud má backend fs kvóty, tak tam víc uživatel prostě nezapíše, to je taky jasný a taky to funguje x let. Otázka je, jakou infrastrukturu chci k tomu, aby se to uživatel nějak korektně dozvěděl (že mu selže zápis asi není ideální). Takže otázka je spíš, jestli si chci kolem toho psát nějaké skripty, které uživatele včas informují (třeba mailem), nebo jestli to nová samba umí uživateli sdělit přes nějaké krásné windowsovské okýnko...
* vytvoření home/profilu je to samý: nejjednodušší je ho vytvořit zároveň s vytvářením uživetele. Nevidím důvod, proč ho vytvářet online, ale pokud to David chce, jde to samozřejmě přes PAM (home) + \\netlogon\Default user (win profil)
* jakou verzi 4kove samby pouzit, to uz je vylozene filosofická debata... Buď preferuju to, co mi dává distribuce, nebo preferuju poslední bugfixy a musím to do toho OS nějak dostat a spravovat si to sám - úplně off topic věc...

7105

Software / Re:Bacula - problém při spuštění

« kdy: 28. 02. 2013, 01:24:23 »

Nešlo by ten dotaz formulovat trochu přesněji? Bacula je výborný a mocný nástroj, ale musíš rozumět tomu, jak funguje. To není něco jako TimeMachine v MacOS, kde klikneš na "ON" a ono to funguje samo od sebe, zálohuje a ty seš v klidu. Pokud Baculu použiješ blbě (což se stane velice snadno), je to jako bys nezálohoval vůbec.

Dobře míněná rada:

Odpověz si na následující otázky:
1. potřebuju zálohovat víc strojů (víc než deset)?
2. potřebuju zálohy ukládat podle přesně daného plánu na různá úložiště?
3. chci zálohování nějak složitěji ovládat vlastními skripty nebo si k němu udělat vlastní rozhraní?
4. mám dobrý důvod, proč proces zálohování rozdělit na jednotlivé úlohy (ovládání, plánování, úložiště, klient)?
5. chci se naučit základní principy "velkých" podnikových zálohovacích systémů?

Pokud jsi na žádnou otázku neodpověděl ano, není bacula nejspíš dobrý nástroj pro tebe. Zkus se zeptat zkušenějších, který by se pro tvé účely hodil líp.

Na spusteni baculy urcite nepouzivej svuj ucet ale root

Jediná komponenta baculy, kterou je dobré spouště pod rootem, je klient (FD). U ostatních je to zbytečnost a potenciální riziko. 

7106

Server / Re:Samba 4: primární a sekundární doménový řadič

« kdy: 27. 02. 2013, 21:12:00 »

Jeste teda kdyz uz jsme u toho vyctu vyhod, bych doplnil dve prinejmensim hypoteticke vyhody:
 
 * vyvojari samby se az v posledni dobe dostali k poradne specifikaci MS protokolu, nevim, jestli by tam nemohlo byt neco, co by odhalilo, ze nejaka vec je v trojce implementovana blbe a nikomu by se nechtelo to ze ctverky backportovat...

 *  MS by teoreticky mohl NT domeny zariznout, ale to zas nebude tak rychle, takze bych se toho az tak nebat - a na softy tretich stran to zas takovy vliv nema (vzhledem k tomu ze tak jako tak je tam z jejich pohledu nestandardni samba...)

7107

Server / Re:Samba 4: primární a sekundární doménový řadič

« kdy: 27. 02. 2013, 21:01:45 »

  zacina to vypadat na boj a to nicemu neprospeje.

Bohuzel ano. Omlouvam se za svuj podil viny, trochu me vyprudilo, kdyz na otazku "co to umi noveho?" dostanu odpoved "jestli nevis, co to umi noveho, tak to nepotrebujes"... Ale nechme OT, tisicere diky tobe za kvalitni odpoved.

To je asi spis dotaz na win adminy (coz na rootu asi neni prave mist)

Predpokladam, ze kdyz nekdo chce udelat tak radikalni krok, jakym imho nasazeni uplne nove samby je, ma to trochu osefovane a vi dost dobre, proc to dela...

Navic si myslim, ze GPO je rozsirenejsi jak WPKG, takze pro to clovek najde uz predpripraveny balik snadneji (ano pro wpkg existuji, ale kvalita je z meho pohledu mizerna). A ono ani samo WPKG napr. na noteboocich neni idealni a obcas trpi podivnymi problemy, ktere se spatne hledaji.

GPO neznam, takze nevim, jake baliky pro nej jsou nebo nejsou, ja to mam spojene s msi baliky a ty pomoci wpkg nainstaluju taky. Kvalita potom zalezi na baliku...
Pokud jde o softy, ktere se pomoci wpkg instaluji jinak nez z msi, tak to vrele souhlasim s mizernou kvalitou (myslim, ze by wpkg.org udelalo dobre, kdyby stanovila nejake prisne guidlines, kterych by se autori navodu museli drzet. Nebo rovnou nejaky repozitar jako treba macports...
No a posledni vec: nastavovani politik v registrech misto jejich naklikani v gpedit.msc, to je opruz. S tim souhlasim. Ale je to pro me spis okrajova zalezitost, kterou se mi zatim vyplati vedome zkousnout...

Nevidim duvod, proc by toto neslo udelat i nad samba4 tooly.

Jasne, koneckoncu je to LDAP (i kdyz se trochu obavam preplacanosti tech schemat a ruznych typicky Microsoftich komplikaci...). Otazka zni ale opacne ("co samba 4 prinasi"), takze tohle je irelevantni.

Kerberos to resi a neresi. Ja to udelane mel, ale ve win je s tim vice potizi, protoze win se vuci kerberovi non-AD moc hezky nechovaji.
A bohuzel i mnohe aplikace stale maji s kerberem potize (zvlast kdyz clovek roubuje MIT krb do win).

Asi jsem se vyjadril trochu nesikovne. Chtel jsem rict "ok, tohle by AD-krb vyresil". Problemy s neAD-krb tak nejak predpokladam, mj. proto jsem se do implementace zatim nepoustel. Zas tak moc to nepotrebuju, abych se s tim paral a nakonec zjistil, ze to kvuli nejakym windowsoidnim priblblostem ciste udelat nejde...

Nerozumim proc se ptate (a proto mi to neprijde jako legitimni otazka), kdyz si zaroven sam odpovidate. Mate to odladene a funkcni a nechcete po tom vic, nez co to umi. Takze prechod je pro vas jen prace navic.
Timto odpovite na jakkykoli argument (bud uz to mate nebo to nechcete).

Nee Ptam se proto, ze by mi treba nekdo, kdo se v tom vyzna, mohl sdelit sladkou novinu, ze AD ma taky tu vlastnost, ze samo bere telefony a ze vsech serveru, kde je nainstalovano, padaji v petiminutovych intervalech tisicovky (cili by prisel s necim, o cem nevim, v tom seznamu jsem to neuvedl, a zaroven je to pro me zajimavy).

Jinak zkusim dat do placu bezpecnost, ktera hovori ve prospech AD - pokud odriznete ukladani starych hashu hesel pro podporu starych windows.
A zase na druhou stranu pridam, ze mi samba 4.0 jeste neprijde natolik odladena, aby na ni prechazel nekdo, kdo chce minimum problemu (staci sledovat mail list samby).

Ten prvni argument docela beru. I kdyz pokud je LDAP spravne nakonfigurovany, tak dostat se k hashum je priblizne stejne tezke jako kompromitovat cely server, takze konkretni cena tehle bezpecnosti navic zavisi na okolnostech... U me je tak mala, ze prevazuje nad tou druhou nevyhodou - upgradu samby se desne bojim, protoze je to uzivateli-nejblizsi hyperkriticka komponenta, ktera se zaroven desive blbe ladi. Po nekdejsich experimentech s oplocky uz se na to bojim sahnout a jsem rad za kazde nove rano, kdy to jede v odladene konfiguraci

----
Jeste jednou velky dik za konstruktivni odpoved.

7108

O serveru Root.cz / Re:Fórum nefunguje kvůli gemius.pl

« kdy: 27. 02. 2013, 19:17:56 »

Eště doporučuju doplnit přihlašováním výhradně přes Fejsbůůůk. 

Radeji MS Live. At linuxaci puknou vzteky

7109

O serveru Root.cz / Re:Fórum nefunguje kvůli gemius.pl

« kdy: 27. 02. 2013, 19:11:29 »

Právě proto by na tyhle "čtenáři žádané a sponzorované" články měli platící uživatelé náhled před zveřejněním a mohli se tam v diskuzi vylejt ještě před vydáním. Po vydání by se nastavila diskuze nová.

A tak to je dobrej napad! Anebo diskusi otevrit jenom pro platici, to by teprv byl odvazny krok

7110

O serveru Root.cz / Re:Fórum nefunguje kvůli gemius.pl

« kdy: 27. 02. 2013, 18:35:52 »

Nesmíš to brát jako formu zisku, ale jako formu prestiže. Když to budeš dělat pro zisk, bude to stát za starou bačkoru. Jinak, také bych platil.

Ja bych to jako formu prestize bral, pokud by se v komentarich pod clankem objevovalo vic podekovani, vic konstruktivni kritiky a doplneni a min debilniho frflani, ze autor je idiot (sorry za expresivni vyrazivo, ale chtel jsem vystihnout pointu).