Příspěvky

916

Server / Re:Monitoring VPS a upozornění SMS

« kdy: 28. 04. 2018, 19:22:25 »

Používám Monit a posílání přes mail2sms bránu od https://sms.sluzba.cz/

Úplně ideální to sice není, ale funguje to. Nevyužitý kredit bohužel na sms.sluzba.cz po roce propadne.

917

Distribuce / Re:lahka distribucia pre QEMU

« kdy: 27. 04. 2018, 20:40:05 »

...

Rád bych ti pomohl, ale přiznám se, že tomu pořád nerozumím. Ty chceš jet v režimu emulace, protože:

• Si myslíš, že to je bezpečnější než v režimu virtualizace?
• Nebo chceš na X86 CPU spouštět aplikaci/browser pro ARM CPU?
• Nebo tu emulaci máš protože tvůj CPU nepodporuje virtualizaci, tzn, VT-x?

Asi si myslí, že to je bezpečnější než v režimu virtualizace. Aby mělo cenu tohle řešit, musel by mít tazatel extra požadavky na bezpečnost ale to by se zase asi takhle neptal. Podle mě nejsou ty požadavky a představy s nimi spojené úplně zdravé, ale samozřejmě se mohu mýlit

918

Vývoj / Re:OSGI vs Servletové kontejnery

« kdy: 27. 04. 2018, 20:27:08 »

Řekl bych, že nemá moc smysl to porovnávat - servletové kontejnery jsou na servlety a OSGi je na cokoli. Podívejte se na výklad těch pojmů třeba na wikipedii.

Na wikipedii nemůže mět doplňující otázky.

To je pravda, ale přečíst si ty pojmy v encyklopedii je dobrý začátek. Každopádně Youda to myslím vysvětlil hezky.

919

Distribuce / Re:Lehká distribuce pro QEMU

« kdy: 27. 04. 2018, 14:38:34 »

Tak jsem se právě kouknul a při použití virtmanagera beží qemu pod uživatelem libvirt-qemu. Takže tazatel asi řeší neexistující problém.

920

Vývoj / Re:OSGI vs Servletové kontejnery

« kdy: 27. 04. 2018, 14:28:16 »

Řekl bych, že nemá moc smysl to porovnávat - servletové kontejnery jsou na servlety a OSGi je na cokoli. Podívejte se na výklad těch pojmů třeba na wikipedii.

921

Distribuce / Re:Lehká distribuce pro QEMU

« kdy: 27. 04. 2018, 12:13:07 »

Pokud jde jen o tohle, tak myslím, že by to šlo upravit, aby root nebyl potřeba. Je potřeba hlavně přístup k /dev/kvm a možná nějaké věci související se síťováním apod.

Ale zamyslel bych se, zda to je opravdu dobrý nápad vzhledem k zamýšleným cílům. Pro běžné desktop použití je libvirt, virtmanager, kvm a qemu dostatečně dobré a snad i dostatečně bezpečné.

Pokud si stále myslíte, že to potřebujete, tak existují distribuce, které to mají vyladěné s cílem maximální bezpečnosti - každá aplikace běží ve vlastním kontejneru (myslím, že jde o kontejnery) apod. Dosažená bezpečnost bude IMHO lepší, než když si budete něco vytvářet sám.

PS: Jak spustit qemu kvm bez roota se dá najít na netu. Nevypadá to tak složitě.

922

Distribuce / Re:Lehká distribuce pro QEMU

« kdy: 27. 04. 2018, 12:12:03 »

Pokud jde jen o tohle, tak myslím, že by to šlo upravit, aby root nebyl potřeba. Je potřeba hlavně přístup k /dev/kvm a možná nějaké věci související se síťováním apod.

Ale zamyslel bych se, zda to je opravdu dobrý nápad vzhledem k zamýšleným cílům. Pro běžné desktop použití je libvirt, virtmanager, kvm a qemu dostatečně dobré a snad i dostatečně bezpečné.

Pokud si stále myslíte, že to potřebujete, tak existují distribuce, které to mají vyladěné s cílem maximální bezpečnosti - každá aplikace běží ve vlastním kontejneru (myslím, že jde o kontejnery) apod. Dosažená bezpečnost bude IMHO lepší, než když si budete něco vytvářet sám.

923

Distribuce / Re:Lehká distribuce pro QEMU

« kdy: 26. 04. 2018, 21:20:28 »

QEMU bezi v rezime "emulacie CPU" a hladam lahku distribuciu, na ktorej pustim broswer a budem pouzivat jednu webovu stranku/aplikaciu.

