Gmail dobobtnal na 7000 MB

Gmail neustále navyšuje maximální velikost emailových schránek, dnes přesáhla největší možná velikost schránky 7000 MB.

5.8.2008 17:34 | houska | IT novinky

Komentáře

[Pavel Půlpán]

Pochybuju že to někdy využiju ale je to milý.

[Limoto]

Tak nějak

[Käyttäjä 11133]

You are currently using 1515 MB (21%) of your 7000 MB.

Pokud jednou přestane narůstat, tak mi asi místo dojde :D

[Dalibor Smolík]

Momentálně používáte 2179 MB (31 %) z dostupných 7002 MB.
jsem na tom podobně

[Anmov]

Ach jo, mě ten Google asi nemá rád - 6997 MB maximálně možných Tam se ještě vejde spamu !

[Grunt]

Spam určitě řeší symlinky.

[tsLnox]

+1

[KS]

Škoda, že bez placení nelze sdílet prostor s Picasa Web Albums.

[Luk]

Picasa Web Album je lemra líná (jako asi 90 % podobných webových alb). Nesnáším javascriptové chrlení!

[Daniel Kvasnička ml.]

No ale ve spojeni s Picasou je to zdaleka nejlepsi reseni sveho druhu dostupne pro Linux... IMHO Dobra sprava knihovny fotek, upload na par kliknuti. A zas tak pomaly mi ten web nepripada.

[Dan Ohnesorg]

SVN verze digikamu je ve spojeni s Flickrem take zatracene dobre reseni. Mozna o tom nekdy napisu neco do blogu.

[Daniel Kvasnička ml.]

Dela digiKam to, co Picasa -- ze neaplikuje zmeny na fotky primo, ale uklada je separatne, takze je mozny plny navrat historii zmen az k 100% puvodnimu obrazku? To je pro me u Picasy killer feature.

[phero]

Toto urcite dela i f-spot, ktery umoznuje nahravat fotky na radu ruznych serveru. Sam ho pouzivam a vyhovuje, ale nema tak hezky UI jak picasa.

[Spike]

To dělá i iPhoto, ale to má ve své knihovně vůbec nějaký bordel. Občas najdu zkopírované celkem nepochopitelně fotky, na kterých jsem nedělal žádné úpravy, často mi tam pak taky straší dávno smazané fotky… A knihovna bobtná a bobtná…

Musím říct, že by se mi celkem líbilo, kdyby desktopové aplikace sloužící ke stejnému účelu sdílely svoje data – ať už jde o správce fotoalb, nebo o e-mailové klienty, historie a záložky v prohlížečích… Možná za pár (desítek) let nebude problém přecházet mezi různými programy/desktopy.

[Daniel Kvasnička ml.]

To dělá i iPhoto

Aaale... to je dobra zprava. Zrovna vcera jsem tak uvazoval co a jak, kdybych se rozhodl pro MacBook (kazdopadne cekam na podzim na ty nove modely) a jedna z nejvetsich prekazek byl prave nedestruktivni prenos tech dat z Picasy do iPhoto. Tzn. je teoreticky mozne napsat treba skript, ktery ta data z Picasy prevali do formatu iPhoto?

[Käyttäjä 11133]

Musím říct, že by se mi celkem líbilo, kdyby desktopové aplikace sloužící ke stejnému účelu sdílely svoje data – ať už jde o správce fotoalb, nebo o e-mailové klienty, historie a záložky v prohlížečích… Možná za pár (desítek) let nebude problém přecházet mezi různými programy/desktopy.

Další brzda vývoje?

[Spike]

Proč by měla?

[Käyttäjä 11133]

Proč? Vezměme třeba ty fotky... Řekněme, že máš fotku, která se vždy ukládá jako originál a potom máš nějaký soubor (třeba XML, je to celkem fuk), který obsahuje posloupnost filtrů, které se na ni mají aplikovat. V případě, že vývoj aplikací pro editaci fotek zamrzl (pro zjednodušení uvažujme jen 2 editory) tak je to poměrně snadné, obě aplikace mohou používat stejné tagy se stejnými parametry pro označení stejných filtrů... Jenže ve chvíli, kdy jsou tyto editory aktivní, tak je zde problém... Existuje určitá množina tagů a parametrů, která je pro oba editory společná, ale nově vyvíjené tagy pro manipulaci s obrazem již stejné být nemohou, neboť může nastat situace editor A transformaci podporuje, editor B transformaci nepodporuje. Může také nastat situace kdy autoři obou editorů dostanou nápad na stejnou transformaci ve stejnou chvíli (nemusí být úplně stejná, stačí když to bude v dostatečně krátkém intervalu, aby to nestihli zkontrolovat, jestli konkurence pracuje na něčem obdobném), pak je zde vysoká pravděpodobnost, že si ji každý pojmenuje jinak a bude u ní mít jiné parametry. Jistě při naší zjednodušené situaci kdy jsou na trhu jen 2 editory je přece snadné aby se spolu domluvili, ale s rostoucím počtem živých editorů pravděpodobnost takové shody klesá a nakonec by musela vzniknout nějaká organizace, která by se zabývala tvorbou "formátu, který definuje manipulaci s obrázky" a pokaždé když by některý z tvůrců editorů chtěl přidat novou vlastnost, která se musí promítnout do formátu souboru, tak by musel žádat tuto organizaci aby formát rozšířila, což sebou nese jistou nenulovou časovou prodlevu, která jako taková musí brzdit vývoj.

