Esmska 0.10.0

Vyšla Esmska 0.10.0. Nově běží na Mac OS X Leopard (s Javou od Apple) a s OpenJDK 6. Opravuje problém s odesíláním zpráv přes t-zones delších než 1 SMS. Byla přidána kontextová nabídka do seznamu kontaktů a do fronty. Dále byl vylepšen import kontaktů, program má novou ikonu atd.

21.6.2008 18:02 | David Watzke | Nová verze

Komentáře

[Kamil Páral]

Novinky se šíří rychle :) Velké díky Marianu 'Algi' Boučkovi za integraci do Mac OS X a spoustu dalších věcí.

[David Watzke]

Mohl bys do příští verze přidat esmska.desktop? Stáhneš ho příkazem:

svn cat svn://svn.watzke.cz/dave/overlay/app-mobilephone/esmska/files/esmska.desktop > esmska.desktop

a patří do /usr/share/applications/. Poslal mi to teď GEDIK, tak jsem to hodil do overlaye.

[Kamil Páral]

No, nejsem si jistej, myslím že by to spíš u sebe měli držet packageři. Protože uživatelům stahující archiv je desktop soubor nanic (mohou tam být akorát absolutní cesty), a tvůrci balíčků mohou používat jiné cesty pro instalaci programu, to už je v jejich režii. Myslíš, že je vhodné, bych to přibaloval do výchozího archivu? Marek Palatinus dělající DEB balíky taky má svoji verzi desktop souboru u sebe. Ale nevím jak to chodí, nechám si poradit :)

[David Watzke]

Ne, máš pravdu, tohle jsem si neuvědomil.

[Kamil Páral]

Přidal jsem esmska.desktop do zdrojáků programu, tvůrci balíčků ho mohou využít, stejně jako další soubory. Viz trunk/esmska/resources

[stativ]

mohou tam být akorát absolutní cesty

A odkdy? Obvykle se naopak používají relativní cesty. Binárku pak hledá někde v PATH, ikonky hledá podle podle tohohle.

[Kamil Páral]

Ano, absolutní nebo v předem specifikovaných adresářích (což *není* relativní) a PATH. Takže to nejde využít pro uživatele stahující zip archiv, jen v systémových balíčkách.

[stativ]

Konečně mi docvaklo, jak to myslíte.

[Quimby]

Super, az tam bude balice pro OSX tak to urcite vyzkousim.. Diky za snahu

[Kamil Páral]

Bude snad ještě dnes.

[Algi]

http://ptakopysk.cz/algi/download/Esmska-0.10.0.dmg

[sssssssss]

Příloha:

• Picture 1.png (15320 bytů)

OS X 10.5.3 CoreDuo, obrázek je pokus o spuštění klikátkem a citace je zpráva při pokusu o spuštění .sh

Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass2(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:774) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:160) at java.net.URLClassLoader.defineClass(URLClassLoader.java:254) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:316) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)

[DjAARA]

Java 1.6 bytecode spuštěný v Java 1.5 runtime?

[sssssssss]

Jestli to je na mě, tak vůbec nevim o čem mluvíš Prostě když jsem na to kliknul tak se mi objevilo to okno. Verzi javy a podobný bejkárny mě nezajímaj, buď aplikace funguje a já jí používám, nebo jde do koše-jednoduchý a bezstarostný.

[bhy]

S tímto přístupem bych nikdy nepřešel z psacího stroje na PC.:)

[AsciiWolf]

+1

[sssssssss]

S tímto přístupem bych nikdy nepřešel z psacího stroje na PC.:)

Mam tokovej přístup, aproto používám jabko!

[bhy]

no já myslel PC jako komp co se vejde na stůl:) takže jabko je u mě taky PC. btw MacOS až do verzí 9.x prý nesnesitelně padal (víc než w98).

[Algi]

Pokud máš MacBook, který není 64-bitový, tak si Esmsku bohužel zatím nespustíš. Můžeš samozřejmě vyzkoušet SoyLatte. Je to implementace OpenJDK, avšak není od Apple. Krom toho, GUI aplikace se v ní spouštějí v X11 serveru :-/ No nic, jdu udělat ten balíček

[sssssssss]

