Alternativa Skype?

27.5.2011 11:30 | Přečteno: 3664× | Linux | poslední úprava: 27.5.2011 11:34

Tak jsem narazil na nový a zajímavé se rozvíjející program - Jitsi a vypadá to, že se konečně objevuje alternativa ke Skypu.

Navíc to v sobě integruje všechno co se dá od ICQ, přes Jabber a Google Talk a navíc to umí i videohovory(přes SIP). Je sice ještě v rannějším stádiu, ale vypadá to, že z toho může vzniknout zajímavý program.

Jako bonus lze brát, že je napsaný v Javě, takže je multiplatformní.

       

Komentáře

[dopisovatel]

Java není výhra.

[rADOn]

Jako bonus lze brát, že je napsaný v Javě, takže je multiplatformní.

Bonus? Spíš veliké mínus.

[DjAARA]

Z toho vyrosteš. Jednou přestaneš reagovat na jednotlivá klíčová slova a budeš software vnímat jako celek a budeš spíš zkoumat zda ti poskytne to co požaduješ. Pak ti klíčové slovo Java možná bude stále vadit, ale protože celek pokrývá tvoje potřeby, budeš ho klidně používat.

[Hovadko]

No mně zrovna Java vadí, protože je dooost pomalá. Používám poměrně obstarožní hardware, ale nemám potřebu ho měnit. Proto mi cokoliv napsanýho v Javě dost vadí.

[pavlix]

Já to na Linuxu vidím na vylepšování Telepathy. Z hlediska VoIP je také v raném stádiu jako Jitsi, ale celkově má v linuxovém ekosystému větší smysl.

Jitsi bych viděl jako výbornou multiplatformní aplikaci, tedy aplikaci pro Windowsáky, kterou si můžu pustit na Linuxu, abych jim mohl po telefonu radit kde co je.

Přecijen se psalo o alternativně Skype, ne o skvělém, čistém a rychlém VoIP řešení. A pro nás od OSS je důležité, aby taková alternativa uměla komunikovat po standardních protokolech SIP a XMPP.

[rADOn]

Z toho vyrosteš. Jednou přestaneš mít čas zkoušet každou kravinu a budeš software vnímat jako součást většího celku a spíš zkoumat zda do toho celku přidá to co potřebuješ. Pak ti klíčové slovo gnome prozradí, že to nebude zapadat do KDEčkového desktopu, klíčové slovo pulse ti řekne, že bez zvukového démona to nepoběží, klíčové slovo 32bitů upozorní že budeš možná potřebovat emulační knihovny, klíčové slovo "komerční" ubezpečí že balíčkování bude nějaký hnusný bastl… a klíčové slovo Java napoví, že to bude žrát gigabajt paměti, bude to pomalý, hnusný a vůbec to do prostředí to zapadne asi jako cihla do okna. Je to smutné, ale desktopové aplikace v javě se u mě prostě takhle chovají.

[Bedňa]

Pred každou aplikáciou čo sa začína na J si dávam majzla. Nechová sa to tak len u teba.

[Chytrex]

asi tak nějak

[Migi]

pod to sa podepíšem

[kralyk z abclinuxu]

+1

[pasmen]

Jednou přestaneš mít čas zkoušet každou kravinu a budeš software vnímat jako součást většího celku a spíš zkoumat zda do toho celku přidá to co potřebuješ.

Tohle mi moc není jasné. Taky poslední dobou nemám čas si hrát a zkoušet kde co, hledám software, který udělá práci kterou potřebuju. Potud tedy souhlas. Pak ni ale nějak nesedí ten výrok o integraci do desktopového prostředí. Pokud potřebuju s něčím pracovat, pak je mi u zadku, jestli to zapadá do mého ňůňo desktopu ne?

[rADOn]

"Zapadnutím do desktopu" nemyslím vzhled, ale funkčnost. Klávesové zkratky, schránka, nastavení proxy, notifikace událostí, asociace přípon/mime typů na programy, tiskový systém, úložiště hesel… Programy v Javě tohle všechno ignorují do té míry, že jsou prakticky nepoužitelné.

Například se mi moc líbil databázový klient SquirrelSQL kvůli chytrému doplňování. Hesla v plaintextu bych skousnul, klávesy bych si nastavil, ale psát SQL bez funkčního clipboardu prostě nejde.

[Der Teufel]

A využití virtuálních filesystémů. K čemu mi je aplikace v javě, když s ní nemůžu editovat soubor přes SFTP?

[moira]

Jak to myslíš? Java aplikace přece přistupuje k FS jako jakýkoliv jiný proces.

[Marián Kyral]

Jak to myslíš? Java aplikace přece přistupuje k FS jako jakýkoliv jiný proces.

KIO.

[moira]

Aha, ale to můžeš říct o každé neKDE aplikaci.

[Marián Kyral]

Aha, ale to můžeš říct o každé neKDE aplikaci.

Můžu. Proto se taky snažím neKDE aplikace nepoužívat.

[kralyk z abclinuxu]

No tak to si budeš muset počkat na KDE klienta. Imho pokud se bavíme o alternativách Skypu, je důležitý především design toho síťového protokolu než konkrétní implementace. Pokud by tahle VOIP síť získala na popularitě, určitě by někdo napsal non-Java klienta.

Nadruhou stranu uznávám, že existence implementace pouze v Javě může na tý popularitě ubrat...

Sečteno podtrženo; má-li být Skajp nahrazen něčím rozumnějším, bylo by fajn místo nějakýho konkrétního prográmku napsat otevřený a hlavně dobře vymyšlený standard. Konkrétní implementace si pak už lidi napíšou, KDEčkaři v KDE, Javaři v Javě a .NETisti v .NETu.
Podobně jako to bylo se XMPP/Jabber.

[pavlix]

Imho pokud se bavíme o alternativách Skypu, je důležitý především design toho síťového protokolu než konkrétní implementace.

Mimo to je důležitá podpora rozšířených standardizovaných protokolů (dnes hlavně SIP a XMPP), a hlavně dobrá integrace do Windows.

Sečteno podtrženo; má-li být Skajp nahrazen něčím rozumnějším, bylo by fajn místo nějakýho konkrétního prográmku napsat otevřený a hlavně dobře vymyšlený standard.

SIP a XMPP. Ty protokoly se do jisté míry doplňují a je co vylepšovat (kodeky, doplňky), ale protokoly jako takové jsou velmi dobré a pokrývají VoIP, IM i pokročilejší věci jako RPC.

Podobně jako to bylo se XMPP/Jabber.

Jitsi podporuje jak XMPP, tak SIP.

[pavlix]

Aha, ale to můžeš říct o každé neKDE aplikaci.

GIO/GVFS

[qiRzT]

Nebo sshfs.

[moira]

sshfs? v čem by měl být se sshfs problém?

[qiRzT]

Asi jsem to nepochopil, myslel jsem že KIO má řešit pro ten javový editor přístup k souborům přes sftp. To dělá sshfs.

[moira]

Já zase myslel, že tvrdíš, že sshfs nefunguje stejně jako KIO, tak nic no

[Petr Tomášek]

gvfs to umí taky, takže není žádný důvod používat KDE sračky

[rADOn]

Velká desktopová prostředí mají vlastní virtuální filesystémy – v podstatě jen knihovny s jednotným API. Ale protože je to napojené na desktop, aplikace se nemusí zatěžovat nastavováním. Pokud otevřu soubor přes http, nemusí řešit proxy, kódování etc. Pokud stejný soubor přes ssh nebo sftp, desktop se zeptá na heslo nebo ho vytáhne ze zašifrované peněženky, et cetera et cetera. Pokud je to "jenom" pohodlnější, vem to čert, ale šifrované ukládání hesel mi přijde jako celkem zásadní výhoda.

Java? Pro začátek by stačilo kdyby file dialog nevypadal jako něco co sem propadlo červí dírou z minulého století

[Marián Kyral]

Java? Pro začátek by stačilo kdyby file dialog nevypadal jako něco co sem propadlo červí dírou z minulého století

Přesně. Právě jsem to tu chtěl zmínit. Obecně, jakýkoli jiný souborový dialog než ten z KDE mi přijde strašně omezující.

[Petr Tomášek]

No mě zase přijde KDE filedialog jako strašně nepřehledný a špatně použitelný...

[Marián Kyral]

Každý na to má svůj pohled. Proto taky používám KDE a ne Gnome. To jsem zkoušel několikrát a nikdy a vždy jsem se jen utvrdil v tom, že to není nic pro mně.

[xkucf03]

Proč by nemohla?

Jedna stará dobrá poučka říká, že každý program by měl dělat jednu věc a měl by ji dělat dobře. O přístup k souborům (i těm vzdáleným) by se měl starat souborový systém (např. sshfs v tomto případě) a o editaci by se měl starat editor.

[pavlix]

Jedna stará dobrá poučka říká, že každý program by měl dělat jednu věc a měl by ji dělat dobře. O přístup k souborům (i těm vzdáleným) by se měl starat souborový systém (např. sshfs v tomto případě) a o editaci by se měl star

Správně by se pro přístupy ke vzdáleným souborům měla používat systémová služba nebo jádro. Nejlépe s jednotným interface. SSHFS je služba na trošku jiné, spíše statické úrovni, vítal bych přístup pomocí URI bez nutnosti mountovat.

[moira]

"Zapadnutím do desktopu" nemyslím vzhled, ale funkčnost. Klávesové zkratky, schránka, nastavení proxy, notifikace událostí, asociace přípon/mime typů na programy, tiskový systém, úložiště hesel… Programy v Javě tohle všechno ignorují do té míry, že jsou prakticky nepoužitelné.

To není špatná myšlenka na vznik knihovny, která by byla schopna integrovat tyto věci (jestli tedy už taková stejně není). Ale taky to chování je dáno použitým prostředím, např. já se svým fluxboxem nemám ani "desktopové" nastavení proxy, asociaci přípon, ani notifikátor událostí, natož úložiště hesel. A pokud se na to někdo bude spoléhat, tak docela omezí nezávislost aplikace na prostředí.

Co se clipboardu týče, já s ním ve Squirrel žádný problém nemám, ostatně Java používá normálně clipboard daného prostředí, ve kterém běží. Ale s clipboardem mám občas taky problémy. Někdy mám pocit, že v X window jsou dvě schránky (jen pocit, nemám to ničím podložené ) - jedna pro data vložená přes Ctrl+C a druhá přes myš. A dost často se mi stane, že to co vložím do schránky v aplikaci A přes myš, nejde v aplikaci B klávesnicí vyndat a opačně. Někdy nefunguje např. vložení přes Ctrl+C ale myší ano nebo naopak. Tak si jen říkám, jestli ten problém se Squirrel nebyl podobného ražení (?).

[Marián Kyral]

Co se clipboardu týče, já s ním ve Squirrel žádný problém nemám, ostatně Java používá normálně clipboard daného prostředí, ve kterém běží. Ale s clipboardem mám občas taky problémy. Někdy mám pocit, že v X window jsou dvě schránky (jen pocit, nemám to ničím podložené ) - jedna pro data vložená přes Ctrl+C a druhá přes myš. A dost často se mi stane, že to co vložím do schránky v aplikaci A přes myš, nejde v aplikaci B klávesnicí vyndat a opačně. Někdy nefunguje např. vložení přes Ctrl+C ale myší ano nebo naopak. Tak si jen říkám, jestli ten problém se Squirrel nebyl podobného ražení (?).

To není pocit, ono to tak skutečně je. Ale některá prostředí/aplikace pro práci se schránkou se to snaží zamaskovat.

[Marián Kyral]

Našel jsem pěkný popis od Luboše.

[moira]

Díky!

[Marián Kyral]

Není zač

[kralyk z abclinuxu]

Tohle se dá docela pěkně vyzkoušet v shellu utilitkou xsel.
xsel -p|-s|-b odpovídá schránkám primární | sekundární | clipboard, xsel buď vypíše obsah schránky na stdout, nebo zapíše do schránky, co přijde na stdin. Takže např. ls | xsel -b zapíše do clipboardu seznam souborů v aktuálním adresáři.

[rADOn]

To není špatná myšlenka na vznik knihovny, která by byla schopna integrovat tyto věci (jestli tedy už taková stejně není).

