Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ladislav Jech

Stran: 1 ... 10 11 [12]
166
Server / Re:Rozdíl mezi MariaDB a MySQL
« kdy: 06. 10. 2017, 21:04:46 »
Celkove bych casem taky videl rad v PostgreSQL AI pro real-time automatickou optimalizaci databaze podobne, jako to ted uvedl Oracle. Mozna se do toho pustim sam :-), ale mam ted jiny AI tasky na stole...

Trochu se poslednich par prispevku zvrhlo v PostgreSQL diskuzi, ale tak nevadi, jak jsem rekl, neresil bych mariaDB nebo MySQL a presel rovnou na PG :-)

Me na PG velmi potesila dalsi vec a to jsou extensions, dostal jsem se uz do situace, kdy jsem potreboval loadovat do databaze opravdu velke mnozstvi timeseries dat (miliardy zaznamu), nebo resit grafy a proto zde mame aha moment:
https://pgxn.org/

Za me hlavne tri, ktere jsem aktivne nasadil/aktualne testuju:
Horizontalni skalovani dat s multi-tenant modelem (resil Oracle 12c) - citus extension
https://github.com/citusdata/citus

TimeseriesDB - time series data hammer, ale neni zatim kompatibilni s Citus extensions, uvidime casem :-)
https://github.com/timescale/timescaledb

Aegens - transakcni grafova databaze
https://github.com/bitnine-oss/agensgraph

To jen na okraj takove zajimavosti, ale tech extensions je cela rada a z uz tak swiss knife jakym Postgre je, udelaji bestii :-))


167
Server / Re:Rozdíl mezi MariaDB a MySQL
« kdy: 04. 10. 2017, 21:20:00 »
Zkusim na tvoji otazku kouknout z opacne strany. Co maji MariaDB a MySQL spolecneho?
Obe by mely byt co nejdrive vymeneny za PostgreSQL a jejich vyvojari by meli emergovat do PostgreSQL take.

No a tvoji puvodni otazku uz nemusis resit, prestala existovat :-))))

168
Studium a uplatnění / Re:Návrat do ČR
« kdy: 03. 10. 2017, 01:56:28 »
Brno je hodne rozjety, ale tak jezdim tam jen namatkove a hlavne na pivo, ale vzdycky se v hospode potkam s nejakou partickou, a co nahodou dela "cool" projekty(ML included), je tam kupa uz zavedenejch startupu/firem, co se venujou ML pro vyuziti ve vsech moznejch oblastech...

Ja preferuju pokud mozno pracovat z domova na zahrade nebo z plaze, chodit/dojizdet do velkyho mesta kazdej den autem, nebo sockou jak jesterka uz me prestalo bavit... mam ted na mysli, ze ten traffic v praze nebo brne je proste smrtelnej...

169
Studium a uplatnění / Re:Rychlý přechod z Win na Linux
« kdy: 03. 10. 2017, 01:44:23 »
Uz mam za sebou ruzny learning curves od stredni skoly (94), pocinaje slackware/mandriva, ale stejne jsem porad lezl na widle (hry a grafika) a dlouho jsem se snazil widle tunit pres nlite napr. vytvaret si custom images (vyrezany sluzby, ktery vubec nepotrebuju, apod.), ale driv nebo pozdejc ten system narost a zacal padat stejne, delal jsem si i images s cistym systemem jen applikace, ktere chci pro rychlou obnovu, ale uz me to sralo...

Pozdeji Ubuntu pro me jasna volba, ale sralo me, ze jsem i bez command line, jenom nejaky GUI utilitky dokazal ten system shodit (asi ne chyba systemu) a rychlejsi byl reinstall, nez zjistovani, co je v zadeki, to jsem byl porad na takovy pul cesty k Linuxu.

Nakonec jsem se na to vysral a prosel porodem ke Gentoo linuxu, to znamenalo, ze jsem se naucil vicemene celej system na urovni vetsiho detailu, no dneska mam Gentoo vsude a widle jen pres Qemu(ani uz dual boot) a PCI passtrough, takze mam GPU akceleraci taky, ale vlastne uz pouzivam jen vyjimecne. Gentoo mam na rapsberry, laptopu, stanici i vsech serverech. Pokud vadi kompilace temer vseho (zakladni dekstop je dnes skompilovanej celkem rychle), tak bych sahnul po Archu.

Dokumentace Gentoo uz je dnes na takove urovni, ze pokud ti jde o to nainstalovat cistej KDE desktop, tak zvladne i uplny novacek. Okej, instalace zabere asi cely den/vikend ze zacatku. Nastudovad specifika portage (balickovaciho systemu) a jedem.

PS: Uznavam, ze jsou rychlejsi moznosti prechodu nez Gentoo nebo Arch, ale pokud planujes prechod trvale, tak za sebe doporucuju. Pro fast install and use asi Ubuntu no.

170
Desktop / Re:GNOME Shell v Gentoo
« kdy: 03. 12. 2013, 21:49:00 »
Ja to jdu dneska vyzkouset.

