Azureus vs. KTorrent (diskuse)

[Michal Karas]

Já jsem dlouho používal Azureus, než jsem nedávno objevil Deluge. Sice nemá (zatím) tolik funkcí jako Azureus, ale svými nároky na hardware tento nedostatek (alespoň u mě) hravě nahrazuje.

[David Watzke]

Už jsem se skoro radoval a on je v Pythonu Ne, ale zkusit bych ho mohl. Takže dík, že ses zmínil, jinak bych na něj asi nepřišel

[Michal Fecko]

Stiahol som si Deluge, a zatial sa sprava celkom fajn, tesim sa na dalsie vlastnosti.

[David Watzke]

No, mně jednou žuchnul při potvrzení konfigurace, ale jinak se to chovalo jak mělo. Jenom je opravdu trochu chudší na vlastnosti. Mohl by se alespoň ptát co za soubory chci stáhnout, než začne, a tak podobně. Dál se mi nelíbí jak zobrazuje průběh. Jako kdyby stahoval z HTTP/FTP :-/

[Pavel Půlpán]

Nevim jak starsi ale verze 0.5.3 uz preselekci souboru umi...

[David Watzke]

Tak zrovna tuhle verzi jsem zkoušel. Teď nevím, asi jsem se teda splet, tak sorry

[Pavel Půlpán]

Jenom je nutna v nastaveni aktivovat, pze defaultne je vypnuta...

[Michal Karas]

Jo, umět by to měl, ale... Když jsem to poprvé zapnul, tak to moc dobře nedopadlo. Deluge hlásil, že stáhl co jsem chtěl, na disku byly ale stažené úplně jiné soubory, které navíc stejně nefungovaly a nepovedlo se mi to už zachránit ani jinými klienty, tak nevím. Ale možná to bylo tím, že už jsem to měl rozestahované, když jsem tu vlastnost zapnul v nastavení. Od té doby jsem to ještě nepotřeboval.

[phero]

Tim chceš říct, že všechno co není v C[++] je podle tebe moc hw naročný/pomalý?

[David Watzke]

Tím chci říct, že nejsem nadšenej z GUI v Pythonu.

[phero]

Proč?

[David Watzke]

No, mám s takovýma programama nevalný zkušenosti. Přijde mi to jen o něco lepší než takovej program v Kommanderu. Je to třeba dobrý na nějakou malou konfigurační ptákovinu, ale dělat v tom takovejhle program, to se mi nezdá... Lepší vysvětlení pro to asi nemám. No a jsem navíc trochu zaujatej proti samotnýmu Pythonu, ale to je jedno

OT.

[Michal Karas]

Já už používám Gajim, takže další PyGTK aplikace mi až tolik nevadí. Navíc si říkám, že vývoj v Pythonu je rychlejší než v C nebo C++, takže to má alespoň nějaké výhody.

A taky zlatý Python oproti Javě (Azureus).

[David Watzke]

Navíc si říkám, že vývoj v Pythonu je rychlejší než v C nebo C++, takže to má alespoň nějaké výhody.

To je mi ale v případě programů, který hodlám používat a ne vyvíjet, docela na prd

A taky zlatý Python oproti Javě (Azureus).

Já nevím, i v tý Javě mi GUI přijde přirozenější. Už aby byl v Gentoo ebuild na JDK ze zdrojáků

[Michal Karas]

To je mi ale v případě programů, který hodlám používat a ne vyvíjet, docela na prd

To sice jo, ale když teda zůstaneme u Bittorrent klientů, tak můžeme říct, že Deluge, které nemá ještě ani rok a o kterém donedávna málokdo věděl, patří dnes k nejpokročilejším klientům a má víc fičur než KTorrent.

(Abych byl spravedlivý, tak je třeba uznat, že používají už hotovou libtorrent knihovnu, ale tak to je problém KTorrentu, že ji nepoužívá taky.)

Já nevím, i v tý Javě mi GUI přijde přirozenější. Už aby byl v Gentoo ebuild na JDK ze zdrojáků

