Organizace Apache Software Foundation (ASF) vydala verzi 20 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Desktopové prostředí Cinnamon, vyvíjené primárně pro distribuci Linux Mint, dospělo do verze 6.0. Seznam změn obsahuje především menší opravy a v říjnovém přehledu novinek v Mintu avizovanou experimentální podporu Waylandu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzích 2.2.2 a 2.1.14. Přináší důležitou opravu chyby vedoucí k možnému poškození dat.
V ownCloudu byly nalezeny tři kritické zranitelnosti: CVE-2023-49103, CVE-2023-49104 a CVE-2023-49105 s CVSS 10.0, 8.7 a 9.8. Zranitelnost CVE-2023-49103 je právě využívána útočníky. Nextcloudu se zranitelnosti netýkají.
I letos vychází řada ajťáckých adventních kalendářů. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2023. Pro programátory v Perlu je určen Perl Advent Calendar 2023. Zájemci o UX mohou sledovat Lean UXmas 2023. Pro zájemce o kybernetickou bezpečnost je určen Advent of Cyber 2023…
Byla vydána verze 2.12 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 23.11 Topi. Přehled novinek v Changelogu.
Po 4 měsících vývoje byla vydána nová verze 4.2 multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu a na YouTube.
Byla vydána nová stabilní verze 23.11 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Tapir. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) upozorňuje na hrozbu spojenou s používáním mobilní aplikace WeChat a její čínské verze Weixin (dále jen WeChat). Ta sbírá velký objem uživatelských dat, a právě to by – v kombinaci se způsobem jejich sběru – mohlo sloužit k přesnému zacílení kybernetických útoků.
Ahoj,
je tady nekdo, kdo pouziva Jabber? Nebo pres co komunikujete? Zatim vyuzivam Gtalk a dale mam na svem serveru Prosody jako Jabber server. Pripojuji se k tomu z Psi na WIN a Yaxim na androidu. Rad bych se Gtalku zbavil a pouzival jen svuj server s nejakymi transporty, abych mel vsechno pod jednim uctem (Gtalk, ICQ i Jabber), ale mam s tim Jabberem problemy.
Pouzivam tri klienty (Notebook, PC a Mobil) a dost mi chybi ta googlovska funkce, ze muzu chatovat z mobilu, PC, proste odkudkoliv, vsude vidim historii a offline zpravy.
Jabber by mel umoznovat preposilat kopie zprav na jine zarizeni, ale nefunguje mi to. Kdyz zapomenu shodit klienta v praci (Psi) ktery ma vyssi prioritu, nez mobil, protoze psani pres mobil je pomalejsi, tak kdyz mi nekdo napise, i kdyz mam mobil ONLINE, tak to nezjistim, pokud se nepripojim na remote desktop.
Chtelo by to reseni, ktere by na serveru archivovalo neprectene zpravy a ty to zobrazilo na klientovi, ktery si je zobrazi jako posledni. Defakto by to mohlo fungovat jako IMAP. Jenomze nevim, zda tohle prosody umi - asi ne a nejsem si jisty, zda to bude umet jiny server.
Jak resite instant messaging, pokud chcete mit svuj server, aby se vam ve zpravach nehrabal google, nebo nekdo jiny?
P.
Ano, presne jak pises... Kdyz se klient odpoji vypadkem spojeni, muzou zpravy chodit, ale pritom se ztracet v cerne dire. Odesilatel nepozna, ze zprava nebyla dorucena. Tohle mne taky neskutecne se...
Jak jsem byl z jabberu nadseny, tak nadseni rychle vyprchalo. Dnes by to chtelo neco, co by melo i nejake webove GUI s moznosti prochazet historii zprav - neco jako je Gmail a Gtalk v nem. Prijde mi, ze neexistuje zadny rozumny IM - skoro se mi jevi jako nejlepsi komunikovat pres email s IMAPem
Pritom by jen stacilo vymyslet neco, co by oznamovalo pouze nove prichozi zpravy a umoznovalo na ne ihned odepisovat, jinak by to zachovalo princip emailu. Jabber koncept mi prijde neskutecne komplikovany.
Vzdyt to bezi pres TCP - odesilatel si muzes precist ze socketu, kolik dat bylo ACKnuto.Ano, presne jak pises... Kdyz se klient odpoji vypadkem spojeni, muzou zpravy chodit, ale pritom se ztracet v cerne dire. Odesilatel nepozna, ze zprava nebyla dorucena. Tohle mne taky neskutecne se...
Vzdyt to bezi pres TCP - odesilatel si muzes precist ze socketu, kolik dat bylo ACKnuto.A jak konkrétně? Už jsem o tom s lidmi diskutoval dříve a popravdě teď nemůžu najít ani jako to udělat na Linuxu, natož všude jinde nebo dokonce v obecných vrstvách pro síťování. Co se tak dívám, tak dostupná API prezentují TCP víceméně jako dvojici streamů, přičemž jabber je explicitně postavený na zprávách a ty taky umožňuje potvrzovat. Teoreticky by bylo možné bufferovat zprávy a nechat si od operačního systému zasílat (pomocí monitorování souborového deskriptoru) o potvrzeném sekvenčním čísle a zároveň si udržovat přehled o aktuálním sekvenčním čísle a tím pádem o rozsahu sekvenčních čísel pro danou bufferovanou zprávu. Ale takové řešení jsem neviděl a nejsem si jistý, zda to bez úpravy kernelu vůbec lze.
getsockopt(fd, SOL_TCP, TCP_INFO, &info, sizeof info);Vzdyt to bezi pres TCP - odesilatel si muzes precist ze socketu, kolik dat bylo ACKnuto.A jak konkrétně?
Skutečně jsem si dal práci s hledáním, neúspěšně, takže díky! Nicméně z hlediska diskuze je to jen první krok.Pokud Vas zajima systemove programovani, mel byste si precist hlavicky z kernelu. Spousta veci v manualovych strankach chybi.
Jde nějak zajistit, abych se dozvěděl o změně (tedy nechat si třeba přes epoll propagovat informaci o tom, že přišel ACK a mám k dispozici nové ackované sekvenční číslo) nebo je potřeba se čas od času doptat?Root si to muze zaridit pres netfilter, ale v tomto pripade mi to prijde zbytecne.
U klienta by mi šlo nejen o to, aby při ztrátě spojení věděl, co všechno bylo neodeslané, ale také aby uměl uživatele informovat u každé odeslané zprávy, že se dostala alespoň k serveru, ať už změnou barvy nebo třeba tím, že do té doby zprávu vůbec nezobrazí. Samozřejmě bych z mnoha důvodů byl rád, aby se aplikace pokud možno vůbec neprobouzela, pokud pro ni žádná nová data nejsou.Jak klient tak server si mohou hodnotu precist po tom, co odeslou a nebo prijmou zpravu a nebo se spojeni prerusi. Delat to casteji nema moc smysl, protoze jediny rozdil by byl, kdy se uvolni pamet, nikoliv vsak v maximalnim mozstvi potrebne pameti, ktere bude vzhledem k velikosti ostatnich buferu v kernelu radove desitky kB (pote bude send blokovat a nebo selze).
Pak by mě rovněž zajímalo, jestli je toto v nějaké formě dostupné na všech dnes běžných operačních systémech. Trochu problém bude s různými mezivrstvami, které takovéto detaily vůbec neřeší, ale to se holt nedá nic dělat.Je to v Linuxu a ve FreeBSD. S nicim jinym nepracuji, takze jsem se o to nezajimal.
Nakonec by mě zajímalo, jestli existuje alespoň jeden jabber klient testovatelný na linuxu, který by toto podporoval (alespoň ve vývojové nebo patchované verzi). Podle mě by to nemusela být špatná alternativa pro případ, kdy druhá strana nepodporuje aplikační acky.Kopete v KDE3 detekuje "ztracenou" TCP zpravu.
Pokud Vas zajima systemove programovani, mel byste si precist hlavicky z kernelu. Spousta veci v manualovych strankach chybi.To bude jistě zajímavé čtení, ale mám v zásobě ještě dost jiné literatury ;).
Root si to muze zaridit pres netfilter, ale v tomto pripade mi to prijde zbytecne.V tomto případě se především jedá o uživatelskou aplikaci.
Jak klient tak server si mohou hodnotu precist po tom, co odeslou a nebo prijmou zpravu a nebo se spojeni prerusi.Klient si může hodnotu přečíst ve chvíli, kdy úspěšně odešle data kernelu, jenže v tu chvíli je mu tak nějak prd platná, pokud nelze zaručit, že kernel odešle data po síti před vrácením kontroly aplikaci.
Delat to casteji nema moc smyslKlient to nepotřebuje dělat častěji, nýbrž ve chvíli, kdy přijde ACK. Pokud přijde s daty, tak ok, o tom se dozvíme, pokud by přišel samostatný ACK, tak asi smůla, ne? A bavíme se o TCP, které zadržuje data často a při problémech se sítí především, ne?
Je to v Linuxu a ve FreeBSD. S nicim jinym nepracuji, takze jsem se o to nezajimal.Díky, zajímalo mě to i kvůlu univerzalitě.
Kopete v KDE3 detekuje "ztracenou" TCP zpravu.Jen pro zajímavost, jak na takovou situaci reaguje?
Tak napriklad chromium taky pouziva pomocnou suid binarku, takze se to muze resit podobne, ale jak jsem jiz napsal, prijde mi to zbytecne.Root si to muze zaridit pres netfilter, ale v tomto pripade mi to prijde zbytecne.V tomto případě se především jedá o uživatelskou aplikaci.
Zrejme jste me nepochopil - program si zpravu drzi v pameti do doby, nez je jasne, ze byla druhou stranou prijata a nebo neprijata. Socket ale kontroluje jen pri nejake jine operaci s nim. Timto zpusobem se nezmeni pocet probuzeni procesu a spotrebovana pamet se zvysi maximalne o velikost odesilaciho zasobniku, coz neni problem udrzet pro spousty spojeni klidne i delsi dobu.Jak klient tak server si mohou hodnotu precist po tom, co odeslou a nebo prijmou zpravu a nebo se spojeni prerusi.Klient si může hodnotu přečíst ve chvíli, kdy úspěšně odešle data kernelu, jenže v tu chvíli je mu tak nějak prd platná, pokud nelze zaručit, že kernel odešle data po síti před vrácením kontroly aplikaci.Delat to casteji nema moc smyslKlient to nepotřebuje dělat častěji, nýbrž ve chvíli, kdy přijde ACK. Pokud přijde s daty, tak ok, o tom se dozvíme, pokud by přišel samostatný ACK, tak asi smůla, ne? A bavíme se o TCP, které zadržuje data často a při problémech se sítí především, ne?
Prijde falesna zprava od puvodniho prijemce, ze zprava nebyla dorucena.Kopete v KDE3 detekuje "ztracenou" TCP zpravu.Jen pro zajímavost, jak na takovou situaci reaguje?
Zrejme jste me nepochopilTo je sice zajímavá teorie, na druhou mám obavu, že je to přesně naopak. Vrátím se tedy k tomu textu, na který to měla být odpověď.
U klienta by mi šlo nejen o to, aby při ztrátě spojení věděl, co všechno bylo neodeslané, ale také aby uměl uživatele informovat u každé odeslané zprávy, že se dostala alespoň k serveru, ať už změnou barvy nebo třeba tím, že do té doby zprávu vůbec nezobrazí. Samozřejmě bych z mnoha důvodů byl rád, aby se aplikace pokud možno vůbec neprobouzela, pokud pro ni žádná nová data nejsou.Tato funkcionalita přímo závisí na tom, že se o ACKu dozvím plus mínus ve chvíli, kdy přijde. U piggyback ACKů lze detekovat příchod ACKu při detekci přijímaných dat, protože ta epoll() probudí. Ale samostatné ACKy, pokud to chápu správně, epoll() nepřeruší, tudíž tato metoda vyžaduje, aby druhá strana jako odpověď na zprávu poslala alespoň něco (i kdyby white space), a to mi přijde značně neelegantní, stejně jako mi přijde neelegantní řešit to nějakou suid binárkou a bůhvíjakým rozhraním.
Já s tím moc nelaboroval, ale tenhle XEP může za to, že mi zpráva přijde na všechny tři klienty, kteří mají stejnou prioritu? Mám to totiž od začátku na prosody zapnuté a takhle to funguje. Bez toho by se to chovalo jak? Když mají všichni klienti stejnou prioritu? Nepřišlo by to náhodou taky na všechny?
A druhá věc - je celkem nepříjemné, když mám v práci zapnutého klienta. Přijdu domů a zapnu klienta na NB. Ale v práci mezi tím bliká nová zpráva. Je šance se k ní dostat? Prostě načíst všechny "nepřečtené" zprávy? Tohle by asi měl dělat ten XEP s Historií, že? To je taky věc, která mě dost sejří - musím se pak přes RDP připojovat do práce a kontrolovat klienta přes desktop, jestli někdo něco nepsal - no pakárna.
Zjistil jsem, ze se tomu da trochu pomoct. Nastavil jsem si vsechny tri klienty na prioritu 0. Funguje to tak, ze kdyz s nekym zacnu chat, tak na dalsi zarizeni se prestane posilat co mi pise. Takze kdyz jsem klasicky online, nekdo napise, vyskoci mi notifikace na vsech pripojenych klientech. Kdyz zacnu komunikovat na NB, tak mi dalsi zpravy na mobil a pc uz nechodi.
Tohle je OK. Problem nastava, kdyz od NB odejdu a chtel bych pokracovat treba na mobilu, nebo PC. Tak to nejde udelat automaticky. Odesilatel by musel UKONCIT CHAT a zacit novy, to by mi zase poslalo notifikaci na mobil a PC a mohl bych pokracovat v komunikaci.
Zjistil jsem, ze staci, kdyz JA na mobilu zvolim - STAV - a dam ok. Proste udelam zmenu stavu na stejny, jaky jsem mel. Tim se jakoby ohlasim a dalsi zprava mi zase prijde i na mobil.
To je fajn, ale neslo by nejak udelat, aby se tenhle stav menil treba s tim, ze aktivuju obrazovku? Nebo treba ze na NB, nebo PC pohnu mysi? To jsem nezkousel, jestli ma vliv, ale primarni je, aby mi takhle fungoval YAXIM na mobilu. Protoze casto mi nekdo pise, kdyz jsem u PC, ale ja pak necham klienta bezet a on mi pise za hodinu, ale veskere zpravy mi prijdou na PC, u ktereho uz nejsem, pritom mobil mam online, ale dokud rucne "neohlasim" stav, tak je pro dany kontakt mrtvy.
Jak na to? Takhle je ta komunikace pekelne nespolehliva, horsi, nez posilat postovniho holuba
Tak jeste update - kdyz se na mobilu zmeni stav Online / pryc tak se tim mobil ohlasi a notifikace zase zacnou chodit, takze je to SKORO ok Uz jen zjistit, proc se mi yaxim pravidelne sekne vzdycky pres noc a proc prestava chodit pri zmene pripojeni wifi / 3G a bude to fajn.
Uz jen vyresit, aby v pripade, ze mi vypadne v rozjete komunikaci spojeni, tak aby se zpravy budto dorucily pozdeji, nebo se odesilateli zobrazilo, ze je nejaky problem. Tohle bude ale dost problem v pripade transportu treba ICQ - neumim si predstavit, jak by ten transport zasilal zpet na ICQ konto info o tom, ze zpravu se nepodarilo dorucit.
Na instant messaging používám (výhradně) Jabber. Google Talk je naštěstí zatím ochotný komunikovat i s jinými Jabber servery, takže s mým Jabber účtem (který nijak nezávisí na službách Googlu) můžu komunikovat i s lidmi na Google Talku. To tedy znamená, že pro Google Talk není potřeba žádný transport.
Synchronizace offline zpráv nejspíš někde v XMPP specifikaci existuje, ale nevím bohužel o klientovi, který by něco takového uměl. Klienti mají možnost ukládat si na serveru nějaká data, ale příliš toho nevyužívají.
Klient v práci by měl automaticky snížit svou prioritu, když jsi away, unavailable nebo offline. Pak by měly zprávy přednostně chodit na mobil. Naopak online priorita toho klienta v práci by měla být vyšší než priorita mobilu. Tím by se mělo docílit požadovaného chování. Jiná situace ovšem je, když někdo vydoluje staré chatovací okno, do kterého psal ještě na ten počítač v práci. To se pak zprávy často pošlou na tentýž zdroj, i když se priorita změnila. V Psi je tohle vyřešeno poměrně flexibilně možností vybrat explicitně zdroj, na který se má zpráva poslat. (Pak je tam vždy ještě možnost poslat zprávu prostě uživateli bez udání zdroje, což znamená, že se pak doručování řídí podle priority zdrojů.)
Já používám jako Jabber server Openfire. Ten má možnost archivovat zprávy, ale nevím, jak to (ne)funguje, protože jsem archivování nikdy neměl zapnuté. Předpokládám, že to taky vyžaduje, aby se klient dokázal ke službě „Monitoring“ připojit a historii z ní přečíst. Zapnul jsem si tedy příslušný plugin v Openfire a vypadá to, že dokonce i funguje, ale zatím se mi nezdá, že by některý z klientů tuhle službu rozumně podporoval.
Což nejspíš vysvětluje, proč mi to archivování s žádným klientem nefunguje a proč jediný přístup k němu je webové rozhraní OpenFire, které samozřejmě nemá s XMPP nic společného. To je vskutku smutné.
Presne tak. Smutna je i situace okolo Gtalku, protoze dnes vetsina lidi, co ma android telefon upgradovala na Hangouts a tim jejich puvodni jabber Gtalk ztratil moznost komunikovat s klasickym jabberem. Proto uz zacina byt jabber nepouzitelny i ke komunikaci smerem ke "Gtalk" kontaktum.
Proste jsem procitl a zjistil, ze pokud nechci pouzivat Facebook, nebo Google, nemam jinou moznost, nez se vratit o 10 let zpatky ke klasickemu emailu. To je ZATIM jediny komunikacni kanal, ktery je otevreny, muzu si jej provozovat na svem serveru, ma jej KAZDY a hlavne, je SPOLEHLIVY.
Rekl bych, je jabber, jak byl vymyslen je proste k nicemu. Vsechny zpravy jdou stejne pres nejaky server, proto nechapu, proc to nefunguje stylem, ze se veskere zpravy na ten server ukladaji a v klientovi nelze zvolit, zda je mazat / ponechat - defakto jako email. Bylo by to spolehlive, jednoduche a udelat klienta pro vsechny OS by nebyl zadny velky problem.
Pouzivat Facebook / Hangouts nebo jine kramy, at uz se sifrovanim, je pro mne neakceptovatelne - sifrovani je kratkodoba vec. Do budoucna nezarucuje soukromi a proto pokud mozno, nechci, aby vsechny zpravy zustavaly na serverech facebooku, apod.
P.S. jeste k tem snaham ucinit Jabber spolehlivym - je sice krasne, ze po uprave kernelu a kdo vi ceho, dokazu zjistit, ze se zprava nedorucila - ALE, co je mi to platne v pripade transportu? Kdyz mi napr. uzivatel zasle zpravu na ICQ, tak by se musely upravit i transporty, aby zpet zaslaly zpravu ve smyslu : zprava nebyla dorucena.
Neni jednodussi vymyslet novou opensource komunikacni platformu? Na bazi klient / server, kde by v pripade neuspechu zustaly zpravy ulozene na serveru? Proste okopirovat Gtalk.
Neni jednodussi vymyslet novou opensource komunikacni platformu? Na bazi klient / server, kde by v pripade neuspechu zustaly zpravy ulozene na serveru? Proste okopirovat Gtalk.Jakože máme IRC, to se nám nelíbilo, vyrobíme jabber. Máme jabber, ten se nám nelíbí, vyrobíme si další. Ono je to celé tak trochu pitomost, ve skutečnosti by bylo mnohem lepší definovat, co všechno taková síť má umět, jak se toho konceptuálně docílí. Pak je v podstatě jedno, zda se to implementuje rozšířením stávajícího protokolu nebo vytvořením nového, nebo dokonce oběma způsoby. Podstatné na tom celém je, aby primárním účelem software nebylo poskytovat protokol, ale službu. Pak může službu poskytovat pomocí jednoho protokolu, na kterém se většina shodne, ale klidně i pomocí několika různých, třeba i redundantních protokolů, pokud se většina neshodne.
Tak mne napada, proc by to defakto nemohlo frcet na klasickem emailu? Vzdyt imap je super - jen by ho to chtelo upravit tak, aby komunikace fungovala trochu vice realtime. Email ma vse co potrebuji - historii, offline zpravy, dokonce prectene/neprectene, podporuje i zasilani potvrzeni o precteni.
Jedine, co tedy chybi, je klient, ktery by zpravy zapisoval v okne pod sebe a pak ochrana proti spamu - zde by se jednoduse dalo definovat, ze prijimam IM zpravy jen od kontaktu, ktere mam v seznamu.
No reknete, neni to lepsi, nez stavet nejaky dalsi protokol? Navic, ten, kdo nema zadneho klienta, tomu by prisla moje IM zprava klasicky do emailu - bylo by to absolutne multiplatformni.
SERVERY - kazdy si muze vybrat, zda pouzije hostovany server, nebo vlastni. Lze aplikovat sifrovani, zasilat prilohy - vsechno je uz definovane, hotove a funkcni. Jen ti klienti nejsou vhodni pro instant messaging. Tak proc neupravit klienty?
Defakto by se IM zpravy od tech klasickych mohly lisit jen nejakym autorizacnim retezcem v predmetu emailu. To by mohlo resit i problem se spamem - nejsem v tom kovany, ale urcite by se dalo nejak zaridit, aby clovek dle sveho verejneho certifikatu dokazal podepsat svoji IM zpravu a ten podpis napasovat do predmetu zpravy. Podvrzenou zpravu by zahodil bud uz server, nebo klient.
Zprava bez retezce v predmetu by dorazila klasicky jako email - a postovni klient by si ji nevsimal.
A ted mi reknete, jake ma tohle reseni problem, proc by to neslo udelat a nemohlo se ujmout? Misto pouzivani nejakych debilit tapy facebook, gtalk, whatsapp, viber a jinych.
P.
Tim padem nevidim jediny duvod, proc nepouzit fungujici servery a neupravit jen soft, aby lepe odpovidal potrebam IM.Nevidím důvod, proč jsi ještě neukázal výsledky.
Protoze nejsem programator. Specializuju se na HW a jednocipy, ne na PC SW. A zatim o tom diskutuji a prijimam podnety a nazory. Je to zatim jen napad. Pokud mi ho nikdo nevyvrati, pak to sepisu a prednesu tvurcum klientskych aplikaci pro email, jako podnet na vylepseni. Ale sam to programovat nezvladnu. Nemyslim si, ze by clovek, ktery ma napad, musel nutne stat za jeho realizaci. Ano, taky znam spoustu kecalu, ale taky znam hodne schopnych lidi, kterym zase chybi napady.
Ja z toho nechci delat komercni projekt. Chci vymyslet neco, co pouze mi a dalsim lidem ve snazsi komunikaci. A neocekavam od teto diskuze zdrojove kody, ale podnety a pripominky.
Napada mne, ze jsem videl i rozsireni pro FF, coby jednoduche emailove klienty. To by taky nemuselo byt spatne - upravit ho pro prochazeni danych slozek imapu a chatovani s danymi kontakty v prepinatelnych zalozkach. FF je multiplatformni, odpadl by tedy Thunderbird, ktery je na ustupu. Pro WIN / Linux a MacOS by tedy stacil FF a pro pristup pres web Roundcube. Roundcube by resil i webovou historii az do ja nevim jake hloubky. Vtip je taky v tom, ze vetsina emailovych klientu ma VYMAKANE vyhledavani, takze by se dalo ve zpravach dobre hledat (nepouzivam to porad, ale obcas se hodi neco vyhledat, treba odkaz, nebo nejake dulezite udaje)
Asi mas pravdu. Prusvih je, ze dneska stale vetsina lidi nema vlastni domenu a pod pojmem email pro ne je neco ve tvaru fanda@seznam-cz.Tedy spoléhá na to, že ten seznamácký e-mail je fajn. Podle mě tohle bude platit, dokud budou uživatelé primárně pod palcem firem. Byly doby, kdy se i mezi běžnými uživateli skupiny lidí nabalovaly na někoho, kdo pro ně vybudoval nějaké technické zázemí, je otázka, jestli se ty doby ještě někdy vrátí ;).
A zavadet neco, jako virtualni identitu, jeste navic treba potuplovanou nejakym certifikat, toho se zase bojim ja.Otázkou není, zda budeš mít virtuální identitu, ale kolik jich budeš mít a jaké to budou. Pseudonymita je stejně dobře možná s jakoukoli doménou, která ti ty služby poskytne a přitom na tebe nebude zbytečně moc vyzrazovat.
Tak mne napada, proc by to defakto nemohlo frcet na klasickem emailu?Nemůže, protože klasický e-mail ktomu neposkytuje prostředky. To už je jednodušší integrovat e-mail do jabberu než jabber do e-mailu.
Vzdyt imap je superIMAP je špatný protokol dokonce i pro ten účel, pro který se už teď používá. Nezvládá ani tak základní věc jako je odeslání zprávy (zato SMTP je na to dost nevhodné), zato jiné věci dělá značně komplikovaným způsobem.
jen by ho to chtelo upravit tak, aby komunikace fungovala trochu vice realtime.To je jako upravit chatku na palác. Teoreticky to samozřejmě jde, ale nejjednodušší je chatku (IMAP) odstranit, aby nepřekážela nebo ji ideálně vůbec nedovézt.
No reknete, neni to lepsi, nez stavet nejaky dalsi protokol?Není. Pokud už bych si vybíral pro IM stávající protokol, byl by to SIP a nikoliv IMAP.
Navic, ten, kdo nema zadneho klienta, tomu by prisla moje IM zprava klasicky do emailu - bylo by to absolutne multiplatformni.To ale vůbec nezávisí na použitém protokolu, nýbrž na použitém software a jeho návrhu. Transformovat instantní zprávy na trvalé zprávy rovnocenné s poštou má své výhody i nevýhody.
SERVERY - kazdy si muze vybrat, zda pouzije hostovany server, nebo vlastni.To platí i pro jabber a SIP (alespoň technicky) a je to obecnou vlastnostní otevřených decentralizovaných protokolů.
Lze aplikovat sifrovani,Šifrování je pouze nástroj, nikoli cíl. Požadavky pro IM a poštu nemusí být (a nejsou) vždy stejné.
zasilat prilohyZasílání příloh je čistě věcí formátu zprávy, který nemusí být vůbec závislý na přenosovém protokolu, nedělá to tedy ani IMAP ani SMTP.
vsechno je uz definovane, hotove a funkcni.Teď tu o karkulce. Vždyť ani ten e-mail nefugnuje nijak zázračně, natož aby člověk lusknul prstem a samo se to transformovalo na instant messaging.
Defakto by se IM zpravy od tech klasickych mohly lisit jen nejakym autorizacnim retezcem v predmetu emailu.Fuj.
To by mohlo resit i problem se spamemAutentizovaný e-mail by problém spamu teoreticky řešil, ale je dobré se zamyslet nad tím, proč to není uvedeno do praxe.
aby clovek dle sveho verejneho certifikatu dokazal podepsat svoji IM zpravuPKI je super, když jsou lidi ochotní se o něj starat a používat ho.
A ted mi reknete, jake ma tohle reseni problemHlavní problém tohoto řešení je, že není ani naimplementované ani vyspecifikované a jako bonus vypadá, že by bylo podstatně horší než jsou existující řešení, a to ve všech možných ohledech, které mě napadají. Je to něco jako kdybych přišel s tím, že ta chajda už je vlastně skoro palác, stačí ji trochu obestavět.
Misto pouzivani nejakych debilit tapy facebook, gtalk, whatsapp, viber a jinych.Další věc je, že zmíněné debility jsou stavěné za účelem, aby je lidé používali, nikoliv za účelem splnění mokrého snu o instant messagingu po IMAPu.
Takze defakto z xmpp udelame ruznymi xepy ten email, ze?
1) jake prostredky email neposkytuje, aby se dal vyuzit k IM?
2) to ze je email spatny je tvuj nazor, neznam cloveka, ktery by ho nepouzival a ztrata zprav je vyjimkou. Naproti tomu, znam jen velice malo lidi, kteri pouzivaji XMPP.
3) To neni upravovat chatku na palac, ale pridat na schranku, kterou uz ma kazdy na plote jenom druhou jmenovku.
4) kdo ma nejaky SIP ucet? z beznych lidi - nebavime se o proficich. S profiky muzu komunikovat libovolnym zpusobem, ja chci komunikovat se vsemi
5) zasilani priloh v emailu roky funguje. Na jabberu se mi to nepovedlo se zadnym klientem - kdyz to musim konfigurovat = stoji to za ho... - nastavi to zase jen profik, takze lame budu posilat prilohy zase emailem
Vubec nevim, co bys na tom chtel specifikovat, krome toho, ze predmet emailu pro IM je treba : IMMESSAGE
Zbytek uz je jenom o tom, vytvorit klienta s odpovidajicim UI, nebo tuhle funkci doplnit do soucasnych Email klientu - moznost otevrit chatovaci okno a nastavit si jine upozorneni pro IM zpravy.
Takze defakto z xmpp udelame ruznymi xepy ten email, ze?Je možné nad XMPP postavit e-mailovou službu, navíc XMPP poskytuje metody ověření odesilatele, které by se e-mailu docela hodily, ale v diskuzi o instant messagingu je to irelevantní.
1) jake prostredky email neposkytuje, aby se dal vyuzit k IM?Jaké zázračné prostředky e-mail (tedy IMAP, SMTP, MIME) poskytuje, které nejsou už zakotveny v obecnějších protokolech?
2) to ze je email spatny je tvuj nazor, neznam cloveka, ktery by ho nepouzival a ztrata zprav je vyjimkou. Naproti tomu, znam jen velice malo lidi, kteri pouzivaji XMPP.Když něco nepochopím, tak se zeptám. Nepsal jsem nic o tom, kolik lidí co používá, lidé teď stejně nejvíc komunikují přes Facebook :).
5) zasilani priloh v emailu roky funguje. Na jabberu se mi to nepovedlo se zadnym klientemImplementace příloh je triviální, ale zcela logicky navyšuje velikost zprávy o velikost přílohy. To není problém u triviálního protokolu pro předání zprávy serveru jako je SMTP, kde se prostě nastaví limit dostatečný pro přílohy, které očekávám. Instant messaging běžně pracuje jinak a limit na zprávy mívá podstatně nižší, aby se neblokoval kanál. Celkově je běžný jabber software navržený s ohledem na to, aby byl server ušetřen manipulace s velkými daty, ale není to podmínkou. Z toho taky vychází požadavek na přímé předávání velkých dat, které mi přijde jako super nápad, akorát ta implementace se zpoždovala a zpoždovala, škoda.
Vubec nevim, co bys na tom chtel specifikovat, krome toho, ze predmet emailu pro IM je treba : IMMESSAGEPokud mi chceš tvrdit, že když naseru do subjectu do IMMESSAGE, budu mít najednou skvělý instant messaging, tak na to nemám slov.
Zbytek uz je jenom o tom, vytvorit klienta s odpovidajicim UI, nebo tuhle funkci doplnit do soucasnych Email klientu - moznost otevrit chatovaci okno a nastavit si jine upozorneni pro IM zpravy.Jasně, a všecko bude magicky fungovat. Takových teoretiků vizionářů jsem potkal dost, ale jednu věc měli společnou. Jediné, co z nich kdy vypadlo byly kecy.
Je to uplne jednoduche. Kdyz neverim jabberu, jakoze mu uz proste neverim, protoze jsem o hodne zprav pres mobil prisel, tak proste dulezite zpravy si necham poslat SMSkou, nebo na email. Vtip je v tom, ze kdyz si dnes v klientovi nastavim, aby mi oznamoval jen zpravy s predmetem IMMESSAGE, tak mam defakto fungujici IM system.
Vis, ja jsem zase ve svem zivote potkal spousty lidi, kteri zili ve svych snech o idealnim svete. Vsichni meli jedno spolecne - presne vedeli, jak to ma fungovat, aby to bylo SUPER. Vetsina z nich to dokonce vyrobila. Ale nikdo krome jich samotnych to nepouzival. Vis proc? Protoze lidi chteji jednoduche a funkcni veci a hlavne, nechteji na ne cekat rok, dva nebo pet. Chteji je hned.
To, co tady popisujes ty je beh na dlouhou trat. Navic je to neco, co musis lidem vysvetlit a naucit je pouzivat. Email pouzivaji vsichni. Kdyz to uplne zjednodusim, tak mi staci, rict kazdymu, kdo mi chce poslat instantni zpravu . cili zpravu na mobil, nebo klienta kde mne vzdy zastihnou, tak at do predmetu emailu napisou DULEZITE.
Nakrasne mne ted napada, ze by se stejne daly resit i ty pitome transporty. Stacil by k tomu jednoduchy script, ktery by neslouchal na ICQ / jabberu / facebooku a prichozi/odchozi zpravy by lifroval do emailu. Vyhodou je, ze by to behalo i bez SMTP, protoze by stacilo, kdyby to ten IM klient strkal do slozky pro transporty a ten script by si to vybiral a odesilal na ICQ / FB apod.
Ale transporty ser pes. Ja tady resim spise akutni potrebu nahradit SMSky a ICQ necim, na co mu budou moci napsat VSICHNI a pojede to na mobilu, na PC i pres web. Bude to umet historii a nebude to zavisle na serveru zadneho velkeho bratra.
Tohle je mozna lepsi resit s vyvojari konkretnich softu, treba K9 pro android. Protoze je to ciste veci toho softu. Stejne tak by se dal upravit jen nejaky plugin do roundcube + thunderbird a clovek ziska smahem klienty pro vsechny platformy. Staci se jen dohodnout, jak znacit IM zpravy.
Hele, znovu jsem si cetl, co jsi psal. Ja se nechci hadat, ze email je TECHNICKY dobre reseni. Neni, byl proste urceny na neco jineho a jeho protokoly jsou mozna zastarale, ale ohromnou vyhodu - je nezavisly a MASOVE ROZSIRENY.
Vis co je ohromny problem kazdeho reseni ala jabber, irc apod? Ze neexistuje zadny mainstreamovy, masove rozsireny a pouzivany klient. Zakladni predpoklad toho, aby mne lidi mohli kontaktovat je, ze to musi byt pro ne snadno proveditelne. Jsou lidi, kterym stoji za to, si instalovat jakykoliv soft, ale pak jsou lidi, kteri mi chteji jednou za rok neco sdelit a sami pouzivaji facebook / Google hangouts. Takove neprinutim si neco instalovat. Proste mi poslou email, ktery treba prave nesleduju, protoze to pro mne neni IM kanal.
Jabber se mi libil, protoze vetsina lidi mela Gtalk a byli tak schopni mi bez problemu psat. Nemusil jsem je nutit nic instalovat. Tohle se stava minulosti a ja proste nechci prechazet na G Hangouts, nebo dokonce facebook. Jasne, muzou mi psat emaily, nebo SMSky, ale to jsme zase u toho.
Takze email ma ohromnou vyhodu v tom, ze KAZDY uz UCET i klienta ma. Takze neni treba nikoho presvedcovat at si neco instaluje, staci mu dat treba adresu ve tvaru hotline@mojedomena.cz a presmerovat si ji na IM - treba jen filtrem.
Ja se nechci hadat, ze email je TECHNICKY dobre reseni.To je taky to jediné, co jsem tím chtěl říct.
Neni, byl proste urceny na neco jineho a jeho protokoly jsou mozna zastarale, ale ohromnou vyhodu - je nezavisly a MASOVE ROZSIRENY.You don't say.
Takove neprinutim si neco instalovat.Stejně jako je nepřinutíš začít používat software nebo nedej bože službu na e-mail s tebou vysněnými IM rozšířeními.
Takze email ma ohromnou vyhodu v tom, ze KAZDY uz UCET i klienta ma.Z hlediska instant messagingu je účet a klient, který instant messaging nepodporuje nulovou hodnotou. Navíc ten účet vůbec není e-mailový, je to jen jméno a heslo, na které lze navázat libovolné služby přes libovolné protokoly.
Navíc ten účet vůbec není e-mailový, je to jen jméno a heslo, na které lze navázat libovolné služby.Pokud mi nějakej debil začne do standardního e-mailu posílat zprávy v kadenci běžné na IM, tak docílí jen toho, že si ho zabokuju. Snad jedině že by se jednalo o účet k tomu určený jako jsou třeba konvergované zprávy na Facebooku. Kritizuješ můj technický vhled bez pádných technických argumentů a přitom zjevně ignoruješ uživatelskou stránku celé věci. Epic fail.
To vypadá dost dobře. To by mi mohlo řešit náhradu spojení s lidmi co jsou na androidu ale používají Hangouts.
Mimochodem, docela dobrý nápad, filtrovat hlavičku a přijímat tedy jako IM zprávy podle toho, zda je odesílatelem taky daný SW.
To ano, ale uz nyni ma spousta klientu implementovanou funkci notifikace doruceni/precteni zpravy. Cili by stacilo ji jen vyuzit. Pak jasne vidim, ze adresat zpravu cetl / pripadne adresat nemusi tohle potvrdit a muze hrat mrtveho brouka (kazdy nepotrebuje byt vzdycky zastizitelny)
Pokud email spadne do spamu, nebo je nejaky problem s prijemcem, pak vetsina serveru zasle zpet zpravu, kterou by klient zobrazil a ktera je uz notoricky znama.
Ale jinak jo, je to docela vecna pripominka, muze se stat, ze email bude "spolehlivy" stejne, jako ten jabber. Ovsem jeho spolehlivost nezavisi na kvalite spojeni klienta do internetu, ktera v pripade mobilniho pripojeni je dost chaba. Takze proto jsou problemy s dorucovanim emailu spise vyjimkou, kdezto na jabberu jsem mel pri prechazeni 3G/wifi problemy se ztracenim zprav neustale.
Že to funguje celkem spolehlivě je malý zázrak.Větší zázrak je vysvětlovat to lidem, když zjistí, že to spolehlivě nefunguje.
Ehm ... ani nahodou, pokud mas internet (a ne nejakou zNATovanou srajdu) tak se klidenti bavi naprimo.Můžou se bavit napřímo a dokonce se můžou bavit napřímo i přes NAT, ale nejsem si vědom toho, že by to byl běžný default. Což samozřejmě nemění nic na tom, že to, na co reaguješ je v tomto ohledu mimo, protože to jabber skutečně umožňuje a dokonce i s tím NATem.
Jeste mi vysvetli, k cemu je to dobre, ze se muze bavit naprimo, kdyz spojeni spolu navazuji pres server? Odpovim si sam : k tomu, aby se nedalo rozumne na serveru implementovat ukladani zprav a historie. Rozumim tomu u SIPu a jinych, kde se prenasi velke objemy dat, ale IM, kde je zatizeni serveru uplne minimalni? Je to blbina.
Souhlasim. A to s tou prioritou, starym chat oknem a moznosti rozpadu spojeni, kdy se mezitim zpravy doruci na jineho - Treba i away klienta, napr. v kancelari cini z jabberu komunikacni nastroj k prdu.
Pokud ocekavam DULEZITOU zpravu, treba ze mam nekam jet, nebo ze se nekam nejede, tak se klidne muze stat, ze tu zpravu nedostanu - a nejhorsi na tom je, ze to nezjistim (treba gtalk mi ukaze, ze jsem offline, takze vim, ze mam problem s komunikaci. Ve chvili, kdy se dostanu online, mi naskoci stare zpravy, takze VIM, ze mi nikdo mezitim nepsal - mohu se na to ABSOLUTNE SPOLEHNOUT - to je to, co na jabberu TRAGICKY CHYBI.)
Porad se tady bavime o xepech, protokolu, technickem reseni IM, atd. Ale unikla mi odpoved diskutujicich na jedny ze zakladnich otazek. Kdybyste mi na ne odpovedeli, byl bych rad a cenil si toho. Kazdy clovek totiz IM pouziva jinak a ma od nej jine ocekavani a naroky. Proto k vzajemnemu porozumeni je dulezite, abychom vedeli, co kdo od IM ocekava.
1) Vam pripada Jabber jako spolehlivy IM?
2) nevadi vam, ze se mohou zpravy tvarit jako dorucene, odesilatel si mysli, ze jste je dostali a vy nic nevite?
4) nevadi Vam, ze kdyz si s nekym pisete pres pocitac, nemate sanci z jineho pocitace vyhledat historii?
5) skutecne byste dokazali naucit pouzivat jabber treba svou babicku, nebo nejakou pipinu na diskotece? Ted nechejme stranou, ze zadne pipiny na diskotece kontaktovat nepotrebujete a babicka uz nezije. Chci tim rict, zda si skutecne myslite, ze je jabber a jeho klienti tak, jak je dneska, vhodny pro absolutni PC analfabety, kteri umi pracovat s emailem a facebookem, cili Vam to umozni byt v kontaktu s lidmi, kteri dosud pouzivaji jen email + fb?
6) kdybyste potkali cloveka, treba spoluzaka ze studii, ale nechteli byste mu davat mobilni cislo, protoze mobil na volani nepouzivate. Dali byste mu jako kontakt na sebe jabber, nebo email? A proc?
1) Vam pripada Jabber jako spolehlivy IM?Nejednoznačná otázka. Software, který neimplementuje hop-to-hop ACKs ani nepoužívá ten trik s TCP je v principu nespolehlivý. Nicméně vzhledem k tomu, že lidé používali ICQ a SMS a dnes používají Facebooḱ, tak spolehlivost pro většinu zjevně nepatří mezi klíčové vlastnosti.
2) nevadi vam, ze se mohou zpravy tvarit jako dorucene, odesilatel si mysli, ze jste je dostali a vy nic nevite?Někdy vadí, někdy nevadí. Trpí tím většina technologií, které používám, od SMS přes IM až po e-mail, a u některých lidí to ani sebespolehlivější technologie nezachrání, takže jsem zvyklý se podle toho chovat.
4) nevadi Vam, ze kdyz si s nekym pisete pres pocitac, nemate sanci z jineho pocitace vyhledat historii?Nevadí, nedělám to.
5) skutecne byste dokazali naucit pouzivat jabber treba svou babickuMojí ne, ale to je trochu jiná story. Babičku, která je ve formě a schopná zvládnout základy používání PC samozřejmě ano.
nebo nejakou pipinu na diskoteceKdyž zvládla ovládat smartphone, zvládne všechno, ale nejspíš nebude chtít, má už fejs.
Chci tim rict, zda si skutecne myslite, ze je jabber a jeho klienti tak, jak je dneska, vhodny pro absolutni PC analfabetyNejsložitější je pro ně všimnout si notifikace o žádnosti o autorizaci. Jakmile se jim podaří zobrazit žádost, odkliknout ji už zvládnou a zbytek nevyžaduje víc znalostí než psaní.
kteri umi pracovat s emailem a facebookemPokud někdo zvládne webmail a facebook, zvládne i jiná ekvivalentní uživatelská rozhraní, pokud chce.
6) kdybyste potkali cloveka, treba spoluzaka ze studii, ale nechteli byste mu davat mobilni cislo, protoze mobil na volani nepouzivate. Dali byste mu jako kontakt na sebe jabber, nebo email? A proc?Mobil na volání používám, a používám ho i na SMS. Pro mě by byl na prvním místě vzhledem k rozšířenosti a dostupnosti, na druhém elektronická pošta vzhledem k rozšířenosti a pohodlnějšímu psaní delších textů, jabber pokud by to byl člověk z oboru. Ale ve skutečnosti by se mě na kontakt nikdo neptal a dostal bych zprávu přes Facebook.
Jo, s tim souhlasim. Z takoveho nastroje defakto tvurce nemuze nic mit, pokud nemuze ani smirovat, ani zobrazovat reklamu. Takze ac neznam historii jabberu, myslim, ze je to takove to udelej si sam. To znamena, ze to potrebuju ja, tak si to udelam a kdyz to funguje a jsem dostatecny samaritan, tak to DAM i druhym. Popravde, ja jsem si myslel, ze tady uz nekdo takovy existuje. Ze nejsem jediny, kdo resi takove problemy a ze jsou lidi, kteri k tomu maji odpovidajici znalosti, aby to pro ne nebyl problem na vice, jak par hodin, ktere jim stoji za to, mit kvalitni komunikacni nastroj.
Ja popravde vubec nemuzu pochopit, proc nekdo udelal neco takoveho, jako je jabber (coz muselo samo o sobe dat dost prace) a nedodelal k tomu tech par blbosti navic, aby to fungovalo spolehlive. Ale mozna jo, v te dobe nebyl Gtalk a zrejme nikdo nemel Jabber s cim srovnavat A dnes uz proste lidi radeji pouzivaji ten gtalk, nebo FB, nez aby si upravili jabber do funkcni podoby.
Popravde, ja jsem si myslel, ze tady uz nekdo takovy existuje. Ze nejsem jediny, kdo resi takove problemy a ze jsou lidi, kteri k tomu maji odpovidajici znalosti, aby to pro ne nebyl problem na vice, jak par hodin, ktere jim stoji za to, mit kvalitni komunikacni nastroj.Čistě hypoteticky, jestliže se teď rozhodnu napsat si třeba e-mailového klienta dle vlastních představ nebo IM klienta, když na to přijde, co z toho budu mít? Spoustu práce, která povede k nedokonalému software, které budu muset dále udržovat nebo opustit. Takže to pro mě nedává smysl, pokud se nenajdou další, kteří by se na tom z vlastních důvodů podíleli a pokud možno tomu mohli věnovat vzhledem ke svým individuálním podmínkám třeba i více času.
Ja popravde vubec nemuzu pochopit, proc nekdo udelal neco takoveho, jako je jabber (coz muselo samo o sobe dat dost prace) a nedodelal k tomu tech par blbosti navic, aby to fungovalo spolehlive.A hlavně proč to bylo na vzdory tomu natolik úspěšné, že o jabberu vůbec víš a navíc jsi ochotný se o něm snad i hádat.
A dnes uz proste lidi radeji pouzivaji ten gtalk, nebo FB, nez aby si upravili jabber do funkcni podoby.Facebook, Google Hangouts apod. jsou konzumní služby, jejichž primárním účelem není se předvádět s otevřenou technologií, ke které může každý připojit vlastní doménu. Jsou to takové dvě strany světa, kde na jedné je láska k technologii a otevřenosti, na druhé je chladný komerční kalkul a mezitím se to různě potkává, viz googlí don't be evil.
Sranda je, ze ja bych treba byl ochotny za takove reseni zaplatit.Ale ne dost. A ani bys nebyl ochotný sehnat dostatek lidí, kteří by zaplatili s tebou.
A zase jsme u toho - pokud chci tohle komercne nasadit, pak to musi fungovat a zpravy se musi dorucovat.Což je jak už jsme se tu bavili triviálně implementovatelné, pokud máš pod palcem jak klienta, tak server, nebo dokonce pokud jen klienta, pokud využiješ vlastností Linuxu nebo FreeBSD kernelu na tom web serveru.
Sam mam jabber (i vlastni server), pred par lety na nej preslo nekolik kamaradu (nejsou v IT oboru), cela rodina ho pouziva ke komunikaci a to velice spokojene (vcetne babicky).
Co jsem procital tuhle diskuzi tak jsem si zkousel nektere scenare. Ale obvykle bud na PC jabber vypinam, kdyz prechazim na mobil nebo tak nejak pocitam s tim, ze v mezidobi nez kontaktuji danou osobu z mobilu (proste s ni otevru konverzaci a napisu ji) nebo nez se mi klient na PC prepne do Away tak zpravy mohou dorazit na nej. Jinak to funguje pomerne spolehlive, ale kriticke veci resim pres GSM obvykle volanim, protoze SMS jsou snad jeste mene spolehlive nez ten jabber
Takže jsme skončili na tom, že Jabber prostě nevydělává a nestojí za ním žádná komerční entita.To ani tak ne, spíš že není komerční či nekomerční entita schopná většího vývoje, která by měla eminentní zájem na zlepšení těch věcí, o kterých jsme se bavili a to pokud možno napříč alespoň open source implementacemi. Nehledě na to, že se většině tradičních open sourcařů při pohledu na XML transport udělá špatně.
V době kdy přišel už SIP sice nějakou dobu existoval (cca 8 let), ale ještě se pořádně nerozšířil.Tedy to bylo vymýšlení ptákovin, z technologického pohledu.
Tiskni
Sdílej: