LINUXSOFT.cz Přeskoč levou lištu

ARCHIV



   

> Diskuze: článek Příprava našeho TPC-B testu databází

zajímavý článek
(link)
25.10.2010 20:44
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

díky

s tím JDBC driverem pro PostgreSQL je to ostuda, ale je to tak - projekt je postaven tak, že drivery nejsou jeho součástí - v rámci projektu je poskytován pouze jediný univerzální C driver. Nicméně komunita kolem Javy není schopná dát dohromady slušný driver. Což je paradoxní vzhledem třeba k .NET driveru, který je kvalitní, a je za tím jeden nadšenec a pár dalších.

Trochu mne napadá jestli to není tím, že za většinou o.s. projektů v Javě je IBM, a té se nechce financovat konkurenci - prostě v Javě o.s. bez IBM nefunguje.

Re: zajímavý článek
(link)
25.10.2010 21:01
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Ještě přidám jeden dotaz - na IRC jsem zkusil popohnat dění ohledně JDBC (těch problémů je víc - např. chybí podpora statement timeoutu) - bylo mi řečeno, že prepared statements jsou podporovány - a že je někdo používá ve své aplikaci. Jak je to tedy? Tohle je něco, co jde absolutně mimo mne.

preparedStatementy
(link)
25.10.2010 21:25
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

preparedStatementy z hlediska Java aplikace podporovany jsou, ale jsou stejne jako kurzory jen emulovane. JDBC driver neprelozi PreparedStatement class z Javy do prepared statementu PGSQL serveru, ale proste ten SQL prikaz odesle znova jako text jen s jinymi parametry. Kdyz si zapnete monitoring SQL prikazu tak vidite jake JDBC driver posila databazi.
Kdyby se ovsem na tom jdbc driveru maklo tak v OLTP na malych tabulkach tak do 10GB by byl pgsql srovnatelny s komercni spickou. Mela by vyvoj zacvakat ne IBM ale enterpriseDB.

Re: preparedStatementy
(link)
25.10.2010 21:56
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Teď googluji a narazil jsem na connection parameter prepareThreshold, který se asi musí explicitně nastavit, pak podle všeho JDBC by měl použít server side prepared statementy.

Asi sám víte, jaký je teď přístup menších firem k financování externích projektů? Ještě tak před dvěma roky možná, ale teď to prostě není reálné. Navíc to vždy chce alespoň jednoho člověka, který by to vzal na sebe - udělal masivní část, a pak by jej možná EDB zaměstnala - nebo další podobné firmy. Bez někoho takového to prostě nemá cenu - a kvalitní programátoři v Javě buďto nevědí kam skočit nebo se snaží vydělat si na důchod a ostatní to prostě neprorazí.

Re: preparedStatementy
(link)
26.10.2010 00:33
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

Default hodnota je 5. Mne to ale stejne vzdy posila inserty misto execute, asi zalezi jeste na necem. Shrnuti je ze mi to out of box nefunguje.

EDB maji ledatak velkou hubu, jdbc driver jsem jim reklamoval a nic pro zlepseni neudelali "NENI TO NAS PRODUKT". Vyzkousel jsem taky ty jejich utility a rozhodne bych za to ty penize nedal. Realita ovsem je, ze staci aby tomu veril manager, protoze ten rozhoduje co se koupi.

Krize dopadla na vsechny. Tohle zari IBM zlevnila DB2, nejlevnejsi edice stoji se 24x7 supportem $1.5k rocne. Vynikajici cena, to uz vyjde levneji nez opensource databaze. Taky udelali novou edici DB2 AESE http://www-01.ibm.com/software/data/db2/linux-unix-windows/edition-advanced-enterprise-features.html kde davaji ty rozsireni co driv prodavali za hezke penize prakticky zdarma.

Taky je dobry tenhle report, zajimave ze MySQL prekonalo PGSQL. To dela sila znacky.
http://www.microsoft.com/presspass/itanalyst/docs/06-30-09EnterpriseDatabaseManagementSystems.PDF