Kdybych měl 2 GiB RAM, tak mi to taky možná přijde přirozené.

[Luboš Doležel (Doli)]

Abych byl spravedlivý, tak je třeba uznat, že používají už hotovou libtorrent knihovnu, ale tak to je problém KTorrentu, že ji nepoužívá taky.

Tak to je zatraceně podstatný detail. A libtorrent je navíc v C++...

[Michal Karas]

Ano, to samozřemě vím a je mi jasné, že je snadnější nabindovat už hotovou knihovnu do Pythonu, než to celé psát znova. Ale proto se taky divím, že libtorrent nepoužívají i v KTorrentu. IMHO by z toho mohli profitovat všichni - uživatelé Qt, GTK+ i konzolisti (rtorrent).

[Luboš Doležel (Doli)]

Protože není vhodný pro všechny účely. Já jsem chtěl taky použít libTorrent jako základ pro podporu BT v Qt download manageru a byl naprosto nevyhovující. Do softwaru psaném v Qt nezapadá, spíš tam překáží. Autory KTorrentu naprosto chápu.

[David Watzke]

Víc fičur než KTorrent? No, s tím bych byl opatrnej. KTorrent má hodně modulů a vyvíjí se dost rychle. A zas o tolik starší než Deluge není, pamatuju si verzi 1.0 - používal jsem ji A byla mnohem chudší než aktuální.

[David Watzke]

A byla mnohem chudší než aktuální.

Sám jsem se nad tohle větou po přečtení zarazil Chtěl jsem napsat: A byla mnohem chudší než ta aktuální.

[Michal Karas]

Comparison of BitTorrent software

Já jsem KTorrent zkoušel jednou a přijde mi to jako už dost dávno. Třeba na kde-apps.org byl zaregistrovaný 12. července 2005.

[...............23]

vývoj v Pythonu je rychlejší než v C nebo C++

Bullshit. C ešte možno, ale C++? Kdeže...

[Michal Vyskočil]

No a jsem navíc trochu zaujatej proti samotnýmu Pythonu

Že by to způsobilo emerge?

[David Watzke]

Jo, Portage!

[xm]

To že vývojáři Gentoo nejsou schopni napsat pořádně fungující portage je čistě jejich chyba a né chyba Pythonu.

[David Watzke]

Portage funguje, tak neplaš. Navíc oni schopni jsou. Už zbejvá jen ho vychytat. Chyba vývojářů je, že si vůbec Python zvolili, to je pravda.

[Michal Vyskočil]

No hlavní chyba vývojářů byla splácat nějaký bastl a postavit na něm distribuci. Jedno v jakém jazyce to bylo

[Käyttäjä 11133]

Ne, tím chci říct, že vše co není Assembler/Fortran je hw náročný/pomalý. :-p

[Luboš Doležel (Doli)]

Ne, ale software v Pythonu pomalý je (pokud se alespoň nezkompiluje do nativní binárky) - najděte se benchmarky.

[phero]

To určitě ano, ale jde o to jak je ten rozdíl velký a jestli bude v tomto případě pro uživatele vubec zaznamenatelný. A tudíž jestli za to stojí ty problémy navíc s implementací v low-level jazyku.

[Luboš Doležel (Doli)]

Jestli považujete C++ za low-level, tak buď schválně říkáte nesmysly, nebo jste v něm nikdy moc neprogramoval.

[phero]

vůči pythonu určitě je

[Jirka]

V čem je teda Python oproti C++ tak úžasný?

Pro mě je C++ léty prověřený, velice dobře navržený jazyk se vším, co programátor potřebuje (ale i nepotřebuje). Není možná až "tak" objektové jako Python, ale to může někdy přijít i vhod. A to je taky jediná "výhoda" (v uvozovkách, protože jde opravdu o pochybnou výhodu) o které vím.

A rychlost vývoje? V době návrhových vzorů a OOP je to trochu podivný argument.

[phero]

A rychlost vývoje? V době návrhových vzorů a OOP je to trochu podivný argument.

Tudíž implementace v různých OOP jazycích zabere stejně času, jasný ...