Jo a ještě kvůli tomu instalovat X11... děkuji nechci.

[Algi]

No, X11 bys mel mit standardne nainstalovany v systemu. Ale tvuj odpor k X11 aplikacim chapu. Jenze kdyz mas 32-bitovy MacBook, tak prozatim neni jine volby. Vyzkousim to, jak moc slozite to je pod touto Javou rozbehnout a zda se vyplati SoyLatte zkouset. Pak dam vedet.

[sssssssss]

Kvůli mě se s tim ne---r, já tu aplikaci nepotřenuju, chtěl jsem to jen zkusit. A jinou javu si taky instalovat nebudu, vše mi běží, tak proč do toho rejpat...

[Algi]

No, pro ty co se nebojí Terminálu, tak je zde malý návod na použití SoyLatte na Mac OS X 10.4 a vyšší (pro Applem nepodporované platformy). Později dám do wiki:

1) Stáhnout Java 6 ze stránky Port of BSD Java
2) Rozbalit a nakopírovat do libovolného adresáře (třeba do Documents)
3) Stáhnout a rozbalit Esmsku (Esmska-0.10.0.zip)
4) Spustit Terminal (v /Application/Utilities)
5) napsat cd<mezera> a přetáhnout ikonku adresáře s rozbalenou Esmskou do Terminálu, pak zmáčknout Enter
6) přetáhnout rozbalený adresář Javy 6 do Terminálu, umazat mezeru a dopsat /bin/java -jar esmska.jar
7) zmáčknout Enter a modlit se

Aplikace se poté nastartuje v X11. Díky tomu bohužel bude mít menu uvnitř okna, což je sice nezvyklé, ale funkčnosti programu to nebrání.

[Ilfirin]

OpenSUSE 11.0, Java sun 1_6_0 x64
a moc mi to nefunguje :-/. Program byl až zběsile pomalý a některé věci odmítal vůbec udělat. Proto jsem si ho pustil v konzoli. No těch chyb. Další z důvodů, pro mě, bát se javy .

[David Watzke]

To je podivný, u mě na Gentoo 64-bit (se Sun JDK 1.6.0.06) je esmska pomalá jen když nastavím nějakej z těch fancy skinů, s výchozím je pomalá jako klasická Java app a jde v ní vše. Co mě spíš znepokojuje, je spotřeba paměti tak malýho prográmku, která je hned po spuštění 83.4 MB a po chvíli v trayi dost přes 100 MB.

[Kamil Páral]

No jo, v tom je i virtuální mašina Javy. Když budeš mít puštěných víc Javových aplikací, tak už požadavky na paměť budou růst mnohem pomaleji :)

[Algi]

No, pokud se díváš do sledovátka systému (např. top), tak 83.4 MB je paměť, kterou si Java od systému zažádala. Neznamená to automaticky, že jí skutečně využívá. Jestli chceš pozorovat detailně ty hrůzy, co se s pamětí v Esmsce dějí, pak si nainstaluj Java 6 SDK a spusť si program jconsole. To pak uvidíš teprve věci

[Luboš Doležel (Doli)]

No, pokud se díváš do sledovátka systému (např. top), tak 83.4 MB je paměť, kterou si Java od systému zažádala. Neznamená to automaticky, že jí skutečně využívá.

To už je ale prakticky jedno, že ji nevyužívá. Program s únikem paměti uniklou paměť taky nevyužívá, a přesto je to problém.

[Filip Jirsák]

To už je ale prakticky jedno, že ji nevyužívá. Program s únikem paměti uniklou paměť taky nevyužívá, a přesto je to problém.

Problém s úniky paměti je v tom, že ta zabraná paměť neustále roste, až přeroste všechno, co je k dispozici. Alokovaná ale nevyužitá paměť problém není, je to někde ve swapu a ostatním programům to nepřekáží.

[Luboš Doležel (Doli)]

Swap na stroje s RAM >=2 GB nedávám. Se slušnými programy není problém, neslušné raději nepoužívám.

[Algi]