Re: preparedStatementy
(link)
26.10.2010 07:17
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Znáš ten vtip - že "tlustý budou hubený a hubený budou studený". IBM, Oracle, Microsoft mají z čeho dávat - zároveň si ale likvidují trh - po krizi se jim budou obtížně zvedat, udržovat marže. Nicméně pořád si myslím, že kvalitní JDBC driver pro PostgreSQL není otázka peněz, ale lidí. Je minimum lidí, kteří by rozuměli problematice, měli čas a ochotu něco s tím udělat. A vzhledem k tomu, že ten driver jakž takž funguje, tak je ochota ještě nižší.

Tu analýzu od Forresterů jsem viděl cca před rokem, kdy se řešila. Osobně si myslím, že některé položky ujely: data types and data integrity - MySQL: 2.81, PostgreSQL: 2.13. Diskutovalo se to v konferenci - PostgreSQL doplatilo a) možná na JDBC, možná na implementaci úrovně SERIALIZABLE - testovací aplikace, které Forrester používá s pg údajně nedoběhne. b) modulární strukturu - forrester hodnotí krabici, což pro pg není a nebude výhodné - gro je v externích modulech. Příští rok by v pg měl být upravená úroveň SERIALIZABLE, tak aby skutečně nedocházelo ke konfliktům - což bude znamenat aktivnější zamykání :(, replikace již pg interně obsahuje, tak by se v hodnocení měla posunout výše.

Na IRC jsem probíral JDBC. Někteří lidé se tvářili docela překvapeně - vždyť JDBC je úplně v pořádku. Chybí use-case, chybí reálné bug reporty, podle jejich feedbacku od vývojářů je JDBC něco, co není třeba řešit. Zatím to vypadá tak, že pokud se JDBC používá přímo, tak k zásadním problémům nedochází, problémy nastávají s použitím ORM. Můžeš mi, prosím, poslat sumář s čím máš problémy, pokud možno konkrétní problémy.

data integrity
(link)
26.10.2010 15:24
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

S tim data integrity maji pravdu v serializable neprojde TPCB test na isolaci transakci, muzete si to zkusit, odkomentujte

System.out.println("Isolation test "+ t.isolationTests(null));

Takze podle oficialnich pravidel bychom nemohli pgsql v tpcb testovat vubec, on ale i v read commited vraci konzistentni vysledky, coz je ale dano tim ze UPDATE umi vracet hodnotu.

Re: preparedStatementy
(link)
26.10.2010 07:30
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov
<i>Default hodnota je 5. Mne to ale stejne vzdy posila inserty misto execute, asi zalezi jeste na necem. Shrnuti je ze mi to out of box nefunguje.</i>
Co jsem vygooglil, tak při defaultu 5 JDBC 5x vytvoří client-side PP a tudíž v logu se minimálně 5x musí objevit standardní SQL, teprve při šestém pokusu se vytvoří server side PP, a pak další volání by již mělo být volání PP.
Re: preparedStatementy
(link)
26.10.2010 11:52
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

Stahnete si Eclipse, naimportujte do nej ten testovaci soft tpc-b z lauchpadu, stisknete run a podivejte se co z toho za prikazy leze.

Re: preparedStatementy
(link)
26.10.2010 13:39
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Když jsem do connection stringu přidal ?prepareThreshold=1, tak se skutečně začaly používat server side prepared statementy - lze to poznat z logu - nastavenéím log_min_duration_statement = 0.

prepareThreshold=1
(link)
26.10.2010 15:19
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

Mate pravdu s
d = new driver();
d.setJDBCURL("jdbc:postgresql:postgres?prepareThreshold=1");

je to opravdu uz v poradku co se tyce server side prepared statementu, znova jsem to prekontroloval cele rucne v logu. Ten monitorovaci tool co jsem pouzival predtim to totiz ukazoval spatne. Takze server side prepared statementy muzeme ze seznamu nedostatku smazat jako funkcni.

Jen je to porad pomaly. 1m radku to vklada 2 - 2,5minuty podle toho jak tam prekazi vacuum. Oracle to ma za 23 sekund, DB2 okolo triceti. Oracle desitka ma vubec hodne rychly inserty, pokud nema tabulka index tak jsou dokonce az 4x rychlejsi nez v DB2 9.5. DB2 ma ale zase vyrazne rychlejsi UPDATE a DELETE. Oracle 11r1 ma ale inserty abnormalne pomale, jedenactka se moc nepovedla.

Re: prepareThreshold=1
(link)
26.10.2010 19:15
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Napadá mne několik možností a) autocommit - ale to by bylo možná ještě pomalejší, b) používáte defaultní konfiguraci? ta vůbec není nastavená na intenzivní zápis a z hlediska paměti je hodně podstřelená - pro soudobé počítače - např. maintenance_work_mem je dobré nastavit na 10násobek def, wal_buffers na 1MB, checkpoint segments alespoň na 20. Tady je pg v nevýhodě - defaultní konfigurace je taková, že si pg vezme něco kolem max. 40 MB paměti - a to se projeví samozřejmě v rychlosti i zápisu. Zajímalo by mne, jestli by se Vám rozjel Oracle s 28MB SGA.