Taková knihovna je právě desktopové prostředí Z pohledu uživatele jsou KDEčka ikonky a barvičky, ale z pohledu vývojáře je to hromada knihoven které poskytují API k různým věcem. Záleží jen na hloubce a rozmanitosti, holé X mají "sjednocenou" snad jen správu oken, barvy a myší clipboard. Ve fluxboxu určitě máš aspoň sjednocené menu aplikací (z .desktop konfiguráků někde v /usr/share) a systray. Java nepobírá ani ty barvičky a clipboard, to i třicet let staré aplikace v atheně jsou chytřejší. Aplikace z toho neviním, tohle nejsou věci který by se měly psát pokaždé znova. Pokud má být Java skutečně multiplatformní, měly by tyhle věci být součástí standartní knihovny.

Co se clipboardu týče, já s ním ve Squirrel žádný problém nemám, ostatně Java používá normálně clipboard daného prostředí, ve kterém běží. Ale s clipboardem mám občas taky problémy. Někdy mám pocit, že v X window jsou dvě schránky (jen pocit, nemám to ničím podložené ) - jedna pro data vložená přes Ctrl+C a druhá přes myš. A dost často se mi stane, že to co vložím do schránky v aplikaci A přes myš, nejde v aplikaci B klávesnicí vyndat a opačně. Někdy nefunguje např. vložení přes Ctrl+C ale myší ano nebo naopak. Tak si jen říkám, jestli ten problém se Squirrel nebyl podobného ražení (?).

Jo tak nějak se to chovalo. A jelikož to byl problém pouze s veverkou a zároveň to byla toho času jediná java aplikace, byl viník jasný.

[Kvakor]

Záleží jen na hloubce a rozmanitosti, holé X mají "sjednocenou" snad jen správu oken, barvy a myší clipboard.

Správa oken už je mimo Xka, to má na starost window manager.

[pavlix]

To už je ale chytání za slovíčka... ona správa oken má různé úrovně.

[Let_Me_Be]

Hehe, prave proto pouzivam par javovych programu, ale uprimne, kdybych je mel za co vymenit (treba i za neco mnohem mene funkcni) tak by leteli z disku okamzite. Javove programy (specificky pod Linuxem) jsou to naprosto nejhorsi kategorie desktopovych aplikaci.

Navic ted kdyz to prebral Oracle jim kazda druha verze blbe kompiluje, takze musim vypinat JIT, jinak ty aplikace hazou po par vterinach SIGSEGV.

[Ladicek]

Navic ted kdyz to prebral Oracle jim kazda druha verze blbe kompiluje, takze musim vypinat JIT, jinak ty aplikace hazou po par vterinach SIGSEGV.

Já jsem narazil jenom na tohle (od JVM verze 20, tedy Sun JDK 1.6.0_25, u OpenJDK přesnou verzi nevím), a jak tam píšu, stačilo mi vynutit server compiler (-server).

[Pindal]

Alternativa? To jakože, dva lidi za různým NATem si to stáhnou, napíšou nick a mail do registrace a hned si spolu volají? Hm, to asi ne co.

[filbar]

Nějaký obecný SIP server tam je, takže si myslím, že by to teoreticky mělo jít.

[Mandarinka]

Tak, NAT nebo smrt. Geekové možná tu potřebu nevidí, ale díru do světa bez toho alternativa neudělá, imho.

[Petr Tomášek]

Empathy mi bezproblmově funguje, i když jsou obě strany za NATem. Stejně tak Empathy ←→ Psi.

[Mandarinka]

I bez otevřených portů?

[pavlix]

Mám za to, že ano, ale u nás se používají veřejné adresy.

Pokud ne, tak hlaš bug a pošli odkaz.

[Petr Tomášek]

Jasně (pokud jsou „otevřenými porty“ míněny porty „zvenčí dovnitř“ ). Empathy používá několik metod pro obejití NATu (NAT traversal).

[Mandarinka]