171
Server / Re:Proč je Java špatná na server?
« kdy: 25. 11. 2013, 10:56:38 »
no, ja si zkusim ve virtualu ten Jnode schvalne a zkusim load java aplikaci v nem.

172
Server / Re:Proč je Java špatná na server?
« kdy: 24. 11. 2013, 09:20:28 »
Zkusim to dnes jeste s hutnejsi aplikaci z pohledu velikosti classpath, tam ocekavam realny "brutalni" narust.

173
Server / Re:Proč je Java špatná na server?
« kdy: 24. 11. 2013, 02:09:48 »
A super, java embedded, na tu jsem uplne zapomnel, very good point!!!

No ja jsem si udelal nejaka srovnani ohledne volani napr nejakeho unix commandu, jeho reimplementace v jave volanim jak z on demand JVM, tak nacachovane JVM s temito vysledky:

Soubor 280MB
Java implementace pouziti unix4j:
Kód: [Vybrat]
/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */
package testingunixutilsjava;

import java.io.File;
import org.unix4j.Unix4j;

/**
 *
 * @author zANGETSu
 */
public class TestingUnixUtilsJava {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        Unix4j.cat("/home/zangetsu/test.txt").grep("TecMint.com").sort().toStdOut();

    }

}


Linux util
Kód: [Vybrat]
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#time cat test.txt | grep "TecMint.com" | sort
real 0m11.798s
user 0m0.128s
sys 0m1.084s

Standard JVM
Kód: [Vybrat]
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#time java -jar TestingUnixUtilsJava/dist/TestingUnixUtilsJava.jar
real 0m18.507s
user 0m8.161s
sys 0m0.208s

Drip
Kód: [Vybrat]
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#/root/bin/drip -cp TestingUnixUtilsJava.jar testingunixutilsjava.TestingUnixUtilsJava
real 0m18.395s
user 0m0.016s
sys 0m0.044s

Jak vidno, tak to spise vypada, ze bude problem ve vlastni implementaci utilit. Jednoduse javova implementace cat, grep a sort dohromady v tomto pripade v jave neni tak vykonna jako original, coz jsem cekal. No zmensim proto soubor na nula cela nula nic, takze uvidim vysledek vlastniho startu:

Linux util
real   0m0.051s
user   0m0.000s
sys   0m0.004s

opakovane:
real   0m0.003s
user   0m0.000s
sys   0m0.000s

Standard JVM:
real   0m0.371s
user   0m0.244s
sys   0m0.088s

opakovane:
real   0m0.382s
user   0m0.272s
sys   0m0.072s

Drip
Zde provedu test na bezici procesy, jelikoz se drip pri prvnich testech urcite demonizoval:
Kód: [Vybrat]
ps -ef |grep drip
root      9031     1  0 18:42 pts/1    00:00:00 /root/drip/bin/drip_daemon /usr/bin/java -Djava.awt.headless=true -classpath /root/drip/bin/../drip.jar:TestingUnixUtilsJava.jar org.flatland.drip.Main testingunixutilsjava.TestingUnixUtilsJava /root/.drip/0.2.3/ebd029dbc177dca5f783f1de6842f7d8edfadfa4/9011-1
root      9034  9031  0 18:42 ?        00:00:00 /usr/bin/java -Djava.awt.headless=true -classpath /root/drip/bin/../drip.jar:TestingUnixUtilsJava.jar org.flatland.drip.Main testingunixutilsjava.TestingUnixUtilsJava /root/.drip/0.2.3/ebd029dbc177dca5f783f1de6842f7d8edfadfa4/9011-1
root      9175  3732  0 18:45 pts/1    00:00:00 grep drip
# kill -n 9 9031 9034

Nyni predpokladam, ze start pres drip bude dokonce mozna o trochu horsi nez standardni JVM, jelikoz je tam nejaky svinstvo okolo, musi se vytvorit znovu deamon apod. Uvidim:
real   0m0.475s
user   0m0.260s
sys   0m0.080s

a opakovane:
real   0m0.463s
user   0m0.008s
sys   0m0.008s

real   0m0.470s
user   0m0.004s
sys   0m0.012s

No je videt, ze exekuce na urovni kernelu i mimo-kernel trvala opravdu velmi male casove okamziky. Co uz tu neni videt a proto cislo real zustava stale vysoke, je exekuce na urovni jineho procesu, kde je rozjeta JVM z minuleho runu. Rekl bych, ze jsem nezvolil nejlepsi priklad. Umim si predstavit, ze zde k vyraznemu narustu vykonu dojde az napr. pokud pouzivame velky set classpath. Takhle se to rozhodne nevyplati.

Jinak exekuce probihala na virtualnim debianu.

174
Server / Re:Proč je Java špatná na server?
« kdy: 24. 11. 2013, 00:01:35 »
Dneska už se používá idiotský návrh aplikací, kdy programátor naprosto nechápe co dělá a bohužel nejčastěji jsou to progamátoři vyšších jazyků (Java například).

souhlas. Stejne je zajimave, ze vznikne neco plne funkcniho, ackoli stvoritel naprosto nechapal, co dela :-) Treba to takhle bylo i s nasim svetem a bohem, ale to je asi do diskuze na cirkev.cz haha

Jazyk samotný s tím, ale nemá co dělat.

nesouhlas. vsechno souvisi se vsim.

Další zádrhel je používání frameworků - dost často patlá taky někdo kdo může nadělat strašný chyby a vaše aplikace za to chudák ani nemůže.

tak tohle je pro me nejvetsi problem! Vybavil jsi mi dobu, kdyz jsem jeste vyvijel ve Skodovce linku montaze na plc gefanucu. Linka trpela velkym mnozstvim jednoduse opravitelnych zavad, ktere postupnymi opravami mizely, nicmene se zacaly rodit potomci binarniho sexu okurence starych chyb a jejich osetreni. Byly to chyby, ktere nastavaly daleko mene casteji, ale bylo potreba daleko vice casu pro jejich napravu. Tento stav se stale prohluboval se stabilizaci (subjektivni) systemu v case. No jestlize tento efekt spojim jeste s vrstvenim, tak je to rodiste opravdu zajimavych stavu  ;D :P

175
Server / Re:Proč je Java špatná na server?
« kdy: 23. 11. 2013, 23:27:23 »
Co ctu, tak se tu dost kritizuje doba startu JVM. Osobne jsem nezkusil, ale projekt Nailgun vypada hodne nadejne:
Kód: [Vybrat]
$ time java com.martiansoftware.nailgun.examples.HelloWorld Hello, world!

real 0m0.132s
user 0m0.080s
sys 0m0.010s

$ time ./ng com.martiansoftware.nailgun.examples.HelloWorld Hello, world!

real 0m0.004s
user 0m0.000s
sys 0m0.000s

Tak to je ale duvod, proc jsou na serveru shell skripty a ne Java. IDE na serveru nemas a pri kazde uprave stahovat a editovat jinde, a posilat zpet, se rychle zaji.
Neznam podrobnosti, ale cetl jsem, ze napr. pomoci Eclim-u lze udelat z Vimu celkem schopne IDE pro Javu (nejaka ukazka je i na youtube - tu).

Diky za toto, je to hezky vyprasene svinsto, mrknu na to, good tip!

Zaznely tu nejake nazory typu to je strasne, kdyz pamet leze nahoru, z procesoru se kouri apod. S tim jsem se se taky setkal. Osobne musim rict, ze na svoji vyvojovy masine mi 8GB taky nestaci no(2 instance weblogicu admin a managed server Oracle SOA, oracle xe, sql developer, firefox(ten zere taky jak svin), jdeveloper, soapui, pripadne loadui, par word, excel dokumentu a je to v pici...ale 16GB mi v teto dobe dostacuje a vse mam svizne, muzu rict, ze proste na gentoo je start vseho rychlejsi, ale nesrovnavame tady L vs W.

Zpatky ale k puvodnimu nametu, proc nepsat systemove aplikace pro linux v jave? Netusim, vlastne je to docela dobry napad ;-). Chapu, ze nejhorsi je tady zrejme problem se startem prikazu, v tom pripade jsou tady stale nativni kompilatory pro javu.
GCJ http://gcc.gnu.org/java/ uz se asi nerozjede, ale stale podpodporuje verzi javy, ve ktere lze drtivou vetsinu stavajiciho setu unix tools prepsat(doufam, ze se nepletu haha).
Nasledne existuji i komercni nativni kompilatory, na kterych se aktivne pracuje:
Excelsior JET http://www.excelsior-usa.com/jet.html
Dalsi treba JNC ale ten je taky uz v kelu http://jnc.mtsystems.ch/download.html

Nicmene tim bychom dostali tooly napsane v Jave a zkompilovane do nativniho kodu, coz je samo o sobe prece hezke, napsal jsem si kod a muzu se rozhodnout, jestli ho necham spoustet ve virtualnim prostredi nebo v nativnim rezimu.

Pred chvili zde zmineny nailgun se mi opravdu libi nicmene muze trpet tim, ze ta masina se casem opravdu zasvini a command LS se pres implementaci C posle na server(ten bezi lokalne haha, ale bude zajebany, takze to skonci exception, nebo timeout). To jen tak ciste hypoteticky. Tento neduh se snazi resit dalsi projekt vedle nailgun jmenem DIRT https://github.com/flatland/drip
Prave DIRTu bych sveril systemove commandy pokud bych chtel start "podobny" nativnimu bloku.

No a kdyz uz se bavime primarne o nixove tooly, pak to take neni nova myslenka a zakladni set hlavne textovych util je implementovan v projektu unix4j at http://code.google.com/p/unix4j/

Ladik

Stran: 1 ... 10 11 [12]