Jinak pro intenzivní import by postgresisti použili spíš COPY než INSERT (bulk load pro komerční databáze), které je ještě cca 10x rychlejší. Navíc pg nemá nijak zvlášť optimalizovanou kontrolu referenční integrity při načítání hromadných dat - tam se musí zákonitě projevit sofistikovanější cache Oraclu nebo DB2.

Re: prepareThreshold=1
(link)
27.10.2010 13:43
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

mam:
shared_buffers=1000MB
maintenance_work_mem = 100MB
checkpoint_segments = 25
wal_buffers = 10MB

takze by mela byt konfigurace ok.

Oracle 10 potrebuje neco pres 70MB SGA aby vubec nastartoval. DB2 ma paradoxne default buffer 4MB a 0MB read ahead buffer a kupodivu dosahuje i s nim velmi dobrych vysledku pokud dela full tablescany nebo inserty do tabulky bez indexu. Oracle ten neumi pri malych velikostech RAM prakticky vubec pracovat, minimalni rozumna SGA je 200MB jinak je to priserne pomaly.

Direct loady jsem netestil to ani nemelo cenu tam by vyhrala DB2 co zvlada miliony radek/sec. Musi ovsem pred tim nez zacne loadovat data zasyncovat buffer cache, coz trva u busy serveru desitky sekund, nekdy to neprojde vubec protoze tam aplikace porad cpou nova data.

Re: prepareThreshold=1
(link)
27.10.2010 14:26
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Tak pak asi to co jsi dostal z pg je maximum. Možná bych zkusil ještě 9 nebo alespoň 8.4 - rychlost zápisu by měla být minimálně stejná, ale měla by se o dost snížit režie spojená s VACUUM.

p.s. Ještě mne napadl docela zajímavý experiment - vzhledem k tomu, že tvoje aplikace je TPC-B v Javě a pgBench je TPC-B napsaný v C, dalo by se docela snadno zjistit jaká je režie prostředí Javy. Jelikož se nevyznám v tvé aplikaci a zrovna tak v metodice TPC-B - a vstával jsem v pět hodin ráno, takže mi to nějak nemyslí, tak se do podobného srovnání pouštět nebudu - dávám to tu jen jako námět. Zkoušel jsem porovnat čas vytvoření databáze - pgbench je cca 3x rychlejší než tvoje aplikace - patrně rozdíl je jedině v indexování - pg_bench vytváří indexy až po importu a je to relativně pomalá záležitost - takže to asi bude hrdlo v pg - aktualizace indexu.

Re: prepareThreshold=1
(link)
28.10.2010 16:01
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