Já tohle znám spís z torrentů :) kde když člověk nemá adresu nebo nastavený port forward, tak se nepřipojí k stejně postiženým, ale jen k těm, kteří to sami otevřené/veřejné mají. IIRC to skype ochcává tak, že provoz takových jako jsme my posílá přes ty intalace, které veřejnou ip/p.f. mají - nebo přes ně minimálně spojení inicijuje (jsetli je to možné, nevím).

[Petr Tomášek]

No, NAT traversal je ještě něco kapánek jiného. Viz tenhle článek na rootu. Pochopitelně dnes se používají sofistikovanější (a standardizované) metody, především ICE, která kombinuje STUN (NAT traversal za pomocí externího serveru, který hlásí vnější IP adresy) a TURN (propojení přes externí proxy server). Pochopitelně, pokud mají strany veřejné adresy, nebo jsou schovány za stejným NATem, tak komunikují přímo. Tohle všechno ICE řeší tím, že si nejdřív „ošahá“ různé možnosti a použije tu optimální...

[pavlix]

Já tohle znám spís z torrentů :)

Zřejmě zatím znáš málo, to není nic ve zlém.

IIRC to skype ochcává tak, že provoz takových jako jsme my posílá přes ty intalace, které veřejnou ip/p.f. mají - nebo přes ně minimálně spojení inicijuje (jsetli je to možné, nevím).

U protokolů SIP a XMPP se dá použít ICE, IETF standard pro navazování komunikace mezi stroji za NATem. Prvně se zkouší prokousání UDP tunelu za domluvy a otestování NATu pomocí vnějšího serveru. Pro případ nouze se používá relay, ale pravda, tu musí někdo poskytnout.

[pavlix]

Geekové možná tu potřebu nevidí, ale díru do světa bez toho alternativa neudělá, imho.

Geekové tu potřebu řešit nemusí, protože se:

a) Zbaví NATu (k čemuž v brzké době stejně dojde)

b) Použijí program, který zvládá komunikovat po UDP i přes NAT

[pavlix]

Alternativa? To jakože, dva lidi za různým NATem si to stáhnou, napíšou nick a mail do registrace a hned si spolu volají? Hm, to asi ne co.

To asi ano :).

[pht]

dva lidi za různým NATem si to stáhnou, napíšou nick a mail do registrace a hned si spolu volají?

Jo, takhle to použít jde (mám vyzkoušeno). Tu registraci můžete provést na libovolném jabber serveru, narozdíl od skype. Přes NAT se to dostane pomocí stun.

Jinak hlas/video přes jabber není nic převratně nového, akorát Jitsi je první multiplatformní klient, který to má všechno naimplementované.

[pavlix]

Jinak hlas/video přes jabber není nic převratně nového, akorát Jitsi je první multiplatformní klient, který to má všechno naimplementované.

A to je na tom celkem převratné a nové :), že už to bude pořádně fungovat i na Windows klientovi.

[Pavel Vymetálek]

Taky jste si všimli, že má od včerejška skype zase nějaký problém? Nešel vůbec spustit, padal na segfault a ve windows to samé v bledě modrém...

Žádné bližší info jsem však nenašel...

[DjAARA]

Pomůže rm ~/.Skype/shared.xml. Na Windows obdobně.

[DjAARA]

zdroj

[Pavel Vymetálek]

Díky, asi neumím hledat. Snad to ve Win kolegovi pomůže. Na Fedoře se to vzpamatovalo do druhého dne "samo"

[Dalibor Smolík]

Já jsem zkoušel Gizmo, ale nějak mi to k srdci nepřirostlo.

[PMD]

Fungovalo, byla to dobrá alternativa, ale pak to koupil a zabil Google. Že to zaintegroval do gmailu, je mi prd platný a gtalk je jen pro windows. Tak zas nic, no... Google, fakt dík.

[Chytrex]

jak bys mi to z hlavy přečetl.. Svého času byl gizmo dokonce lepší než skype co se týče kvality přenosu.

[pavlix]

Fungovalo, byla to dobrá alternativa, ale pak to koupil a zabil Google. Že to zaintegroval do gmailu, je mi prd platný a gtalk je jen pro windows. Tak zas nic, no... Google, fakt dík.

Empathy/Telepathy zase funguje na linuxových distribucích :).

[Dalibor Smolík]

Nojo, ono je potřeba aby člověk snadno komunikoval s lidmi jak na Linuxu, tak na Windows ..

[pavlix]

Proto Jitsi.

[Petr Tomášek]

Fígl je v tom, že GTalk, Empathy/Telepathy i Psi fungují (měly by, vyzkoušené mám jen dva posledně jmenované programy) mezi sebou...

Takže na linuxu dáš Empathy, na Widlích psi, nebo GTalk a vesele komunikuješ...

[pavlix]

Ještě by do budoucna bylo potřeba, aby Google konečně přešel na standardní Jingle. A samozřejmě SIP, ale ten už možná jako alternativní připojovací metodu podporuje.

[Bedňa]

Nechcem ti kaziť radosť, ale jabber clienti vedia bežne videohovory. Čo vie ICQ, to asi ani nechcem vedieť.

[Petr Tomášek]

V čem by to mělo být lepší, než třeba Empathy, nebo Psi?

[pavlix]

V čem by to mělo být lepší, než třeba Empathy, nebo Psi?

Než Empathy v tom, že to běhá na Windows, než Psi v tom, že to umí videohovory na Windows. A uznej, že to je docela zásadní pro prosazení protokolů SIP a XMPP pro běžné použití.

[Petr Tomášek]

V čem by to mělo být lepší, než třeba Empathy, nebo Psi?

Než Empathy v tom, že to běhá na Windows, než Psi v tom, že to umí videohovory na Windows. A uznej, že to je docela zásadní pro prosazení protokolů SIP a XMPP pro běžné použití.

Popravdě, ty znáš někoho, kdo by prováděl videohovory? Jo, možná že je Psi ještě v tuto chvíli neumí, ale nepřijde mi to jako taková zásadní killer-feature... (podivej se na videohovory v UMTS, taky to skoro nikdo nepoužívá, hlas je zásadní...)

[pavlix]

Popravdě, ty znáš někoho, kdo by prováděl videohovory?

Minimálně znám sebe a lidi, se kterými ty videohovory vedu.

Jo, možná že je Psi ještě v tuto chvíli neumí, ale nepřijde mi to jako taková zásadní killer-feature...

Mě to přijde jako dostatečně důležitá vlastnost pro výběr programu, to zaprvé.

Připomínám, že ses ptal v čem je Jitsi lepší než Empathy a Psi. Já ti jenom odpovídám :).

(podivej se na videohovory v UMTS, taky to skoro nikdo nepoužívá, hlas je zásadní...)

Po UMTS videohovory nevedu a ani k tomu nevidím důvod. Po XMPP a SIPu na notebooku mi to smysl dává. Když už mi tam tu kamerku dali :).

[kralyk z abclinuxu]

Popravdě, ty znáš někoho, kdo by prováděl videohovory?

Tys nikdy neukazoval nikomu prdel na Skajpu? Ani ti nebyla žádná ukázána?
Ne vážně, znám celkem dost lidí, co to používaj (seriózně)...

[pavlix]

Tak ono se to dá použít i na ukazování ksichtů :).

[brk]

To že to umí hlasovou komunikaci ještě neznamená, že to je alternativa ke Skype. Síla Skype je v tom, že bez krkolomného nastavování funguje takřka všude a teď už i v jeho uživatelské základně.

[pavlix]

Síla Skype je v tom, že bez krkolomného nastavování funguje takřka všude

Pravda, že podpora ICE v klientech SIP a XMPP nepřicházela úplně rychle... co se týká podpory za restriktivním firewallu, komunita jabberu je velice aktivní v pomoci lidem s tunelováním pomocí různých SOCKS proxy, HTTP/BOSH a podobných metod.

Ale nevidím jediný důvod v roce 2011 hořekovat nad tím, že kdysi něco nefungovalo.

a teď už i v jeho uživatelské základně.

Ona ta uživatelská základna není zase až tak stabilní, jak to může na první pohled vypadat. Doporučuju se podívat po okolí, jak u nás dopadlo tradiční ICQ.

Před třema rokama se kdekdo divil, že nemám ICQ a chtěli mi vysvětlit, jak si ho můžu pořídit... dneska po něm pes neštěkne.