Patrně nepoužívaš Oracle XE To bys totiž swap musel mít. Mě to při instalaci dokonce donutilo k tomu, abych jej rozšířil. Jenže tenkrát jsem byl lama a raději jsem Linux přeinstaloval. Když jsem o týden později zjistil, že to šlo udělat i pomocí fstabu, tak mě málem kleplo

[jk]

Nevidim duvod proc nepouzit swap. V beznem provozu ho linuxu nepouzije, takze nepredstavuje zadne zpomaleni. Ale kdyz narazis na nejaky neslusny program, nebo se treba pokusis otevrit 4 gigovy soubor v textovym editoru, tak ti da swap sanci zareagovat a program zabit.

[Luboš Doležel (Doli)]

Procesy žeroucí více než 1 GB nechávám střílet rovnou, na to swap nepotřebuju.

[Jakub Lucký]

U takovýchto procesů já střílím vývojáře ;)

Výše uvedený příspěvek je pouze vtip a nemá nic společného s názorem na vývojáře aplikací

[Filip Jirsák]

Program, který nechá paměť spravovat jádro, místo aby si ji spravoval sám, je neslušný? Ona by si JVM samozřejmě mohla přerovnávat paměťové stránky, nepoužívané odkládat na disk – ale řekl bych, že v systému už je jedna komponenta, která tohle dělá, takže by nebylo zrovna šťastné její práci duplikovat.

[Luboš Doležel (Doli)]

Jenže to JVM přesně nedělá. Zažere si podstatnou část systémové RAM a tu nechce jen tak uvolnit. Nejde o odkládání, jde o uvolnění.

[Filip Jirsák]

Ne, JVM nesežere podstatnou část systémové RAM. JVM si vezme systémovou paměť (maximálně množství určené uživatelem), a je starostí systému, aby zabranou paměť rozložil mezi RAM a swap.

[Luboš Doležel (Doli)]

Takže aby program zažral nějakou paměť, kterou zrovna nepotřebuje a neuvolnil ji, je v pořádku? Podle mě rozhodně ne.

[jk]

Ta pamet se pouziva - potrebuje ji pro svou cinnost GC javy. Urcite by bylo technicke mozne volat malloc/free pokazde, kdyz se zmeni vyuziti heapu, ale zrejmne u Sunu usoudili, ze by to bylo prilis pomale.

Problem je spise v tom, kolik pameti Java potrebuje. U noveho pocitace je to celkem jedno, ale u starsich pocitacu muze mit smysl dat prednost aplikaci, ktera je napsana v jinem jazyku. Ale urcite bych aplikaci nezavrhoval proto, ze alokuje 60MB a pritom by ji stacilo 40MB.

[Algi]

Na druhou stranu, je technicky možné udělat takový GC, který nepotřebuje předem znát rozsah paměti. Skvělým příkladem je Objective-C 2.0. Kdo ví, zda by toto šlo použít i v Javě.

[Luboš Doležel (Doli)]

U noveho pocitace je to celkem jedno, ale u starsich pocitacu muze mit smysl dat prednost aplikaci, ktera je napsana v jinem jazyku.

To je právě ten přístup, co se mi nelíbí. Omlouvat zbytečné nároky tím, že je k dispozici více prostředků. To je pak nekonečný závod.

(Tímto nechci vyjadřovat směrem k autorovi programu cokoliv negativního. Je to velmi pěkný program.)

[Filip Jirsák]

To mělo smysl v případě, kdy program používal přímo fyzickou paměť. V době, kdy s epoužívá virtuální paměť, nepoužívané stránky se odkládají do swapu, nemá smysl plýtvat prostředky na to, aby program uvolnil paměť, kterou bude vzápětí znova alokovat.Dřívě se muselo programovat tak, že programátor do paměti načetl jen to nejnutnější a jakmile se ěnco zpracovalo, hned se to odložilo na disk. Dnes je ale rozumnější, pokud program nepracuje opravdu s velkým množstvím dat (jako foto, video, databáze) mít data v paměti a serializací a deserializací se zabývat pouze při startu a ukončení programu. Jinak je lepší nechat swapování na OS, protože ten ví líp, jaký je celkový stav systému, jaké procesy jsou aktivní atd. Vracet paměť by mělo smysl snad jenom v případě, kdy by program nějaké velké množství paměti potřeboval pro nějakou operaci, kterou by dokončel a běžel by dlouhodobě dál, ale už by bylo jasné, že se taková operace nebude opakovat. Ale to není zrovna častý případ použití. A aby program vracel paměť, kterou nejspíš bude brzo znova alokovat, to mi nepřijde moc rozumné…