pgbench nebezi s tabulkama vyvorenyma mojim programem. Musel bych si nainstalovat do widli C prekladac coz se mi nechce.

Re: prepareThreshold=1
(link)
28.10.2010 16:21
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

pgbench by měl být normálně v instalaci, když už instalátor od edb obsahuje i PostGIS, tak by měl obsahovat i pgbench. Je to tam, kde se v instalaci nastavují rozšiřující moduly.

Re: prepareThreshold=1
(link)
28.10.2010 19:14
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

pgbench tam je, jen vyzaduje jine databazove schema. potreboval by proto poeditovat a ja nemam na widlich c kompilator ponevadz delam v Jave.

Re: prepareThreshold=1
(link)
27.10.2010 11:44
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Zkontroloval jsem log, autocommit je vypnutý - problém je v defaultní konfiguraci. V def. jsem měl čas pro generování 10M řádků (cca G db) kolem 34 min. Po nastavení "checkpoint_segments=30, wall_buffers=1924kb, maintenance_work_mem=160MB jsem se dostal na čas 12 min - cca 1/3 - takže by to u Vás vycházelo kolem 50 sec - možná 40. Hrdlem by měl být určitě zápis na disk - což si myslím, že může být čas Oracle. Je otázkou kolik z těch zbývajících 30 sec padne na vrub JDBC?

Re: prepareThreshold=1
(link)
28.10.2010 16:03
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

nevim jak se zjisti ve windows kolik sekund CPU casu spotrebovala data aplikace, to jest ekvivalent unixoveho prikazu time.

Re: prepareThreshold=1
(link)
28.10.2010 16:17
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

To já nevím také - ty to testuješ ve win? Windows mají speciální požadavky - někde jsem četl, že se doporučuje mít shared_buffers co nejmenší - a víc bohužel nevím - tady moc lidí není, kteří by věděli, co potřebuje pg na win.

Re: prepareThreshold=1
(link)
28.10.2010 19:14
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

Ano, testuji to na win32

Re: prepareThreshold=1
(link)
28.10.2010 20:10
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Na Win32 je pg maximálně znevýhodněn - samozřejmě, v nevýhodě jsou všechny db, ale vzhledem k architektuře, která nepoužívá vlákna - a v defaultu ani pooling conexí (i když o to se stará možná JDBC) je to asi nejznatelnější - trojková řada je navíc snad ještě kompilovaná (sice už nativně) cygwinem - další už jsou překládané v Visual C++. Hlavně je pg ve verzi 8.3 teprve třetím rokem pro win32 - zrovna u win se asi nejvic reviduje, záplatuje, optimalizuje - je to nejmladší z podporovaných platforem. Docela by bylo zajímavé udělat graf např. pgbenche mezi 8.0 až 9.0.

Re: prepareThreshold=1
(link)
30.10.2010 14:11
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

Doba zakladani db spojeni je irelevantni pro vyse uvedeny test, protoze se po kazde transakci neodpojujeme od db.

Malá kritika
(link)
26.10.2010 22:29
Karel Benák

Článek opět na vysoké úrovni, ale drobná výtka týkající se části s dokumentací k Oracle. V ní to totiž vypadá na velmi neumělý automatický překlad. Min. dvě věty v této části prostě nedávají smysl a chtěly by přeformulovat. Takže 8/10 ;-)

Re: Malá kritika
(link)
27.10.2010 11:43
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

Mne se ta cast taky nezdala, ale nenasel jsem zpusob jak to opravit s vynalozenim male namahy tak jsem to tam nechal s oduvodnenim ze Oracle dokumentace by si lepsi praci stejne nezaslouzila.

Kurzory v pgSQL
(link)
27.10.2010 20:03
Aleš Hakl
Bydliště: Praha