[Jirka]

Zapomněl jste na druhou část věty, který zněla "v době návrhových vzorů". A o čem se teď bavíme? O počtu stisknutých kláves na klávesnici při psaní třídy? Já myslím, že rychlost vývoje se odvíjí od různých programovacích technik, sdílení už napsaného kódu a možnosti práce v týmu, znalosti použitého jazyka. Nebo ne?

[Miloslav Ponkrác]

No to bych tedy silně protestoval. Použitý jazyk (a vývojové prostředí) má velmi silný vliv na rychlost vývoje. Samotné návrhové vzory nejsou Bůh a nejsou všespasitelné.

Programuji v C++ od doby, kdy vzniknul a dá se říct, že ho znám jako vlastní boty a napsal jsem v něm velmi mnoho. Ale rozhodně vývoj v Pythonu je výrazně rychlejší.

[Luboš Doležel (Doli)]

Já bych se zeptal, jestli v C++ za pomoci Qt - s Qt je to velká změna, konečně kvalitní knihovna.

[Miloslav Ponkrác]

I v Pythonu můžete za pomoci Qt Qt existuje pro oba jazyky

Ano, v Pythonu budete určitě rychlejší co se týká vývoje. Pokud nejste nemehlo. To Vám zaručuji.

Navíc je nutné říct, že na to, aby byl člověk dostatečně výkonný v C++ je potřeba značně praxe a znalostí. Já sám si vzpomínám, že i po roce programování v C++ (a to jsem dost nastudoval) mě C++ neustále překvapovalo novými možnostmi a různým chováním. Dnes už mě C++ nepřekvapuje a vím jak se chová ve všech případech, ale rozhodně C++ je velmi složitý jazyk na zvládnutí - složitější neznám. To je jeho velký handicap.

Dnes třeba vím, že jsem schopen programovat stejný problém stejně rychle v C++ jako třeba zkušený Javista. Vývoj v Javě určitého programu oproti zkušenému C++kaři není rychlejší. Ale rozhodně i relativně slabý pythonista v rychlosti vývoje snadno předežene i brutálně zkušeného C++kaře.

Velká slabina C++ je slabá a špatná standardní knihovna. Qt sice lze používat, ale rozhodně je to slabota ohledně možností C++. Třeba už jen fakt, že Qt nepoužívá výjimky není správný - a já už se rozhodně nehodlám vracet k modelu, kdy trpělivě ošetřuji chyby sledováním návratových hodnot funkcí/metod. Nehledě na to, že interface mnohých tříd vůbec nepředpokládá chybu ani tam, kde by mohla vzniknout - jednoduše vrací void.

[Luboš Doležel (Doli)]

Z Pythonisty jsem se ohledně rychlosti vývoje hádal už několikrát a vždy to skončilo na tom, co nabízí standardní knihovna, a ne na možnostech samotného jazyka. A právě horší možnosti standardní knihovny C++ mi připadá, že relativně dobře doplňuje Qt - pokud pomineme vámi uvedené nevýhody (které mě taky štvou).

[Miloslav Ponkrác]

Ono je někdy těžké rozlišit jazyk od standardních knihoven. V C++ ne, tam je ten předěl jasně daný. Ale Python, nebo i Java má část standardních knihoven integrovánu přímo do jazyka a není mezi tím jasná čára.

Qt bohužel C++ nedoplňuje - ač to není standardní knihovna. A to z těchto příčin:

1) Není volně k dispozici - je zdarma k dispozici jen GPL programům. To je vážný nedostatek.

2) Není založena na výjimkách.

3) Není to C++ knihovna - bez speciálního moc preprocesoru to nejde.

4) Zbytečně duplikuje a není příliš kompatibilní s STL knihovnou. Nepoužívá standardní typy C++ a standardní knihovny C++ ani tam kde by tobylo vhodné.

Ale řekl bych, že nejvážnější (z mého hlediska) je jasně bod 1, který v podstatě Qt vylučuje jako náhradu, nebo doplněk standardní knihovny. A já osobně nejsem schopen zavřít oči nad bodem 2. To bych si musel udělat wrapper Qt, který by to zařídil a to je pro mě jednodušší si napsat knihovnu vlastní - čímž zmizí i bod 1).

[Martin Böhm]

Myslím si, že je správné, že Qt není k dispozici zdarma pro proprietární software. Do Qt byla investována spousta práce a peněz, Trolltech si tedy nepřeje, aby jiní na jeho plodech vydělávali bez placení. Pokud chcete vytvářet proprietární program (a proč byste to jinak dělal, než za účelem vydělání peněz), musíte se prostě podřídit komerci a knihovnu si koupit. Pokud ale na přímém prodeji vydělat nechcete, pak Vám postačí vydat software pod GPL.

Skutečnost, že si nakonec vyberete jinou knihovnu, protože přenositelnost Vám za takovou cenu nestojí, je věc jiná

PS: Omlouvám se za trochu offtopic komentář, snad nebude fungovat jako benzín vylitý do flamewar.

[Miloslav Ponkrác]

To je opravdu hodně off topic téma. A trochu nepochopený můj komentář. Bavili jsme na téma, zda Qt je vhodná náhrada (nebo doplněk) standardní knihovny. Já samozřejmě chápu strategii Trolltechu, ale rozhodně nic, co by mělo fungovat jako standarní knihovna, nebo jeho náhrada by tyto licenční problémy mít nemělo.

Nerad bych rozvířil téma, ale nechápu proč si myslíte, že za skutečností vydat proprietární program stojí vždycky jen snaha vydělat peníze. Uf, trpíte moc malou představivostí pane a fanzii nemáte pražádnou (bez urážky). Nehledě na to, že Qt není free pro open source programy, ale pouze pro jejich malou část - programy pod licencí GPL.

Byl bych docela rád, kdyby na mě nereagovali GPL evangelizátoři - protože já proti GPL nic nemám.

[Martin Böhm]

Uf, trpíte moc malou představivostí pane a fanzii nemáte pražádnou (bez urážky).

Urážka bez urážky? Pokud nechcete urazit, tak takové věty vůbec nepište :o) Jinak o sobě samozřejmě vím, že jsem nadutec, blboun nejapný, bez fanzie i fantazie a mnoho dalšího. Budu ale rád, když díky Vám prozřu :o)

Mýlíte se v tom, že Qt může být použito jen pro software licencovaný pouze pod GPL. Toto (pokud to není zastaralý odkaz) a toto to vyvrací.

[Miloslav Ponkrác]

A jak mám reagovat na takovou blbost ve stylu, že proprietární program se dělá pouze za účelem vydělání peněz? A já o vás neprohlásil, že jste blboun, nebo nadutec, ale jen že nemáte představivost, protože spousta proprietárních programů (řekl bych milióny) na celém světě jsou zdarma a autor ani nikdo jiný je nepíše za účelem vydělání peněz.

Qt může být použitou pouze pro velmi právnicky omezenou množinu programů, pokud ho nechcete koupit - stačí?

[phero]

A vubec, o to mi nešlo. Jde mi o to jestli by šlo na běžnym stroji poznat, kdyby byl Deluge napsaný v C++ místo pythonu. O tom, že v python (nebo dokonce ruby) je vývoj daleko rychlejší než v C++ se snad nebudeme přít

[Luboš Doležel (Doli)]

Jako programátor v C++/Qt si to ani nemyslím. Když máte za sebou silnou a kvalitní knihovnu, je všechno rychlé.

[phero]

Jasně, díky za odpověd. Můžu se tě ještě zeptat proč píšeš v C++ a ne třeba právě v pythonu nebo ruby? Právě se učim C++ z jediného důvodu a to je množství opensource kodu v C++. Kde bez znalosti C[++] je malá možnost někam přispět. Tak bych byl rád kdyby si mi řekl proč upřednostňuješ C++, rád bych větší motivaci než jen rozšířenost.

[Luboš Doležel (Doli)]

• Výkon
• Výkon
• Výkon
• Není potřeba žádných bindings ani jiných šaškáren
• Je to jazyk, se kterým uděláte všechno - systémovou službu, GUI aplikaci, výkonnou OpenGL hru, modul do jádra, modul do PAMu, cokoliv - neříkám, že některé vyjmenované věci neuděláte i v Pythonu
• Komerční vývoj softwaru probíhá obvykle v C++ nebo Javě - oba jsou to jazyky příbuzné. Po naučení jednoho snáze zvládnete druhý a řadu dalších.
• Podle potřeby můžete dělat low-level věci. Nebo také nemusíte.

[Miloslav Ponkrác]

Já se do toho taky vlomím. Já píšu jak v C++ i v Pythonu, ale začal jsem Python dost omezovat. Důvod je jednoduchý:

1) Nespolehlivost při převodu do binárky a neustálé náhodné problémy s tím plynoucí, které nelze rozumně vyřešit.

2) Vidina Pythonu 3000, který chce změnit syntaxi zdrojového kódu a já nechci přepisovat v budoucnu své zdrojové kódy kvůli pitomému jazyku, který neví co je to zpětná kompatibilita.

3) Větší možnosti C++, všechno mám pod rukou - mohu být low level i high level. Podle potřeby.

4) Výkon. C++ je jasně rychlejší. Ale tohle je ten nejméně závažný argument.

[...............23]

Môžeš aj povedať prečo by mal byť vývoj v Pythone ďaleko(dokonca!) rýchlejší než v C++, alebo si to len niekde počul? Lebo mne to pripadá čo sa týka tohto zhruba na rovnakej úrovni... (teda s výnimkou že pre C++ je dostupných ďaleko viac knižníc)

[phero]

Tak řekněme ruby a ne python. Nemusim blbnout s pointerama, headerama, starat se o deklarovani typu a tuny podobnyho balastu. Taky samotná objektovost jazyka z pohledu uživatele (programátora) je uplně jinde. U standardních knihoven v C++ je třeba celkem běžné, že používají globalní funkce pro manipulaci s objekty.

[Michal Kubeček]

Nemusim … starat se o deklarovani typu

A to je výhoda???

[Martin Böhm]

Samozřejmě. O co méně věcí se musím starat, o tolik produktivnější budu, pokud jde o programování samotné. Nebo jinak: čím více formy za mne obstará interpret/překladač, tím více času budu míti na vylepšování obsahu.

[Luboš Doležel (Doli)]

S pointerama v C++ taky blbnout nemusím, napsání nějakého #include rozhodně není žádné složité blbnutí a deklaraci typu považuji za zatraceně důležitou věc. Je to součást kontroly kvality a chyb v softwaru.

[Miloslav Ponkrác]

Zajímavé, dělám v C++ už mnoho let a pointer vidím jen velmi zřídka. Prakticky už začínám zapomínat co to je, nebýt toho, že musím udržovat pár projektů v C.

Deklarování typu je velmi užitečná věc a žádný program, která program jednak zrychluje a jednak ho činí daleko bezpečnějším.

Samotná objektovost C++ je na velmi vysoké úrovni. Python má v zásadě o několik řádů víc neobjektových věcí ve standardních knihovnách, než v C++.

[Miloslav Ponkrác]

Já bych o rychlejším vývoji v Pythonu oproti C++ nepochyboval. Důvod je jednoduchý, není třeba kompilovat. Pak high level konstrukce v Pythonu.

[phero]

To výpadá jako "mladší bráška" ktorrentu, který ale fandí gtk. Ale musim uznat, že ano to gtk nevypadá špatně. Jen škoda toho file dialogu

[KaiSVK]

btw. vsimol si niekto tie pripicne banery microsoftu ? :D to je ale grc

[frEon]

kde?

[mess]

No v tom článku, vpravo nahoře. Takový hnusný čtverec.

[Limoto]

myslíš tohle?

[KaiSVK]

no toto toto ... smarja pano ...

[mess]

Přesně to myslím.

[peto]

Na taketo reklamy mam jeden link: highscalability.com
Celkom zaujimave citanie (amazon preskocte :) ).