[Deleted [8409]]

Když si představím 5 programů, co si každý vezme 100MB pro případ, že by je mohl náhodou potřebovat, tak z toho je 500MB, což je celkem slušná velikost pro dalších X desítek programů.

[David Jaša]

Tohle téma se tady probíralo už před nějakou dobou.

[Luboš Doležel (Doli)]

V té diskuzi si lidé bohužel pletou alokaci většího množství paměi, která se nepoužije, s memory leakem, kde se paměť použila. V tom prvním overcommiting pomůže, v tom druhém nikoliv.

[Filip Jirsák]

Mě představa 500 MB někde na swapu nijak nedrásá. Naopak představa, že program sám bude něco iniciativně uklízet z paměti, zdržovat zápisem na disk, a to jenom proto, co kdyby náhodou, mne moc neláká. Mimochodem, zrovna JVM (alespoň ta Sunovská) je zrovna program, kde můžete určit, kolik paměti má alokovat na začátku a kolik maximálně. Který další program vám nabízí nastavení takového limitu?

[Deleted [8409]]

Mě celkem jo, protože ta paměť se někdy musí odswapovat a třeba na noťasu 500MB je celkem zabíračka pro systém

Java aplikaci používám jednu - Eclipse. A můžu říct, že když občas čekám třeba půl minuty na to, než se "odswapuje", abych mohl ve zdrojáku něco změnit, tak je to otravné:(

[Filip Jirsák]

Jenomže ta paměť se odswapuje jenom v okažiku, kdy je to skutečně potřeba. Jenže pokud by ta aplikace řešila sama svůj swap, swapovala by daleko častěji (preventivně). Navíc nezdržuje ukládání z RAM do swapu, které se děje průběžně, zdržuje to, když je potřeba najednou ze swapu nahrát data do paměti. Jediné, co by ta aplikace ušetřila, že by data mohla nějak do svého swapu komprimovat. Na druhou stranu by ale data z disku načítala daleko častěji (protože by musela paměť uvolňovat preventivně). Nejlepší by bylo, pokud by systém mohl poslat aplikacím zprávu „dochází paměť, pokud můžete něco uvolnit, uvolněte to“. Jenže takováhle zpráva neexistuje. A preventivní uvolňování paměti znamená, že paměť v drtivé většině případů uvolníte zbytečně.

eclipse není zrovna moc dobrá ukázka Javovské aplikace, protože pod tím máte nativní SWT.

[Deleted [8409]]

Eclipse je zatím to nejlepší co jsem našel pro python, pokud víte o něčem jiném tak rád vyzkouším

Ale s tím swapem si možná trochu nerozumíme, mi jde o to, že já mám třeba 1GB ram. A pokud eclipse využívá průměrně 300 MB, je to 1/3 systémových prostředků. Toto se projeví hlavně když potřebuju něco kopírovat nebo spustit jiné aplikace (které taky žerou), pro které už není tolik paměti a systém začne právě swapovat. Jenže jak můžete vědět, že se netrefí zrovna do místa, které bude eclipse potřebovat když se na něj přepnu a budu chtít něco editovat ?

Toto je podle mě ten problém, systém neví, které data aplikace potřebuje a které ne. Proto si myslím, že by bylo nejlepší, kdyby se to místo radši uvolnilo, protože namapovat se může kdykoliv, ne ?

Ještě mě zajímá jedna věc co se tu diskutovala. Jak časově náročné pro aplikaci je vrátit paměť systému a znova si o ni zažádat ? Berme v úvahu pro zjedodušení třeba jen malloc() a free() - Mi to přijde bleskové, ale možná je něco o čem nevím, nbo jiný problém v oblasti virtuálních mašin

[Filip Jirsák]

Ještě mě zajímá jedna věc co se tu diskutovala. Jak časově náročné pro aplikaci je vrátit paměť systému a znova si o ni zažádat ? Berme v úvahu pro zjedodušení třeba jen malloc() a free() - Mi to přijde bleskové, ale možná je něco o čem nevím, nbo jiný problém v oblasti virtuálních mašin

Přinejmenším je to systémové volání, takže se musí přepnout kontext. Navíc aplikace nežádá extra o každých pár bajtů, ale žádá o celé stránky. Takže pak by musela neustále sledovat, co je kde jak zaplněné a pokoušet se shlukovat prázdná místa, aby dostala celou prázdnou stránku a tu mohla uvolnit. A to vše by dělala preventivně, co kdyby někdy začla docházet paměť.

To je podle mne lepší mít v počítači tolik RAM, aby se do ní vešly všechny současně používané aplikace najednou. Pak ke swapování dojde jenom v okamžiku, kdy jednu aplikaci přestanete používat ale necháte ji spuštěnou – místo uložení stavu a znovunačítání když aplikaci znovu spustíte se pak prostě jen obraz paměti odloží na disk a zase se z něj přečte. Je to podobné, jako s uspáním počítače – taky je výrazně rychlejší odložit obsah RAM na disk a po probuzení počítače jej odsud znovu načíst, než všechny programy startovat znovu.

[Deleted [8409]]

Takže když to shrnu. Aplikace (nemusí být nutně ani JavaVM) si alokuje mnohem víc paměti proto, aby se ušetřilo řekněme pár systémových volání. Nebudu dělat benchmark systémového volání, ale třeba otevření souboru je taky syscall nebo ne ? A toto je naprosto běžná činnost.

Teď jen doufám, že jsem se nesekl, jinak mě tu profíci sežerou

[Ladicek]

Aplikace (nemusí být nutně ani JavaVM) si alokuje mnohem víc paměti

Obvykle to nebývá aplikace, ale alokátor jakožto součást standardní knihovny. Obvyklé alokátory to mimochodem dělají velmi podobně, akorát u javovského heapu je velmi dobře vidět obrovská velikost inkrementu (vždy rovna aktuální velikosti, čili z 64 MB se heap zvětšuje rovnou na 128 MB, to je celkem nemilé, i když to asi má nějaké principiální důvody stran jednoduchosti a efektivity implementace, fragmentace a já nevím čeho).

[Filip Jirsák]

Otevření souboru je běžná činnost, ale jinak než systémovým voláním to dělat nejde. Paměť také nejde alokovat jinak, než systémovým voláním, ale aspoň je možné to nedělat pro každý bajt zvlášť – jeden bajt vám jádro myslím stejně nedá, ale ani knihovní alokátory podle mne nealokují paměť od systému po nejmenších možných jednotkách a nevracejí ji okamžitě zpět.

[Deleted [8409]]

Alokátor používá bloky dejme tomu 1MB (takže pro každé MB syscall), potřebuju 100 MB (postupně) == 100 systémových volání. Ptám se, je to moc ?

Toto je obrazná situace, přijde mi, že to právě není vůbec moc. Jak říkám, nedělal jsem nikdy bechmark, ale například při spuštění eclipse mi to trvá asi 20 až 30 sekund, pochybuju, že ušetření 100 nebo klidně 1000 syscalů bude mít nějaký efekt:)

OT: Zajímalo by mě jak toto řeší např. .NET, protože ty aplikace mnohem míň žerou, a přijdou mi i rychlejší, ale nechci o tom flejmovat :)

[Jakub Lucký]

Imho je .NET už naloadovaný předem, takže se do toho nezapočítá všechno (jako u Javy celý JVM)...

Ale z .NET mám teda dost podobný pocit žravosti...

[Luboš Doležel (Doli)]

Tady už se ale diskuze dostala pryč od původního problému. Pokud by stále jak alokovala a uvolňovala, tak to nesmysl je. S tím souhlasím.

Diskuze ale začala s tím, že je alokováno XXX megabajtů, ale ty se z části nepoužívají a jsou zabrané "co kdyby náhodou". Je otázka, zda je to skutečně pravda.

[Filip Jirsák]

Diskuze ale začala s tím, že je alokováno XXX megabajtů, ale ty se z části nepoužívají a jsou zabrané "co kdyby náhodou". Je otázka, zda je to skutečně pravda.

Za prvé, pokud se nepoužívají, mají ležet někde ve swapu, a tam mne netrápí. Za druhé, pokud si někdo nastaví, že má JVM hned na začátku alokovat 512 MB, když aplikace nikdy nevyužije víc než 20 MB, je to jeho problém. Mimochodem, výchozí hodnota pro maximum heapu je 64 MB.