Ono to s temi kurzory v pgSQL vubec neni tak jednoduche. Ten PQ protokol ma pomerne netypickou (dle meho nazoru vlastne dobrou) vlastnost, ze vysledky dotazu predava naraz jako jeden velky paket. Tudiz mi prijde, ze emulovat ResultSet/Cursor na klientske strane je vlastne zadouci chovani, protoze se to pak chova vicemene stejne jako libPQ. Treba driver pro pythonove DBAPI (minimalne ten nejpouzivanejsi, jsou asi 3) ma tu vlastnost, ze pro kazdy kurzor opravdu vytvari portaly a pouziva je, coz mi prijde ve vetsine pripadu jako zbytecne plytvani casem. Je otazkou jak to rozumne resit, podle me by to melo byt nejak konfigurovatelne, idealne per-dotaz, nicmene do tech API obvykle neni kam takovou volbu nacpat.

Re: Kurzory v pgSQL
(link)
27.10.2010 20:28
Pavel Stěhule
Věk: ( ~51 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Myslím si, že kurzory určitě mají svoje místo - zvlášť, když zpracováváš větší data z klientů, kteří mohou mít problémy s pamětí - PHP, Java, ... Navíc dochzází k určitému souběhu - server může začít posílat data relativně brzo, klient se rychle dostane k výsledku - na druhou stranu, klient může brzdit server, zvyšuje se i síťová komunikace. Kdyby klient si bral data ze severu řádek po řádku, tak by to bylo skutečně neefektivní a také se to nedělá - obyčejně se zavolá FETCH s parametrem 100 nebo 1000. Další výhoda kurzoru může být relativně rychlé a bezbolestné ukončení provádění dotazu - v okamžiku, kdy najdeš data, která tě zajímají, tak můžeš skončit - to se někdy nedá udělat jinak než skrz kurzor.

Re: Kurzory v pgSQL
(link)
27.10.2010 21:09
Aleš Hakl
Bydliště: Praha

Ja netvrdim, ze nemaji vyhody. Ja tvrdim, ze je lepsi, kdyz se defaultne driver chova stejne jako libPQ, jednak kvuli konzistentnosti a jednak s ohledem na to, ze pro 90% aplikaci (treba asi cokoli weboveho) ma to chovani smysl.

Fakt je, ze je to cele o tom, ze to API co prezentuje JDBC/DBAPI/temer cokoli objektoveho ma tu vlastnost, ze tenhle rozdil v nem neni rozumne postihnuty (uz jenom proto, ze postgres je asi jedina databaze, kde existuje).

Re: Kurzory v pgSQL
(link)
28.10.2010 18:03
Radim Kolář
Věk: ( ~51 let) , Bydliště: Louny

v JDBC je mozne rici kolik vysledku ma nacist na jeden zatah do pameti, jen to JDBC driver pgsql neumi.

DISKUZE

zajímavý článek 25.10.2010 20:44 Pavel Stěhule
L Re: zajímavý článek 25.10.2010 21:01 Pavel Stěhule
  L preparedStatementy 25.10.2010 21:25 Radim Kolář
    L Re: preparedStatementy 25.10.2010 21:56 Pavel Stěhule
      L Re: preparedStatementy 26.10.2010 00:33 Radim Kolář
        |- Re: preparedStatementy 26.10.2010 07:17 Pavel Stěhule
        | L data integrity 26.10.2010 15:24 Radim Kolář
        L Re: preparedStatementy 26.10.2010 07:30 Pavel Stěhule
          L Re: preparedStatementy 26.10.2010 11:52 Radim Kolář
            L Re: preparedStatementy 26.10.2010 13:39 Pavel Stěhule
              L prepareThreshold=1 26.10.2010 15:19 Radim Kolář
                |- Re: prepareThreshold=1 26.10.2010 19:15 Pavel Stěhule
                | L Re: prepareThreshold=1 27.10.2010 13:43 Radim Kolář
                |   L Re: prepareThreshold=1 27.10.2010 14:26 Pavel Stěhule
                |     L Re: prepareThreshold=1 28.10.2010 16:01 Radim Kolář
                |       L Re: prepareThreshold=1 28.10.2010 16:21 Pavel Stěhule
                |         L Re: prepareThreshold=1 28.10.2010 19:14 Radim Kolář
                L Re: prepareThreshold=1 27.10.2010 11:44 Pavel Stěhule
                  L Re: prepareThreshold=1 28.10.2010 16:03 Radim Kolář
                    L Re: prepareThreshold=1 28.10.2010 16:17 Pavel Stěhule
                      L Re: prepareThreshold=1 28.10.2010 19:14 Radim Kolář
                        L Re: prepareThreshold=1 28.10.2010 20:10 Pavel Stěhule
                          L Re: prepareThreshold=1 30.10.2010 14:11 Radim Kolář
Malá kritika 26.10.2010 22:29 Karel Benák
L Re: Malá kritika 27.10.2010 11:43 Radim Kolář
Kurzory v pgSQL 27.10.2010 20:03 Aleš Hakl
  L Re: Kurzory v pgSQL 27.10.2010 20:28 Pavel Stěhule
    L Re: Kurzory v pgSQL 27.10.2010 21:09 Aleš Hakl
      L Re: Kurzory v pgSQL 28.10.2010 18:03 Radim Kolář




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

28.11.2018 23:56 /František Kučera
Prosincový sraz spolku OpenAlt se koná ve středu 5.12.2018 od 16:00 na adrese Zikova 1903/4, Praha 6. Tentokrát navštívíme organizaci CESNET. Na programu jsou dvě přednášky: Distribuované úložiště Ceph (Michal Strnad) a Plně šifrovaný disk na moderním systému (Ondřej Caletka). Následně se přesuneme do některé z nedalekých restaurací, kde budeme pokračovat v diskusi.
Komentářů: 1

12.11.2018 21:28 /Redakce Linuxsoft.cz
22. listopadu 2018 se koná v Praze na Karlově náměstí již pátý ročník konference s tématem Datová centra pro business, která nabídne odpovědi na aktuální a často řešené otázky: Jaké jsou aktuální trendy v oblasti datových center a jak je optimálně využít pro vlastní prospěch? Jak si zajistit odpovídající služby datových center? Podle jakých kritérií vybírat dodavatele služeb? Jak volit vhodné součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně datové centrum spravovat? Jak co nejlépe eliminovat možná rizika? apod. Příznivci LinuxSoftu mohou při registraci uplatnit kód LIN350, který jim přinese zvýhodněné vstupné s 50% slevou.
Přidat komentář

6.11.2018 2:04 /František Kučera
Říjnový pražský sraz spolku OpenAlt se koná v listopadu – již tento čtvrtek – 8. 11. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

4.10.2018 21:30 /Ondřej Čečák
LinuxDays 2018 již tento víkend, registrace je otevřená.
Přidat komentář

18.9.2018 23:30 /František Kučera
Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

9.9.2018 14:15 /Redakce Linuxsoft.cz
20.9.2018 proběhne v pražském Kongresovém centru Vavruška konference Mobilní řešení pro business. Návštěvníci si vyslechnou mimo jiné přednášky na témata: Nejdůležitější aktuální trendy v oblasti mobilních technologií, správa a zabezpečení mobilních zařízení ve firmách, jak mobilně přistupovat k informačnímu systému firmy, kdy se vyplatí používat odolná mobilní zařízení nebo jak zabezpečit mobilní komunikaci.
Přidat komentář

12.8.2018 16:58 /František Kučera
Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek – 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.
Přidat komentář

16.7.2018 1:05 /František Kučera
Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

31.7.2023 14:13 / Linda Graham
iPhone Services

30.11.2022 9:32 / Kyle McDermott
Hosting download unavailable

13.12.2018 10:57 / Jan Mareš
Re: zavináč

2.12.2018 23:56 / František Kučera
Sraz

5.10.2018 17:12 / Jakub Kuljovsky
Re: Jaký kurz a software by jste doporučili pro začínajcího kodéra?

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2024) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze