Seznam.cz: druhá liga

7.8.2006 13:01 | Přečteno: 2084× | Ani zbla

Mám tendenci nedůvěřovat službám, u kterých není zaručeno zhola nic (obvykle proto, že jsou zadarmo). Mám na mysli například freemaily. Dlouhou dobu jsem byl vášnivý odpůrce freemailů, jednak pro mizernou spolehlivost, druhak pro šílený uživatelský komfort (pomalé a plné reklam). Mám na mysli především české prostředí.

První skutečně použitelný freemail je GMail. Používám ho a shodl jsem s řadou lidí, že je to skvělá služba. A Googlu zatím věřím.

Občas čtu blog Iva Lukačoviče, majitele "českého Googlu". No a občas prosakují informace, které mě utvrzují o (nebojím se ten výraz použít) amatérismu této firmy.

Cituji z http://blog.lide.cz/ilblog/2006/07/20/329 o výpadku služby Email.cz a částečné ztrátě dat.

Co budete dělat aby se něco takového nestávalo dál?

Přijali jsme sadu opatření, abychom problémům z disky předcházeli. Začínáme evidovat jejich stáří a sérii a ty staré chceme začít preventivně vyřazovat sami, pokud zjistíme, že mezi kolapsem disků a jejich stářím je skutečně přímá úměra. (...)