Fedora LXDE - len pri pravom kliknuti mysou trva 5s kym vybehne kontextove menu. Fakt tam ocakavam len ten broswer. Nieje niekde k stiahnuti image s Gentoo alebo nieco take lite. Dovod ku komplikacii je bezpecnost a napr. moznost pustit QEMU s pravami bezneho uzivatela. Ak nic ine, tak aj ten VirtualBox mi bude dobry.

Vdaka za tipy a rady

Rychlost virtualizovaného OS na distribuci hosta ani hostitele moc nezáleží. Zásadní je ale použít KVM, pak se dá ten virtualizovaný OS normálně používat. Pro KVM musí být podpora v CPU, což dnes většinou už je. Pokud je potřeba virtualizovat jinou CPU architekrutu, například ARM, pak nejde KVM použít a je to skutečně dost pomalé. Ale to asi nebude Váš případ.

Výběr virtualizované distribuce má význam jen tehdy, pokud záleží na rychlosti bootu nebo objemu dat na disku,případně na nějakých speciálních vlastnostech. Tam mohou být rozdíly velké.

924

Software / Re:Doporuceni SW pro planovani zahrady

« kdy: 22. 04. 2018, 16:46:30 »

Zkuste se podívat, jak se navrhují permakulturní zahrady - pojem „inteligentní zahrada“ tam neznamená, že je zahrada prošpikovaná technikou, ale že té techniky je potřeba co nejméně, protože o vše se postará inteligence zahrady samotné (umístěním mikrozón, výběrem rostlin, využitím terénu apod.). Vzniknou tak opravdu krásné zahrady a jsou i lidé, kteří je dokážou okořenit technologií a dělat třeba nějaký drobný výzkumný projekt nebo zajistit energetickou soběstačnost (solární zdroje pro čerpání vody...). Takže i technicky nadaní lidé se uplatní. IMHO alternativní pohled na věc, před kterým se doporučuju zcela neuzavírat. Minimálně postupy při kreslení návrhu jsou inspirativní (nevím ovšem, zda nějaký software permakulturní principy zohledňuje...).

925

Odkladiště / Re:Váš názor na web (pls)

« kdy: 21. 04. 2018, 18:29:53 »

Nová verze mi přijde lepší, ale nejsou tam využity barvy pro lepší orientaci uživatele. Vypadá trochu narychlo spíchnutá. Uvítal bych tam zřetelnější vizuální rytmus, abych se orientoval na co to zrovna koukám. Ale i tam mi přijde lepší než původní web. Myslím, že u tazatele hraje roli zvyk - i na horší design se člověk „naučí“.

926

Vývoj / Re:Generalizovaný název objektu

« kdy: 21. 04. 2018, 18:08:36 »

Pokud to bude jen na serveru, pak by to mohlo být něco jako AbstractRecord (abstraktní třída). Z toho se bude dědit a povede to k těsné vazbě mezi třídami, která Vás pak časem bude omezovat. Zlepšení by šlo asi dosáhnout užitím generik, pokud je použity jazyk umí - pak by byla třída Record<T> kde T je typ dat, které ten záznam obsahuje. Třída Record by pak obsahovala fieldy, která jsou z principu přítomny vždy (id, čas vytvoření, modifikace, přístupová práva apod.) a obslužné metody.

Pokud to bude součástí nějakého webového API a ten objekt bude lítat z klienta na server a zpět, bych udělal něco jako dvojici Request<T> Response<T>, kde T bude typ dat, které se budou přenášet (Feed, Comment atd.). V samotném Request a Response budou jen metody a fieldy, které mají smysl vždy (stavové kódy, chyby, verze protokolu a obslužné metody apod.), uživatelská data budou v tom typu.

Určitě je x dalších možností, jak to udělat...

927

Vývoj / Re:Jak v PHP vypsat všechny problémy na obrazovku bez úpravy php.ini na serveru?

« kdy: 20. 04. 2018, 08:35:56 »

Ahoj, potřebuji v jednom PHP projektu zobrazit výpis chyba na obrazovku. Vložil jsem do index.php na začátek souboru

Kód: [Vybrat]

error_reporting(E_ALL);
ini_set('display_errors', 'On');

přesto se všechny chyby nevypíšou. Neví někdo jak zobrazit úplně všechny problémy? Chyby, varování a já nevím co všechno? Díky.

Nepřepíše se to nastavení potom někde jinde na jiné hodnoty? Taky se dá nastavit error handler - fce set_error_handler.