[Drom]

No, proto jsou dulezity standardy a jejich aktualizace.

[Käyttäjä 11133]

Jenže standardy obecně brzdí pokrok jednoho konkrétního produktu, který by se bez jejich dodržování mohl mnohem rychleji a dynamičtěji vyvíjet.

[Michal Vyskočil]

Jenže standardy obecně brzdí pokrok jednoho konkrétního produktu, který by se bez jejich dodržování mohl mnohem rychleji a dynamičtěji vyvíjet.

Musíš zvolit metodu w3c, nebo standardizační komise pro C++ - chrlit tolik, nejlépe těžko implementovatelných standardů - že to nikdo nebude stíhat dobře implementovat .

[Spike]

Ale tam se neukládají žádné tagy filtrů, ale prostě originální a upravená fotka a (i kdyby) vůbec to nevidím jako nějakou brzdu vývoje, jako spíš jeho zcela přirozenou součást. Jednou k tomu prostě dojít musí.

[Limoto]

Musím říct, že by se mi celkem líbilo, kdyby desktopové aplikace sloužící ke stejnému účelu sdílely svoje data – ať už jde o správce fotoalb, nebo o e-mailové klienty, historie a záložky v prohlížečích… Možná za pár (desítek) let nebude problém přecházet mezi různými programy/desktopy.

Jenže to je blblost, protože kdyby potom chtěl třeba novej e-mailovej klient použít lepší formát ukládání (rychlejší, úspornější..), tak by nemohl. Takže kdyby se tohle někdy povedlo, stejně by to dlouho nevydrželo.

[Filip Jirsák]

Ještě že to nevědí všichni ti, kteří do e-mailových klientů implementovali podporu mbox a Maildir formátů. Není nutné, aby aplikace podporovala jediný formát – může podporovat nějaký univerzální, kterému budou rozumět i ostatní aplikace, a pak může mít svůj vlastní, nejrychlejší a nejlepší na světě.

[Spike]

Dík. :)

Problém je v tom, že dneska, i když ti e-mailoví klienti třeba podporují ten mbox nebo Maildir, tak si tahle data „syslí“ ve svém adresáři s nastavením, kde podle mě nemají co dělat.

[Käyttäjä 11133]

Ty nemáš symbolické odkazy, nebo kde je problém?

[Spike]

Problém je v tom, že je to otrava, když to může prostě fungovat.

[Tomáš]

Proto jsem si doma rozjel na desktopu trochu perverzně IMAP server a mohu používat tolik email klientů, kolik se mi zlíbí.

[KS]

Nevšiml jsem si.

[Luk]

Hmmm, spousta lidí si nevšimne. Stejně jako si nevšímají, jak pomalé je GTK

[Spike]

Ono je pomalé?

[J. M.]

No tak samozřejmě všechno je relativní. Třeba osmdesátelitý tlusťoch-cukrovkář po mrtvici uběhne stovku za 15 minut, což se může zdát pomalé. Ale v porovnání s takovým hlemýžděm je kolikrát i patnáctkrát rychlejší. Čili nezavrhujme tlusťocha GTK+, všechen software má někde v něčem nějakého svého hlemýždě útěchy.

[Luk]

No, pokud mám čekat desítky vteřin na načtení seznamu souborů do dialogu pro otevření souboru, tak GTK+ s klidným svědomím zavrhnu.

[Grunt]

A nebude to spíš tím, že se parsuje velké množství i-nodů?

$ time ls

real    0m6.838s
user    0m0.020s
sys     0m0.072s

[Luk]

Ne. Nejednou se tu o tom vedla obšírná diskuse. V jejím rámci někteří lidé (včetně mě) prováděli určité testy, a to se zajímavými výsledky.

[Daniel Kvasnička ml.]

A je to tady

[Luk]

Nemohl jsem si to odpustit. Ale mohu si kopnout i do Qt (ohledně výkonnosti), pokud by bylo libo

[J. M.]

To já bych si dal říct. Jen kopej, kopej do nich. Však ono to s nimi stejně nehne.

[Luk]

Jen kopej, kopej do nich.

Dobře. Tak třeba třída QBuffer. Nechť ji člověk používá dle libosti v souladu s dokumentací. Pokud bude mít smůlu, stvoří neskutečně plazivý program, který bude většinu času trávit přemísťováním paměťových úseků (memmove()).

[Heron]

Hmm, optimální velikost je nekonečno. Alespoň v mojí schránce je volného místa méně a méně.

[brk]

Docela by mne zajímalo, na kolik to je dimenzováno reálně. O tom, že to nebude počet uživatelů x 7GB se asi nemá cenu moc bavit, ale bude to desetina, dvacetina?

[Pavel Půlpán]

Že by nějaký průměr současného využití krát počet uživatelů plus rezerva?!

[pc2005]

Třeba to mají komprimované.

[Pavel Půlpán]

Že by nějaký komprimovaný průměr současného komprimovaného využití krát počet komprimovaných uživatelů plus komprimovaná rezerva?!

[tsLnox]

Ty jsi komprimovaný? Já nechci být komprimovaný, honem mě dekomprimujte

Krásně řečeno ;)

[Pavel Půlpán]

Možná tak kompromitovaný... ale teprv od minulý soboty!

[Jindra]

Být Microsoftem, tak vymyslím nějaké využití pro tuto kapacitu. Myslím, že ten ukazatel maximální velikosti by rychle nabral o trochu jiný směr. Stejně jako akcie Googlu

[quanti]

neusále :)

[Luboš Doležel (Doli)]

Opraveno, díky.

[Drom]

No jo, uzivatele uz nemaji kam davat zabavny videa a super vtipky?

[freshmouse]

Přesně. Za to bych zabíjel...

[Václav "Darm" Novák]

Stačí párkrát poslat tam kam slunce nesvítí a oni daj pokoj…

[Grunt]

Umlčíš jednoho a vynoří se dalších deset co nemají nic na prácí.

[Luboš Doležel (Doli)]

Mám pocit, že nejvíc takových hloupostí posílají státní zaměstnanci a lidé na vyšších postech ve firmách. Aspoň takto to vypadá z toho, co vidím a co mi někdy přijde.

[Grunt]

S těmi já bohužel/naštěstí ještě nemám zkušenost. Mě nejvíc otravovali puberťáci co prostě nemají co na práci. Zase to má jednu výhodu. Dá se uložit od každého jedno, zbytek nasymlinkovat a dá se nabízet schránka o 7GB.

[manasekp]

You are currently using 522 MB (7%) of your 6997 MB.

me treba kapacita gmailu nejak netrapi

[Xeelee]

You are currently using 308 MB (4%) of your 7001 MB

Nápodobně

[Käyttäjä 11133]

TO jsem fakt jediný který má zaplněno více než 1/5? A přitom tam nemám žádná "vtipná videa".

[Xeelee]

A co tam v tom případě máš? Hafo obrázků, „vtipné prezentace“, hudbu nebo jen pár set GB textu?

[Käyttäjä 11133]

Hafo obrázků

Obrázků tam nebude víc než 10MB,

„vtipné prezentace“

maximálně tak 2-3

hudbu

pokud je mi známo tak jednu písničku o velikosti 5MB

jen pár set GB textu?

A co tam v tom případě máš?

Úplně normální e-mailovou konverzaci za posledních několik let, odpovědi z bugzilly, maily z pár mailových konferencí.

[Käyttäjä 11133]

Průměrná velikost je 26KB/konverzace... Bohužel nevím jak zjistit počet mailů, umím zjistit jen počet konverzací :-/

[miso]

Bohužel nevím jak zjistit počet mailů, umím zjistit jen počet konverzací :-/

python:

import getpass, poplib
M = poplib.POP3_SSL('pop.gmail.com')
M.user('username')
M.pass_('password')
len(M.list()[1])

[Deleted [8409]]

Řekl bych, že stačí nějaký bouřlivý mailing list

[Heron]

Neboj nejsi:

You are currently using 2742 MB (39%) of your 7002 MB

Všechno čisté emaily.

[m1c4a1]

Momentálně používáte 8 MB (0 %) z dostupných 7001 MB. :))

[Nicky726]

+1

Dlouhodobě se držím kolem 12% schránky...

[Xeelee]

4 %, ale ještě tak před půl rokem to bylo 6 %. Fakt netuším, čím to volné místo zaplácat. Drtivou většinu nespamoidních mailů archivuji a dnes jsem při příležitosti převzetí Freerunneru vytvořil 45. štítek.

[Käyttäjä 11133]

Já mám 19 štítků...

[JZD]

Mohl byste mi prosím říct, kde najdu kolik štítků jsem vytvořil? Díky.

[Xeelee]

Podíváš se do levého sloupce (nebo do nastavení) a spočítáš je

[Přemek Vyhnal]

Kam to ten Google všechno dává?

[Drom]

To je dost stary...

[Konqui]

To vysvětluje hodně věcí - proč je zemské jádro horké a proč se země točí

[tsLnox]

lol já četl "proč je ženské jádro horké..." taky na tom něco bude ne? ;)

[Jendа]

.thunderbird teď zabírá 97MB. U nejmenovaného mailhostera mám 50MB a stačí mi to. Thunderbird mi zprávy na serveru totiž automaticky promazává. To je zajímavé, že tolik lidí používá webmail. Zkusili jste to někdy přes 19,2kbps modem?

[Tomáš]

Ano, před mnoha a mnoha a mnoha lety jsem začínal s faxmodemem a megarychlosti fax 9600 bps, modem 2400 bps