Vsadím se o co chcete, že v Googlu takové nějaké proaktivní opatření praktikují dlouhá léta. Já Seznam chápu, v naší kotlině se prostě nevyplatí investovat do skvělých technických řešení. Když mají v Goooglu 100000 serverů (přesné číslo nikdo neví), tak se vyplatí mít pár lidí s Ph.D., co se hrabou ve statistikách a určují, kterou šarži kterých disků kupovat a které preventivně poslat do skartovací pece. (Mají v Seznamu skartovací pec? Vždyť nemají ani vlastní hasičskou jednotku

Važte si svých dat, nedávejte je amatérům.

       

Komentáře

[vencour]

Ach jo, autore, moc schopně Tvá poznámka nevypadá. Nechceš to rozvést? Ať to neni jen plácnutí? Jo, ten povzdech Lukačoviče mi připomíná logiku dialogu už snad dávno minulou, tedy je to tragédie. To abych se na ten jeho blog někdy taky podíval sám ...

[alblaho]

Rozvést? Ne, to bylo jen takové ublognutí. Prostě z globálního pohledu budou vždy zaostávat. Z řady celkem zjevných důvodů.

[vencour]

V našem "kapřím" rybníku je pořád štikou, ne? Kde neni (až taková) poptávka, nebude nabídka.

[alblaho]

Jop. Ale proč se neporozhlédnout po lepším rybníku. Když internet cestování mezi rybníky zkrátil na

$ ping google.com

Pinging google.com [72.14.207.99] with 32 bytes of data:

Reply from 72.14.207.99: bytes=32 time=138ms TTL=234
Reply from 72.14.207.99: bytes=32 time=143ms TTL=234
Reply from 72.14.207.99: bytes=32 time=150ms TTL=234
Reply from 72.14.207.99: bytes=32 time=163ms TTL=235

[David Watzke]

Na

$ ping mail.klenot.cz
PING mail.klenot.cz (87.236.199.95) 56(84) bytes of data.
64 bytes from mail.klenot.cz (87.236.199.95): icmp_seq=1 ttl=60 time=21.8 ms
64 bytes from mail.klenot.cz (87.236.199.95): icmp_seq=2 ttl=60 time=17.2 ms
64 bytes from mail.klenot.cz (87.236.199.95): icmp_seq=3 ttl=60 time=24.3 ms
64 bytes from mail.klenot.cz (87.236.199.95): icmp_seq=4 ttl=60 time=20.9 ms

[trekker.dk]

PING www.l.google.com (66.249.91.147) 56(84) bytes of data.
64 bytes from 66.249.91.147: icmp_seq=1 ttl=242 time=63.0 ms
64 bytes from 66.249.91.147: icmp_seq=2 ttl=242 time=31.5 ms
64 bytes from 66.249.91.147: icmp_seq=3 ttl=242 time=43.9 ms
64 bytes from 66.249.91.147: icmp_seq=4 ttl=242 time=41.6 ms
64 bytes from 66.249.91.147: icmp_seq=5 ttl=242 time=42.9 ms
64 bytes from 66.249.91.147: icmp_seq=6 ttl=242 time=53.7 ms

[JiK]

lenochod:~ jik$ ping www.google.com
PING www.l.google.com (66.249.85.99): 56 data bytes
64 bytes from 66.249.85.99: icmp_seq=0 ttl=248 time=6.806 ms
64 bytes from 66.249.85.99: icmp_seq=1 ttl=248 time=6.686 ms
64 bytes from 66.249.85.99: icmp_seq=2 ttl=248 time=6.814 ms
64 bytes from 66.249.85.99: icmp_seq=3 ttl=248 time=6.790 ms
64 bytes from 66.249.85.99: icmp_seq=4 ttl=248 time=7.249 ms
64 bytes from 66.249.85.99: icmp_seq=5 ttl=248 time=6.749 ms
64 bytes from 66.249.85.99: icmp_seq=6 ttl=248 time=6.694 ms
64 bytes from 66.249.85.99: icmp_seq=7 ttl=248 time=6.760 ms
^C
--- www.l.google.com ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 6.686/6.819/7.249/0.169 ms

[stativ]

Mezi ping google.com a ping www.google.com je ale velkej rozdil:

[lukas@red_dragon ~]$ ping google.com
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from 64.233.187.99: icmp_seq=1 ttl=236 time=123 ms
64 bytes from 64.233.187.99: icmp_seq=2 ttl=236 time=123 ms
64 bytes from 64.233.187.99: icmp_seq=3 ttl=236 time=123 ms
64 bytes from 64.233.187.99: icmp_seq=4 ttl=235 time=120 ms
64 bytes from 64.233.187.99: icmp_seq=5 ttl=236 time=133 ms
64 bytes from 64.233.187.99: icmp_seq=6 ttl=236 time=124 ms

--- google.com ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 5995ms
rtt min/avg/max/mdev = 120.843/124.906/133.505/3.739 m

[lukas@red_dragon ~]$ ping www.google.com
PING www.l.google.com (72.14.221.104) 56(84) bytes of data.
64 bytes from 72.14.221.104: icmp_seq=1 ttl=246 time=22.2 ms
64 bytes from 72.14.221.104: icmp_seq=2 ttl=246 time=20.9 ms
64 bytes from 72.14.221.104: icmp_seq=3 ttl=246 time=22.3 ms
64 bytes from 72.14.221.104: icmp_seq=4 ttl=246 time=23.1 ms
64 bytes from 72.14.221.104: icmp_seq=5 ttl=246 time=47.5 ms
64 bytes from 72.14.221.104: icmp_seq=6 ttl=246 time=23.4 ms

--- www.l.google.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4999ms
rtt min/avg/max/mdev = 20.909/26.612/47.531/9.390 ms

[NbS]

[martin@localhost ~]$ ping -c3 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.040 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.041 ms

a proc to neobratit v neco jineho ze ? :)

[Josef Kufner]

Mnoo, až tak moc se to nezkrátilo

PING www.l.google.com (66.102.9.104) 56(84) bytes of data.
64 bytes from 66.102.9.104: icmp_seq=1 ttl=239 time=11973 ms
64 bytes from 66.102.9.104: icmp_seq=2 ttl=239 time=11550 ms
64 bytes from 66.102.9.104: icmp_seq=3 ttl=239 time=11621 ms
64 bytes from 66.102.9.104: icmp_seq=4 ttl=239 time=11715 ms
64 bytes from 66.102.9.104: icmp_seq=5 ttl=239 time=12120 ms

--- www.l.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 11550.491/11796.163/12120.522/216.298 ms, pipe 5


PING www.seznam.cz (194.228.32.3) 56(84) bytes of data.
64 bytes from www.seznam.cz (194.228.32.3): icmp_seq=1 ttl=57 time=13541 ms
64 bytes from www.seznam.cz (194.228.32.3): icmp_seq=2 ttl=57 time=13106 ms
64 bytes from www.seznam.cz (194.228.32.3): icmp_seq=3 ttl=57 time=13202 ms
64 bytes from www.seznam.cz (194.228.32.3): icmp_seq=4 ttl=57 time=13569 ms
64 bytes from www.seznam.cz (194.228.32.3): icmp_seq=5 ttl=57 time=12929 ms

--- www.seznam.cz ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 12929.086/13269.951/13569.670/249.550 ms, pipe 5

A koukám, že google je na tom o kus líp

[Luk]

Také sem něco přihodím:

PING www.seznam.cz (194.228.32.3) 56(84) bytes of data.
64 bytes from 194.228.32.3: icmp_seq=0 ttl=58 time=1.17 ms
64 bytes from 194.228.32.3: icmp_seq=1 ttl=58 time=1.24 ms
64 bytes from 194.228.32.3: icmp_seq=2 ttl=58 time=1.01 ms
64 bytes from 194.228.32.3: icmp_seq=3 ttl=58 time=1.17 ms

PING www.l.google.com (66.249.93.104) 56(84) bytes of data.
64 bytes from 66.249.93.104: icmp_seq=0 ttl=244 time=26.1 ms
64 bytes from 66.249.93.104: icmp_seq=1 ttl=244 time=26.3 ms
64 bytes from 66.249.93.104: icmp_seq=2 ttl=244 time=26.5 ms
64 bytes from 66.249.93.104: icmp_seq=3 ttl=244 time=25.7 ms

PING www.l.google.com (66.249.93.99) 56(84) bytes of data.
64 bytes from 66.249.93.99: icmp_seq=0 ttl=244 time=21.2 ms
64 bytes from 66.249.93.99: icmp_seq=1 ttl=244 time=20.9 ms
64 bytes from 66.249.93.99: icmp_seq=2 ttl=244 time=21.5 ms
64 bytes from 66.249.93.99: icmp_seq=3 ttl=244 time=21.9 ms

PING google.com (64.233.167.99) 56(84) bytes of data.
64 bytes from 64.233.167.99: icmp_seq=0 ttl=242 time=125 ms
64 bytes from 64.233.167.99: icmp_seq=1 ttl=242 time=124 ms
64 bytes from 64.233.167.99: icmp_seq=2 ttl=242 time=123 ms
64 bytes from 64.233.167.99: icmp_seq=3 ttl=241 time=124 ms

(Zejména doporučuji všimnout si rozdílu mezi IP adresami odkazovanými stejnou jmennou adresou.)

[Luk]

Ono je to totiž tím, že i když jsou obě adresy ve stejné síti, na každou adresu to směruje jinudy (v jednom případě navíc o 2 hopy delší trasou). Má to ale strýček Google divnou čelátku

[KroliN]

Neco mi rika, ze to co pises vypada o tve zaujatosti nebo neinformovanosti?ted nevim ja seznam taky nepouzivam ale pouziva ho tolik lidi zvlast z cr ze jim verim..(o to vic kdyz se podivam na centrum,ten proste nenavidim mail stoji za nic) Uprimne si myslim ze delaji pokroky..srovnani s googlem a yahoo by bylo nesmyslne

[Haaja]

Musím nesouhlasit. Email na seznamu sice již dlouho nepoužívám i když tam jednu adresu mám. Ale myslím si, že z českých freemailů je jeden z nejlepších. Těžko můžete srovnávat Gmail. Ale z praxe musím říct, že třeba kvalita služeb email.cz od doby co je to pod opatrováním seznamu se o 100% zvýšila. A asi není nic lehkého udržovat takto velký freemail.

[alblaho]

Zlepšila, to je dost dobře možné. Vždyť Seznam je v Čechách špičková firma. Ale vždycky bude z principu dost zaostávat za globální špičkou.

[klassik]

Mam mejla na seznamu tak 10 let a nic se mi z nej neztrtilo.Za tu dobu sem si omylem sam smazal mnohen vic veci nez by my seznam mohl kdy smazat.

Nelibi nepouzivej, nepomlouvej

[sssssssss]

Používal jsem pár let mail na seznamu, když začal být v modě gmail založil jsem si tam taky účet a vše ze seznamu jsem směřoval tam. Asi po půl roce jsem se opět vrátil k seznamu, protože mi prostě vyhovuje víc, spam mi hází do spamu a narozdíl od gmailu mi nedělá bordel (to jejich slavný řazení mailu "jako" diskuze) v M2, do kterýho si zprávy stahuju. Možná to jde ted nějak nastavit, ale už gmail nemam a nechci. Freemail používam, jen jako adresu a maily tam nenechávam.

[alblaho]

Ale já neříkám, že to rozhraní je vyloženě špatné. Pokud se vám to líbí víc než Gmail, prosím, je to věc názoru.

Ale prostě způsob, jakým ta firma funguje (firemní procesy, jak se starají o data...). Je na dost jiné úrovni.

[sssssssss]

hmmm to je možný, ale nebyl jsem ani v seznamu ani v google.

[Heron]

Seznam je prostě otloukánek. Nevím, jestli za to může čeká závist, nebo něco jiného. Místo aby byl člověk rád, že má zadarmo dobré služby, tak nadává. Zajímalo by mě, jestli se autorovi postu na seznamu něco ztratilo -- a pokud to bylo tak důležité, tak proč to neměl zálohované, nebo umístěné na placeném serveru.

[Dalibor Smolík]

Naprosto souhlasím.

[kotrcka]

Ja pouzivam 3 (slovom TRI) maily. Jeden na GMail, druhy na HotMail a treti mam plateny na serveri ISP. Nemam ani s jednym problem, pretoze je to rokmi preskusana a vyselektovana sluzba. Nijakemu post.sk, azet.sk, pobox.sk a podobne by som svoje dolezite maily nezveril. Jedine, co ma trosku stve, ze z hotmail konta sa neda posta stiahnut cez POP3. No nic, nemozem mat vsetko.

[JiK]

Je to závist, jen jednu věc Češi neodpouští a tou je úspěch.

[madA]

zacinate znit jako ross hedvicek ... bacha na to

[Jan Přech]

A Vy také neodpouštíte úspěch? Nebo už se považujete za Čecha pouze jménem? Nebo co tedy Vás opravňuje házet nás všechny do jednoho pytle?

Chápu Vás, někdy je těžké odolat siláckým obecným soudům (zvlášť když se jedná o zopakování zaběhlého klišé), ale možná byste to mohl zkusit. Jistě to leckdo z Vašeho okolí ocení.

[JiK]

Diky, popremyslim o tom. (A ano, vsimam si, ze obcas take 'trochu' zavidim uspesnejsim kolegum)

[Jindřich Pozlovský]

Už jenom samotný fakt, že autor srovnává Seznam s Googlem a nikoliv s Centrem nebo Atlasem myslím nazačuje, že je na tom Seznam vlastně celkem dobře :)

[mrzout]

To je pravda.

Ostatne se casto pise o tom, ze Google nevstoupil do CR ze strachu z pozic Seznamu.

Seznam jiz ma pomerne sirokou skalou sluzeb a divil bych se, kdyby driv nebo pozdeji se nepokusil uvest na svet nejaky anglicky portal. Jiste, liga kterou hraje Google a Yahoo je jinde, do toho muze jen tak vstoupit MS dotovany pomatencema s IE, ale ja bych Seznam nezatracoval.

Treba dnes jsem hledal jednu konkretni firmu a fulltextem se nedarilo - seznam disponuje databazi firem s informacemi o zemepisne poloze, a tak jsem to pres nej snandno dohledal.

[alblaho]

Předpokládám, že si děláš srandu. Anglický portál od Seznamu, no to je dobrý vtip

Seznam má pár dobrých "regionálních" věcí. Tu databázi firem. Jinak mail jen špatná (bez ajaxu) kopie Gmailu (aneb Lukačovičův "průmyslový standard"). Mapy jsou fakt dobré, ale opět kopie (tentokrát ovšem zdařilá) maps.google.com. No a vyhledávač nechám stranou (počítám, že na globální vyhledávač jsou potřeba megawatty elektriky)

Víš ty co znamená bojovat na globálním trhu? Vem si třeba Microsoft, snaží se, ale zatím nic moc.

[Pavel 'lingeek' Szalbot]

Četl jsem, že clustery Google se analyzují samy, vadné uzly hlásí zodpovědným osobám (samy se odstaví) a ty pracují na opravách. Myslím, že to v principu nemusí být nic extra, v Googlu to ale bude asi hodně "vychytané".

[vencour]

? To neni vtip?

[jarda]

Tady jde spíš o Gbytové schránky z kterých si někteří hned udělali úložiště dat a něco jako FTP. E-mail je snad na jiné věci a ruku na srdce i kdybych potřeboval přístup ke staré poště odkudkoli Giga je snad zbytečně moc. Hodně dat, hodně disků, velký provoz více poruch to patří k sobě a kdyby v Čechách byly zadarmo sirky budou jich mít nekuřáci batohy a ostatní budou shánět křesadla.

[alblaho]

Nesmysl. Poštu mažou jenom ufouni (vždycky se to může hodit). No a mám zabráno pár set mega a to prosím žádné velké úložiště neprovozuju - jen pár mejlů s fotkama a trochu většíma dokumentama. Giga rozhodně moc není, nic nemazat je pohodlné a prospěšné.

Navíc gigo prostoru dnes stojí tolik jako deset mega za úsvitu freemailů.

[VícNežNic]

No, třeba spam a kraviny ruším nekompromisně. I když bych normální mail v životě nesmazal

[Heron]

jen pár mejlů s fotkama a trochu většíma dokumentama.

A odkdy je na tohle určen email? Na soubory tu vždy bylo ftp (požději i další možnosti).

[kyknos]

Zkus přesvědčit BFU aby ti něco posílal na FTP. Mail je ta lepší varianta. Horší je ICQ. Nehledě na to, že GB prostoru na mailu je dnes rozhodně dostupnější než GB na FTP, pokud tedy nemáš vlastní server (což většina lidí nemá).

[Heron]

Zkus přesvědčit BFU aby ti něco posílal na FTP.

Ano, to dnes bude velmi těžké. Ale uvědomíme-li si, že email, ftp, web pochází přibližně ze stejné doby, tak by mi přišlo logické, že s rozvojem webu a (free)mailů, se začnou provozovat i file-služby. BFU je schopný posílat soubory "jakkoliv" (přes IM, email, a dokonce i přes freeweb). Pokud by existovali souborové služby, tak by se velmi imho rychle prosadily.

pokud tedy nemáš vlastní server (což většina lidí nemá).

Tohle je pravda jen částečně. Vlastní server může mít prakticky kdokoliv a pokud se domluví skupina lidí, která si potřebuje vyměňovat soubory, tak si obvykle takový server pořídí -- zkušenost z okolí.

[D-Evil]

Souborový služby budoucností asi budou a v zahraničí jich několik celkem úspěšně funguje. Nicméně u nás to podle mě ještě chvíli hrozit nebude, protože narozdíl od tuzemskejch freemailů se u freewebů s velkou kapacitou nedá kalkulovat s velkou agregací fyzickýho diskovýho prostoru.

Dovolim si tvrdit, že revoluční by bylo postavit takovej systém alternativně na přítulný klientský aplikaci, která by před počítačově nevzdělanym uživatelem vtipně maskovala, že je ve skutečnosti jen obyčejnym HTTP/FTP klientem. A kdyby se přidala i přidaná hodnota v podobě server&client-side MD5 ověření integrity souboru, asi by se těžko hledala konkurence. Odesílání a koneckonců ani stahování velkejch souborů browserem totiž neni zrovna nejšťastnější a v porovnání s přenosem souborů mailem je lepší v podstatě jen kosmeticky a ideologicky.

[alblaho]

No nevím odkdy jsou v mailech přílohy, ale myslím, že docela dlouho.

Možná je ta funkce nadužívána a rozhodně to nebylo projektované na stomegabajtové přílohy. Mně osobně to omezení velikosti příloh dost štve. Prostě když platím přenos po lince, tak bych rád poslal gigo z bodu A do bodu B emailem. Proč ne? Proč by to nemohlo fungovat? Jen to chce novou generaci této služby.

[Luk]

No nevím odkdy jsou v mailech přílohy, ale myslím, že docela dlouho.

Hodně dlouho. MIME existuje od roku 1992, ale pomocí uuencode a dalších podobných metod se přílohy posílaly už dost dlouho před tím.

Možná je ta funkce nadužívána a rozhodně to nebylo projektované na stomegabajtové přílohy. Mně osobně to omezení velikosti příloh dost štve. Prostě když platím přenos po lince, tak bych rád poslal gigo z bodu A do bodu B emailem. Proč ne? Proč by to nemohlo fungovat? Jen to chce novou generaci této služby.

Má to zcela logické důvody. Většina MTA není navržena a implementována pro přenos obrovských souborů. Přece jen je rozdíl, když se posílají objekty velikosti jednotek KB, anebo stovek MB. Kromě toho i přenosové protokoly (SMTP, POP3, IMAP a další) nejsou navrženy na velké soubory, např. z hlediska obnovy přerušeného přenosu.

Na přenos velkých souborů jsou zase jiné technologie. Sice lze zatloukat hřebíky hasákem nebo šroubovat nožem, ale nebude to nikdy ono. Sice už jsem také jednou posílal nějaký obrovský soubor skrz IM, ale považuji to za zvěrstvo.

[alblaho]

Zvěrstvo nezvěrstvo, já chci, aby mi počítače usnadňovaly život. FTP je sice hezké (jednou jsem ho implementoval, každý klient a každý server má nějaké své móresy , ale moje maminka s tím neumí. A to už vůbec nemluvím tom mít nějaká ftp server (s veřejnou IP atd.). Prostě fuj.

Nezbývá než předělat MTA, aby sežral cokoliv.

Většina MTA není navržena a implementována pro přenos obrovských souborů. Přece jen je rozdíl, když se posílají objekty velikosti jednotek KB, anebo stovek MB.

V čem? Ve velikosti? Od toho tu jsou tlustší kabely a žhavější procesory.

[D-Evil]

Ve velikosti ten problém je, ale ne kvůli kabelům ani procesorům. Problém je v pravděpodobnosti výskytu chyby při přenosu, kterou neni protokol díky svýmu návrhu schopnej řešit (např. obnovením přenosu v místě, kde došlo k chybě).

Když pojedete trabantem nakoupit do kilometr vzdálenýho obchodu, dost možná se ani po tisíci pokusech nic nestane. Ale jeďte s nim tisíckrát tisíc kilometrů na dovolenou...

[KroliN]

Ja tomu nerozumim, ale nejde proste email a soubor posilat zvlast?email pres svuj protokol a soubor pres ftp?staci s nim poslat mensi identifikator treba id emailu zaheshovane a email oznacit tim samym nebo nejak jinak.Kdyz uz by se dohodli??

[D-Evil]

A proč by to někdo dělal? Proč nestačí říct, že takhle se to dělat nemá (a dodat, že se to má dělat tak a tak)? Samozřejmě by to všechno asi udělat šlo, asi i docela jednoduše, ale nemá to žádnej smysl. Trabanta taky nikdo nepředělává na Mercedes, aby s nim moh jezdit na tu dovolenou. Koupí si rovnou originál Mercedes, vyjde ho to levnějc a funguje to líp.

[vagojan]

Zvěrstvo nezvěrstvo, já chci, aby mi počítače usnadňovaly život.

Nezbývá než předělat MTA, aby sežral cokoliv.

Satane drž se dál od mých IP adres a transportních cest.

Dej se k Microsoftu, je jedno že je to nebezpečné řešení, nestabilní a v důsledku těžce nerentabilní, hlavně že je to jednoduché...

Můžu ti říct že je dost velký problém spravovat mailserver, zejména ve firmě kde se k mailu přistupuje jako k zaručené službě a používá se k přenosu draze placených dat. Ale ani tak nepovolujeme víc než 20MB na zprávu.

To co ty hlásáš je jako jízda v nákladáku z Barrandovského kopce s vyřazeným kvaltem a návěsem plným sklářského písku.

[D-Evil]

S vypnutym motorem a po náledí.

[alblaho]

Tobě by se nelíbilo mít novou generaci mailových služeb, který by zvládla velké objemy dat a třeba byla zaručená? Měla by dobré zotavování z chyb a doručenky. Já nechápu, co všichni máte, lidem by se to dobře používalo a technicky je to realizovatelné.

Jistě, chtělo by to vyřešit takové ty hloupoučké případy, kdyby někdo poslal gigovou přílohu do LKML. Nějaké kvóty by být musely (a třeba by se dělily počtem adresátů). No ale mohlo by to fungovat aniž by admini skřípali zubama (současný stav, kdy uživatelé chtějí posílat velká data a admini se tomu brání).

[tomasgn]

uzivatele obvykle chteji posilat kraviny, jako ruzne *.exe srandicky nebo mpeg z posledni oziracky, a klidne by poslalli mailem i obraz CD, kdyby to slo. bez ohledu na to, ze ta oziracka byla firemni, si skutecne myslim ze takove veci patri na ftp/fsp/http, ale ne do mailu.

[vagojan]

Samozřejmě, bylo by to hezké, za předpokladu že budou mít všichni gigabitové linky, veškerá výměna dat poběží relačně, včetně kontrolních součtů a šifrování, každý SUPERmailový server bude mít certifikaci od NBU, několik stovek GB volného prostoru pro provozní data dostatečný výkon na to aby to všechno ošetřil... ideálně se to bude šířit přes UDP (nebo uděláme snad rovnou jiný lepší datagram).

Ano dá se udělat spousta pěkných věcí. Ale bude to stát několik centů na každý mail a nebude to smět být v žádném případě slučitelné se stávající technologií mailu. (nebezpečí přicházející z venčí... nečekané nároky na systém vycházející zevnitř)

Ale zase potom ubyde spamu... ale budou to používat normální lidé? Koupí si to normální lidé?

[Orrorin]

To není přece není pravda. Protokol mailu měnit netřeba, stačí, když poskytovatelé mailových služeb budou zároveň poskytovat službu pro uskladnění souborů. Uživatel klidně v mailovém klientu připojí libovolně velkou přílohu (velikost bude omezená jen prostorem, který mu poskytovatel služby na _svém_ serveru dá), příloha se nejprve uloží na server poskytovatele, vygeneruje se nějaký její identifikátor a ten se spolu s nějakou obálkou vloží jako příloha do mailové zprávy. Mail se pak odešle klasicky. Příjemce buď bude mít mailového klienta, který si bude s tímhle systémem rozumět (a pak se třeba zpráva automaticky stáhne ze serveru odesilatelova poskytovatele - buď rovnou k uživateli nebo si vyžádá na serveru svého poskytovatele, aby se stáhla i tam - do adresátova úložiště) nebo ne a v tom případě se mu třeba zobrazí jenom odkaz, odkud si to může ručně (ftp, http) stáhnout k sobě. Poskytovatel by mohl třeba ještě omezit, že každý soubor lze stáhnout pouze jednou (aby se takhle nešířil třeba warez).

[tomasgn]

tvoje reseni by vyzadovalo zasah do mnoha existujich maileru. za druhe, SMTP protokol neumi navazovat spadla spojeni (jak jiz byl zmineno), takze kdyz nekdo posle 400MB prilohu a behem odesilani/stahovani spadne spojeni, bude se to muset posilat znovu od zacatku.

dnes uzivaci vezmou nejaky vtipek velikosti par megabajtu, vrazi ho do mailu, do To: (pripadne CC:) daji 5-100 adres (uz to je zhovadilost), a poslou to. dovedes si predstavit co se stane kdyz na stejne mnozstvi adres misto par megove prilohy posle treba 400MB?

a pak ti stejnou kravinu posle mailem jeste 5 dalsich lidi... prijemnou zabavu!

nemluve o tom, ze soucasni e-mail klienti by se z podobnych priloh zcela jiste taky vysypali, takze jsme nejen pred prepsanim vsech MTA, ale i MUA, plus dalsi software na ne navazujici.

mozna se za par let budou tak velke prilohy prenaset bezne, dnes si to ale neumim predstavit.

[Luk]

Mně to hlavně pořád přijde, jako když chce někdo nosit cihly v tenké igelitce a diví se, že to nejde. Nebo když chce stěhovat velký nerozebíratelný gauč Fabií nebo Matizem. Kdo chce nosit cihly (když už je chce nosit a ne vozit), ať si pořídí odpovídající zavazadlo. Na stěhování gauče ať si vezme dodávku nebo náklaďák. No, a na přenos obrovských souborů ať použije technologii, která je k tomu určená.

[Orrorin]

A která technologie je k tomu určená, smím-li se ptát? Popište mi, jak jednoduše někomu pošlete velký objem dat, který ale nemá přijít do rukou někomu cizímu. Ať už vymyslíte cokoli, bude to jistě neuvěřitelně nepohodlné.

Přenos přílohy mezi odesilatelem a serverem poskytovatele by byla samozřejmě realizována vhodnou technologií, stávající mail servery by se vůbec neměnily, pouze by vznikla nová služba a patřičným způsobem by se upravily klientské aplikace. Z hlediska uživatele by to ale mohlo být plně transparentní.

Prostě nechme stávající protokol pro malé maily, zaveďme něco nového pro velké soubory a obě služby spojme.

Z pohledu nepoučeného uživatele je přece naprosto přirozené poslat fotky z páteční pařby kamarádům mailem. Není jeho chyba, že se to tak snaží udělat.

[Luk]

Ano, udělejme něco nového, co bude určeno pro tyto přenosy. Ale nechtějme se to snažit tlačit přes nevhodné protokoly, např. SMTP (Simple Mail Transfer Protocol).

Může to klidně fungovat jako vrstva nad tím. Bude to třeba vypadat tak, jako když se posílá mail s přílohou (jako dnes), ale přes SMTP půjde jen samotná zpráva + odkaz. Přílohu klient odesílatele přenese (třeba pomocí FTP, FTPS, SFTP, SCP, WebDAV apod.) na server, odkud si ji vyzvedne klient příjemce.

Nebo to může být i úplně nový protokol určený jen pro toto. Je jedno, jak se to udělá, ale požadovat, aby se to řešilo zvýšením/odstraněním kvót na stávajících serverech mi moc smysluplné nepřijde.

[Orrorin]

Bude to třeba vypadat tak, jako když se posílá mail s přílohou (jako dnes), ale přes SMTP půjde jen samotná zpráva + odkaz.

No vždyť něco takového jsem se pokusil (asi neobratně) popsat.

[Heron]

A která technologie je k tomu určená, smím-li se ptát?

FTP, nebo lépe SCP.

[Michal Čihař]

No giga mi až tak moc nepřijde, už tahle mám mailů docela dost a ubývat nebudou

du -sh Maildir/
658M    Maildir/

[tomasgn]

Přijali jsme sadu opatření, abychom problémům z disky předcházeli. Začínáme evidovat jejich stáří a sérii a ty staré chceme začít preventivně vyřazovat sami, pokud zjistíme, že mezi kolapsem disků a jejich stářím je skutečně přímá úměra.

rad bych videl firmu, ktera meni disky podle stari, to by byl snad svetovy unikat. vsude jinde se disky meni az zacnou chybovat nebo zdechnou, data se chrani redundanci a zalohovanim.

[Luk]

Zřejmě je to po ruském vzoru. Pokud vím, tak u ruských letadel (a další techniky) byla běžně předepsaná výměna některých dílů, i když byly v pořádku (a u obdobných "západních" výrobků se neměnilo).

[Jiří (BoodOk) Kadeřávek]

Muzou to prodat jako funkcni, 'lehce' ojety disk. Jeste na tom vydelaji

[vagojan]

Kolik terabajtů dat, na kolika serverech že to spravuješ, s vlastní odpovědností, že si dovolíš takto soudit?

[Rezza]

Seznam uz mam jenom na spam z pochybnych registraci... Vetsinou se setkavam s "Vnitrni chyba systemu", kdyz napisu na technickou podporu, tak reakce nulova (beru sluzba zadara, ale muzou byt radi, ze jim nekdo nahlasi bug, ne? kdyz sami o to zadaji;) )... I pani mamu jsem naucil pouzivat seznam, ale ve chvili, kdy webove rozhrani delalo co delalo, tak jsem musel preucit na KMail... Nemuzu zase srovnavat s jinyma sluzbama v cechach, radsi jsem ani nezkousel a nebo jsem dobre zmasirovany reklamni kampani seznamu:D Jinak jak uz tu nekdo psal - kopie google map je pekna, databaze firem teze, ale zbytek sluzeb uz za moc nestoji...