928

Vývoj / Re:Java: Mám neprázdný Set, ale nemůžu z něj dostat položky

« kdy: 16. 04. 2018, 13:57:28 »

Precetl jsem si jen prvni stranku. A reagoval. Dal jsem to i do statement.

Samozřejmě vím, že jste to uvedl. A já se zeptal, co tím příspěvkem vlastně myslíte, když to je už vyřešené.

Uzavřeme to: Synchronizoval jsem přes špatný zámek, protože jsem mylně předpokládal tvrdý singleton. Tím vznikla race condition v kokurenčním multi-threaded prostředí a ta mě vypekla. Po změně zámku to funguje. V diskuzi dále zazněly další doporučení, jak aplikaci pro dané použití lépe strukturovat a byla doporučena literatura. To je ta část diskuze, která pro mě měla smysl.

Tu knizku ti muzu poslat. Bude to i s postovnym asi $28. Dej vedet.

Děkuju, vystačím s tím co mám.

929

Vývoj / Re:Java: Mám neprázdný Set, ale nemůžu z něj dostat položky

« kdy: 15. 04. 2018, 11:14:05 »

Ale špatná synchronizace přístupu při změně té fronty by neměla vést k trvalé nepoužitelnosti té fronty, ne? Takže jeden problém je, zda je synchronizace v pořádku a druhý problém je, jakto že se ta fronta dostane do nevalidního stavu (není prázdná ale nemůžu dostat její prvky a to ani při pozastavených vláknech jvm).

Tomu se rika race condition. Brian Goetz napsal skvelou knizku https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601. Je ted ve sleve za $15. Stalo by zato si ji precist nez delat zavery, ze kdyz neco modifikuju pres nekolik threadu bez synchronizace, tak to nemuzu rozbit. Proto jsem psal, ze si hrajes na Doug Lea

Aha, dobře, díky za vysvětlení příspěvku. Problém nebyla absence synchronizace, ale špatná synchronizace (přes špatný objekt). Závěry jsem nedělal, ptal jsem se a odpověď jsem dostal již na cca druhé stránce této diskuze, totiž že se rozjede počítadlo se skutečným počtem prvků.

Na jiny masine to muze vypadat jinak. Proto je to race condition. A je jedno jestli to je absenci synchronizace nebo spatny synchronizaci.

Rozdíl je v tom, že v druhém případě je jasné, že si od začátku uvědomuju nutnost synchronizace akorát jsem ji (pod dojmem toho nepravého singelotnu) špatně provedl. A reaguju tím na vaše doporučení, abych to udělal thread-safe, což už je v diskuzi dávno zmíněno - poprvé v mém původním dotazu a posléze potvrzeno ostatními. Mimo jiné právě proto jsem nerozuměl, co svým příspěvkem vlastně chcete říct, přišlo mi to jako takový výstřel do tmy 

930

Vývoj / Re:Java: Mám neprázdný Set, ale nemůžu z něj dostat položky

« kdy: 14. 04. 2018, 19:36:55 »

Jenom doplnění - k modifikacím Image nedochází přímo u prvků té kolekce, může k nim dojít jen v jiných instancích stejné entity jinde v kódu (tj. jiná proměnná, jiné místo v paměti, stejné UUID entity a stejný záznam v databázi). V kolekci pak zůstane neaktuální verze entity (u entit se používá eager loading). Neaktuální verze v kolekci ale ničemu nevadí, protože za chvíli bude aplikací použita a z kolekce odstraněna (tak funguje daná aplikační logika). Později se již do kolekce načte čerstvá verze. V tomto schématu by tedy podle mě mohlo dojít v nejhorším k tomu, že by v kolekci byla stejná entita 2x (pokud by se modifikací změnila identita, k čemuž ale v použitím frameworku nedojde). Takže synchronizovat tento druh modifikace není potřeba.

To je fakt tak těžké si obalit kolekci proxy vrstvou, která synchronizovaně zajistí všechny potřebné služby Image a nepřipustí přímou manipulaci s kolekcí?

Ne, ale proč to dělat? V daném případě to je úplně zbytečné. Taky se neptám, proč jedeš autobusem a ne vlakem, když „jet vlakem snad není tak těžké“. Jinými slovy, problém jsem opravil adekvátně k významu a rozsahu té aplikace a její funkčnosti. Tímto debatu končím a samozřejmě děkuju za příspěvky (jsem zvědavý na kolik stránek tu debatu ještě natáhnete, ale za mě to je uzavřené).