[David Watzke]

Dívám se do htopu na hodnotu RES a to je afaik kolik fakt využívá...

[Kamil Páral]

Nevím jak to přesně funguje u Javy, ale myslím, že na požádání tu paměť uvoluje. Je zbytečné paměť uvolňovat, dokud ji nikdo nechce, že? Každopádně podle jconsole by mělo být reálné využití paměti po provedení garbage collection zhruba 25-30MB. Ale nejsem v tomhle expert.

[Luboš Doležel (Doli)]

Nevím jak to přesně funguje u Javy, ale myslím, že na požádání tu paměť uvoluje. Je zbytečné paměť uvolňovat, dokud ji nikdo nechce, že?

Takhle to nefunguje. Jádro procesům určitě neříká "hele, nechceš třeba něco uvolnit?". To případně rovnou střílí.

[jk]

Nezada jadro, ale samotna Java. Sprava pameti v Jave velice zjednodusene funguje tak, ze se nejakou dobu pamet vubec neuvolnuje. Kdyz dosahne mnozstvi pouzivane pameti urcite hranice (ktera se da nastavit), tak se projdou vsechny alokovane objekty a ty nepotrebne se uvolni.

[Luboš Doležel (Doli)]

Uvolní ji ale jen pro sebe, ne nezbytně systému. A o to jde.

[Ilfirin]

Teď koukám, že mám nainstalováno i IcedTea. Jestli se mi náhodou nepouští ten ("whereis java" moc nenapovídá) a třeba s ním není Esmska kompatibilní :-/.

[Kamil Páral]

V Ubuntu je projekt IcedTea a OpenJDK sloučen do balíčku openjdk. Což by mělo bez problémů jet, pokud nebudeš používat skiny Substance.

[Ilfirin]

Díky za radu. Po přepnutí skinu Substance na systémový, program evidentně ožil.

[laco]

Poučen od P.T. jsem zkoušel ten program nikoliv v Linuxu, ale v XP a jede skvěle. Rychle a spolehlivě.

[Algi]

Jsou dokonce známy i případy, kdy byla Esmska spuštěna pod Windows Vista

[laco]

No to je paráda !

[Algi]

Systémové integraci jsme s Kamilem věnovali velkou pozornost. Pokud se ti naskytne příležitost spustit Esmsku pod Vistama, tak jí zkus přepnout na systémový vzhled a pošli mě screenshot. Docela by mě zajímalo, jakou práci odvedl Sun při portování Javy na Windows Vista. Díky.

[Nicky726]

Ad Systémová integrace: Vzhled GTK je pod KDEmod bezchybný, škoda že zatím není nic pro QT

[Algi]

Pro QT existuje QTJambi, což je knihovna pro Javu. Avšak její použití neplánujeme, znamenalo by to přepsání do jiného frameworku a to by byla práce navíc...

[slush]

Jen poznamenavam, ze nova verze je zabalena a funkcni v repository pro debian/ubuntu, viz. Ubunti wiki

[Ilfirin]

Mimochodem. Jak se dnes odesílají SMSky? Je na to nějaký trik (ala email), nebo se to pokouší vyplnit formulář na webu? Díky

[Kamil Páral]

Parsování webových stránek operátorů. Nic světoborného.

[Ilfirin]

Díky . Zrovna se učím PyGTK, tak mám motivaci na malý testovací prográmek.

[the.max]

Nevite o nejakem programu/skriptu, ktery dokaze odesilat smsky z prikazove radky?procte neco ve smyslu program $cislo $text ??? nebo to esemesak umi take?

[Kamil Páral]

Neumí. smssend. Akorát si asi budeš muset aktualizovat (čti: napsat vlastní) skripty pro české operátory.

[Ilfirin]

A co captcha?

[Kamil Páral]

smssend používá gocr