Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Vývojáři poštovního klienta Mozilla Thunderbird plánují implementovat funkci, která usnadní zasílání velkých souborů e-mailem. Tato činnost obvykle narazí na limit SMTP serveru, který velkou zprávu nepřijme. Thunderbird by měl tento problém řešit tak, že soubor, který chete poslat, nahraje na server, příjemce obdrží odkaz a soubor si může stáhnout. Zatím není jasné, ve které verzi se funkce objeví. Zdroj: mozilla.cz.
Tiskni
Sdílej:
Hm, zase super kecy nějakého chytráka,zato ty jsi sežral kopec chytrý kaše ... nebo tě platí Mozilla Foundation? já nehodnotím, jestli je posílání velkejch douborů mailem dobře nebo špatně já mluvím o tom, že zase někdo vynalejzá hranatý kolo, a sere na to, aby podporoval to kulatý, který je tu "odjakživa" - konkrétně RFC2046 část 5.2.2
který chce rozesílat mailem obří nesmysly,já osobně nechci (mám na rozdávání tak akorát fotky, který stejně dávám do galerie na webu i s popiskama - zpracování metadat uloženejch přímo ve fotkách taky kulhá na obě nohy), ale jestli sis nevšiml, tak doba pokročila ... tak jako Česká pošta dnes umí balík do jedné tuny, namísto nějakých patnácti kilo či kolik byl před lety limit, tak i internetová infrastruktura dnes zvládá více než kdysi dálnopis jinými slovy, je na ISP a poskytovatelích služeb, co umožní, jestli např. smtp servery Seznamu mají limit 10 MiB (nebo už víc?), tak tím Seznam říká, že takovou věc kapacitně zvládá, a nevidím důvod to nepoužít pokud chci, a proč by nějaký mailový klient měl kecat do smlouvy mezi mnou a mým poskytovatelem mailu
a zbytečně zatěžovat servery rozesláním zároveň padesáti lidem, z nichž třicet pět to zahodí rovnou a dalších deset neotevře dřív než za týden, namísto poslání odkazu, ze kterého si to stáhnout akorát ti, kteří to fakt chtějí,to jsou zase kydy ... nebylo by snad efektivnější vysvětlit odesílateli, že to nemá posílat těm, co o to nestojí, než vymýšlet finty, aby nemohl poslat, to co chce poslat?
a navíc postupně,jo, to je úžasná výhoda ... takže místo toho, aby se to lidem natlačilo hned, tak se bude čekat, až k tomu přijdou - jinými slovy, místo aby se mi mail stahoval někde na pozadí, a v okamžiku, kdy mi cinkne jako přijatý, tak jsem se na tu věc mohl rovnou podívat, tak namísto toho kliknu na odkaz a budu půl hodiny čekat, než se to stáhne, to bude moc cool :-/
a kdyby se před dvaceti lety naučil ftp nebo jiný protokol, který je určen k přenosu velkých souborů, nemusel by teď plácat o vaření kafeděkuji umím - jenom mi ještě nikdo nevysvětlil, jak mám zajistit, aby příjemce měl v době odeslání ftp server nahozený, přístupný (v dnešní době NATů ...), a o mnou nahraném souboru se dozvěděl, včetně průvodního dopisu, aniž bych mu musel paralelně posílat mail, do kterého to teda už rovnou můžu připojit ... což mimochodem vede na níže zmíněné, on snad ten TB bude poskytovat vlastní úložiště, anebo půjde přes nějaké obecné služby typu Úschovna, takže místo aby člověk šel rovnou na danou službu, tak se akorát bude zbytečně otravovat s TB jako prostředníkem? a když jsme u těch cizích služeb a prostředníků ... co podepisování a šifrování? - to sice můžu zajistit na úrovni souboru, co nahrávám, ale není to tak trošku pruda to ještě prohánět nějakým udělátorem, co mi soubor zašifruje a připojí podpis, když v rámci mailu to funguje tak nějak "samo"?
je na ISP a poskytovatelích služeb, co umožní, jestli např. smtp servery Seznamu mají limit 10 MiB (nebo už víc?), tak tím Seznam říká, že takovou věc kapacitně zvládá, a nevidím důvod to nepoužít pokud chci, a proč by nějaký mailový klient měl kecat do smlouvy mezi mnou a mým poskytovatelem mailuKdyž se vejdeš do toho limitu, tak ty přílohy klidně posílej. Ale když se do něj nevejdeš a obcházíš ho tím, že rozdělíš přílohy do spousty mailů, tak už se asi dostáváš do mezí, které poskytovatel kapacitně nezvládá (nebo nechce zvládat) a jen to nedokáže snadno detekovat (jedna velká zpráva se pozná a odmítne snadno – deset menších zpráv poslaných po sobě už hůře, protože tam si musíš držet stav – kolik toho daný uživatel poslal např. za poslední hodinu). Předpokládám, že ta hranice, od které se mají přílohy vkládat někam na web místo do mailu, půjde nastavit v Thunderbirdu, případně půjde tahle funkce úplně vypnout.
kliknu na odkaz a budu půl hodiny čekat, než se to stáhnePokud bych měl čekat půl hodiny, tak fakt nechci, aby se mi takové objemy stahovaly do schránky – abych je mohl smazat/ignorovat, aniž by se ta data přenášela.
Když se vejdeš do toho limitu, tak ty přílohy klidně posílej. Ale když se do něj nevejdeš a obcházíš ho tím, že rozdělíš přílohy do spousty mailů, tak už se asi dostáváš do mezí, které poskytovatel kapacitně nezvládá (nebo nechce zvládat) a jen to nedokáže snadno detekovat (jedna velká zpráva se pozná a odmítne snadno – deset menších zpráv poslaných po sobě už hůře, protože tam si musíš držet stav – kolik toho daný uživatel poslal např. za poslední hodinu).hm, takže poslat dest samostatných megových mailů můžu, ale poslat jeden desetimegový rozdělený do deseti částí nemůžu?
Pokud bych měl čekat půl hodiny, tak fakt nechci, aby se mi takové objemy stahovaly do schránky – abych je mohl smazat/ignorovat, aniž by se ta data přenášela.píšu to už potřetí ... pokud ty data nechceš, tak ti je předně nemá nikdo posílat mimochodem, ty máš na svém primárním připojení nějaký datový limit?
píšu to už potřetí ... pokud ty data nechceš, tak ti je předně nemá nikdo posílatTohle rekni vsem spammerum, urcite ti prestanou posilat nevyzadanou postu :D
ale poslat jeden desetimegový rozdělený do deseti částí nemůžu?
Kdo ti v tom brání? Ale přijde mi to jako obcházení pravidel (jestli jsou špatná – např. velikostní limit přílohy 5 MB – tak by se měla změnit ta pravidla, než je obcházet).
pokud ty data nechceš, tak ti je předně nemá nikdo posílat
A co když odesílatel (byť je vychovaný a myslí to dobře) neví, zda tu přílohu budeš chtít nebo ne – pak má možnosti:
Každá ta možnost má nějaké vady na kráse – přitom by to šlo elegantně vyřešit tak, že by uživatel „vložil přílohy“ a u některých zaškrtl, že jsou „volitelně ke stažení“ a e-mailový klient by pak použil nějakou službu (ať už dané firmy/organizace, nebo u poskytovatele, nebo u třetí strany) pro uložení těchto příloh. A klient na druhé straně by ty odkazy (přílohy s metadaty o příloze) interpretoval uživateli opět jako přílohu (třeba s nějakou ikonkou nebo poznámkou, že je potřeba ji teprve stáhnout) a pro něj by to fungovalo jako obyčejná příloha, jen by se ta data přenášela, pouze když jsou potřeba. Viz #21
řekl jsem, že mi v tom někdo reálně brání? - já se pouze ptal, jak to tedy myslíš ...ale poslat jeden desetimegový rozdělený do deseti částí nemůžu?Kdo ti v tom brání?
Ale přijde mi to jako obcházení pravidel (jestli jsou špatná – např. velikostní limit přílohy 5 MB – tak by se měla změnit ta pravidla, než je obcházet).taková změna pravidel by ovšem nejspíše vyžadovala investice ... ještě jednou, když pošlu deset mailů po jedné fotce, tak to bude oukej, a když deset fotek pošlu v jednom mailu, a program to rozdělí a v cíli to zase spojí, tak už to oukej nebude, bude to "obcházení pravidel"? - WTF?
A co když odesílatel (byť je vychovaný a myslí to dobře) neví, zda tu přílohu budeš chtít nebo neno tak to je přesně případ, kdy je nemá posílat - není v tom případě zbytečným zatěžováním serverů a linek, proti kterému tady všichni tak brojí, už jen to, že to vůbec někam uploaduje, aniž by věděl, zda o to někdo bude stát?
taková změna pravidel by ovšem nejspíše vyžadovala investice ...Myslíš jako odložit hrnek s kafem, otřít si ruce do kalhot a změnit jednu položku v konfiguraci Postfixu?
ještě jednou, když pošlu deset mailů po jedné fotce, tak to bude oukej, a když deset fotek pošlu v jednom mailu, a program to rozdělí a v cíli to zase spojí, tak už to oukej nebude, bude to "obcházení pravidel"? - WTF?Stále to bude obcházení pravidel, ale nebude to provozovatel serveru mít nějak ošetřené*. (ošetřit je to trošku složitější než kontrolovat velikost jedné zprávy – musím si držet stav, kolik toho uživatel poslal v daném dni nebo hodině) Poslat ručně přílohy v deseti mailech představuje pro uživatele jisté úsilí, což znamená, že se velká část z nich na to vykašle – a těch ostatních bude málo, takže to servery tohle jejich obcházení pravidel v klidu ustojí. Ale když bude běžný e-mailový klient umožňovat vložení přílohy 100 MB (nebo víc) a její následné rozdělení na X mailů – tím, že uživatel jen zaškrtne nějaké políčko, tak toho lidi budou posílat mnohem víc. A pak jako poskytovatel musíš koupit silnější konektivitu, posílit servery, nebo kontrolovat, kolik toho který uživatel během nějakého časového úseku poslal – a co bude nad limit, to odmítnout. Takže příjemci pak dorazí třeba první desetina fotek z dovolené nebo CD obrazu (protože SMTP neumí transakce). E-mail prostě beru jako službu s relativně nízkou latencí (obvykle vteřiny nebo maximálně jednotky minut – což je taky důvod, proč zrovna nemusím greylisting, byť je to dost účinná metoda proti spamu), relativně vysokou spolehlivostí (zpráva téměř vždy dorazí, neztratí se, v nejhorším případě se vrátí odesílateli – byť to samozřejmě má daleko třeba k dvoufázovému commitu v relačních databázích) pro relativně důležité zprávy. A do této představy mi právě moc nezapadá posílání velkých příloh, které můžou snadno zahltit servery (nebo ty špatné dokonce shodit), zpozdit zprávy ostatních nebo třeba někomu DoSovat schránku (když bude plná a on bude čekat důležitý e-mail). A líbil by se mi BFU-přátelský přístup, kdy uživatel může vzít třeba půlgigové video, přetáhnout ho myší do poštovního klienta a „sdílet“** ho s ostatními – aniž by při tom zahltil poštovní servery (které mají důležitější věci na práci) nebo zaplnil lidem schránky. O sdílení by se transparentně postaral poštovní klient a pro uživatele by to bylo stejně jednoduché a pohodlné, jako kdyby ostatním poslal obyčejnou přílohu. *) což neznamená, že se to neprojeví – např. bude chodit ostatním pomaleji pošta. **) místo aby k tomu musel používat nějaké pošahané centralizované sociální sítě
A kdo bude chtít posílat i větší přílohy e-mailem, ten si tuhle funkci vypne a bude si je posílat.nebude, protože mu to smtp server odmítne, a klienti dělení a spojování moc nepodporujou (abych nepomlouval jenom Thunderbird, tak třeba ani kmail to neumí)
Další, co si myslí, že mail slouží k posílání souborů?viz výše - další, co by Českou poštou povolil jen posílání pohlednic?
1) Když by šlo pár stovek v mailu rozkouskovaný na desítky příloh, tak antivirový filtr na mailserveru by dostával pěkně zabrat, resp. celý mailserver (mnohem větší zátěž a mnohem menší průtok mailíku / min)sorry, ale této úvaze opravdu nerozumím samozřejmě, že zátěž serveru záleží na tom, co přes něj teče zakážeme posílat maily úplně, aby nám všechny ty stroje krásně idlily? vycházím z toho, že odeílatel chce k příjemci ty data nějak dostat - takže teda místo mailserverů bude zatěžovat nějaký http servery, ok, kde teda máme tu úsporu prostředků?
Nehledě nato, že by spaměři mohli pěkně sundat server tím, že by ucpaly lajnu, což jde v případě zasílání gigových příloh jedna dva.opět nerozumím ... jak jedna rozdělená gigová příloha ucpe lajnu "jedna dva", zatímto 1024 megových ji neucpe?
2) Když by jsi nepoužíval antivir na mailserveru, tak by ti to zabíjel antivir na lokálu (chápu, máš linux, antivir nepoužíváš, ale co zbylá populace?)jednak jsem si nějak nevšiml, že by se antivir na serveru nějak vylučoval s antivirem na lokálu a jednak pořád je potřeba ty data zkontrolovat, a pro antivir je snad jedno, jestli to udělá při otevření mailu nebo při stažení jiným protokolem
3) Řešení Mozilly je možnost volby,fakt? - no já jsem si nějak nevšiml, že by výše zmíněný standard už spolehlivě podporovali, takže jakouže mi dávají tu druhou volbu? ... ale dost možná mám špatné informace, TB nepoužívám, třeba už to umí?
tvoje řešení je nemít volbu,"moje" (ehm!) řešení ti nějak upírá možnost volby jít na uschovna.cz, ten soubor uploadnout a nechat příjemci poslat email s odkazem?
Pokud nechápeš, tak jako příjemce pak nemáš možnost volby odmítnout takový mail, rovnou se ti nasáčkuje do mailboxu, nebo tobě na PC (za předpokladu, že syncuješ). Tudíž někomu by stačilo, aby ti poslal pár domácích kousku videí, nebo pár iso obrazů, což by ti zabilo mailbox a přestaly by ti chodit maily. Nebo by ti nějaký spamer mohl sejmout veškeré volné místo na hdd, nebo by ti mohl sejmout celou tvojí internetovou konektivitu jedna dva. a to nemluvím o uživatelých 3G, cdma apod.ano, jistě, a to všechno uvedené v současnosti nikdo nemůže docílit prostým posláním více mailů místo jednoho rozděleného, LOL
Nějaké řešení se samozřejmě nabízí ve stahování pouhých hlaviček a zbytek nechávat na serveru, ale i tak je to prostě celkově koncept na dvě věci.to je koncept vhodný pro omezené připojení na telefonu mě spolehlivě "zabije" stokilovej mail, na to mi nikdo nemusí poslat image dvdčka - takže jakej dáme limit, od kterýho se mi to nemůže poslat, 160 znaků jako u sms? - ještě bysme neměli zapomenout zapojit nějakou službu na zkracování URL, aby ten odkaz náhodou nebyl příliš moc poslanejch dat
tak zmáčknout delete nad tím stokilovým mailem mě stojí stejnou práci, jako to zmáčknout nad tím gigovýmJenže ta data se musela zbytečně přenést a zatížit síť. Můžeš se samozřejmě snažit vychovávat uživatele, aby neposílali zbytečné přílohy někomu, kdo o to nestojí, to je v pořádku, ale i když se ti to povede, často prostě nemůžeš rozhodnout, zda příjemce tu přílohu bude chtít vidět nebo ne – do hlavy mu nevidíš, to bys mu musel předem zavolat nebo poslat e-mail: „hele, můžu ti poslat to a to?“ počkat, až ti odpoví a pak mu to poslat. Dejme tomu, že chceš poslat video z konference všem účastníkům – ale jen někteří se na něj budou chtít podívat, jenže ty nevíš, kteří to jsou. Jako přílohu by to video dala leda hodně otrlá povaha (a ostatní by mu za to nepoděkovali). Takže se to většinou řeší tak, že soubor pověsíš někam na svůj web, zkopíruješ si odkaz, vložíš ho do e-mailu a pošleš. Přitom by to mohlo být krásně automatizované – mohlo by tu být API pro ukládání velkých souborů, e-mailový klient by ho zavolal, vložil soubor, obdržel odkaz a vložil ho do e-mailu. Ideálně jako přílohu, která by obsahovala nejen URL, ale i další metadata jako název souboru, popis, velikost, hashe atd. A klient na straně příjemce by tuhle přílohu „rozkódoval“ a stáhl přílohu ze serveru. Běžný uživatel by byl od tohoto procesu úplně odstíněný – pro něj by to bylo pořád stejné jednoduché „pošlu přílohu e-mailem“ nebo „dostal jsem zprávu s přílohou“ a zároveň by se nepřenášela zbytečná data. Ještě lepší by bylo použít Torrent místo HTTP – když pošlu stejnou přílohu dvěma lidem ze stejné organizace, tak přes HTTP by se to stahovalo dvakrát, zatímco v případě Torrentu by si ten, kdo přílohu otevřel později, mohl stáhnout od svého kolegy v rámci LAN. Takovou úschovnu (HTTP, Torrent atd.) by mohla mít každá organizace vlastní, takže by se nemuselo spoléhat na třetí stranu a nechat se otravovat jejich reklamou.
This mechanism can be used when intermediate transport agents limit the size of individual messages that can be sent.Vždyť to slouží skutečně k tomu obcházení pravidel, která někdo jiný stanovil – zřejmě proto, že jeho server větší objemy nezvládne. A když se začne hromadně obcházet, tak on bude muset nasadit složitější pravidla. Přijde mi to podobný kolotoč jako firewally – někdo zakáže porty pro ICQ aby zaměstnanci nechatovali a oni začnou chatovat přes HTTP, to se zakázat nemůže, tak se místo jednoduchého firewallu musí nasadit složitější, který kouká dovnitř HTTP protokolu, analyzuje požadavky a některé zahazuje (místo aby stačila obyčejná kontrola portů). Nakonec se na obou stranách vyplýtvá hodně energie (implementace tunelů a složitých firewallů) a přesto se to stejně nějak protuneluje – nebo naopak zarazí – podle toho, která strana má zrovna navrch. U těch firewallů je to často nesmyslná buzerace… Ale u těch velikostních limitů to bývá docela racionální pravidlo vycházející z technologických omezení – naše servery a linky víc neutáhnou a chceme raději spolehlivé doručování malých e-mailů než nespolehlivé doručování velkých.
Eh? Už vidím, jak ti jeden uživatel kouskuje a posílá 1024 souborůpsal jsi původně "že by spaměři mohli", takže co do toho zase taháš obyčejného uživatele, co podle tebe neumí poslat 1024 souborů?
a když ano, tak né najednou. A o tom to jezajímavé ... a hele víš o tom, že Outlook to dovoluje už léta? - můžeš mi tedy poreferovat o nějakých těch konkrétních z právě tohoto důvodu zabitých serverech?. Dovolením větších příloh, popř. automatického rozkouskování, by servery zabíjelo.
no tak to fakt nechápu jak si podle tebe příjemce může vybrat, jakým způsobem mu to odesílatel pošle?"moje" (ehm!) řešení ti nějak upírá možnost volby jít na uschovna.cz, ten soubor uploadnout a nechat příjemci poslat email s odkazem?Pokud jsi nepochopil, ač jsem to jasně napsal, jedná se o možnost volby příjemce, nikoli odesílatele.
ehm, mluvil jsi o spammerechano, jistě, a to všechno uvedené v současnosti nikdo nemůže docílit prostým posláním více mailů místo jednoho rozděleného, LOLAno, nemůže, protože jednak ti uživatel
ten mail nerozkouskuje na 100 (s tím se nikdo babrat nebude),viz výše, to si vážně myslíš, že když to neumí ThunderBird, tak to neumí nic?
další regulace je na straně serveru, kdy se dá v pohodě žít s omezením počet emailů / min / IP apod. (takže toto částečně eliminuje nadměrnou zátěž, i když si to ten klient bude chtít kouskovat, ale i tak tam bude),WTF? nejdřív si argument sám popřeš, a pak napíšeš, že stejně platí?
kde by byly takové limity v případě big souborů stejně na nic.smím se zeptat proč?
Taktéž si nejsem zcela jist, zda vůbec víš, jak funguje antivir na mail serveru a co se s tím mailem děje.poslyš, a na kterém serveru myslíš? - ne, vážně nevím, jak je každý jednotlivý mailserver nakonfigurován ...
Protože pak by to mohlo jít do stádia, kdy server s 10GB ramkou dokáže obsloužit třeba jen 10 klientů, nehledě na rychlost obsloužení.viz výše - opravdu je to, že mailservery neklekají, jen a pouze zásluha TB, když odmítá tento standard implementovat?
Vážně by ti nevadilo, kdyby ti někdo poslal mailem třeba 1TB dat?mno, trošičku ano - jenom stále nechápu, proč se pokoušíš argumentovat, jako kdyby mi nikdo nemohl za současné situace ten terabajt dat mailem poslat ...
Tzn, že schránku by jsi měl zaplněnou a pak by jen maily seděly ve frontě u senderu a čekaly by na uvolnění schránky, nebo by se vůbec nedoručily. Takže co je podle tebe lepší? Když ti půlka mailů zabije mailbox a zbytek se nedoručí, nebo když ti půlka mailů zabije mailbox a pak ho budeš muset pravidelně promazávat další půl den, protože po jednom smazání se ti opět celý zaplní poštou, která je ve frontě?opět nemám jinou reakci než WTF? jak jsi přišel na to, že nerozdělené maily se nedoručí a nebudou sedět ve frontě, zatímco rozdělené v té samé frontě čekat budou, případně že se po zaplnění inboxu neodmítnou stejně jako ty nerozdělené?
Jinak obyčejné uživatele můžeš učit co chceš, ale spammer zůstane vždy spammerema můžu se aspoň pokusit naučit tebe rozmyslet si, jestli tedy argumentuješ spammery nebo obyčejnými uživateli?
Obratem jsem odpovedel, jestli je zapotrebi vyvynout nejake nadlidske usili k tomu, aby tato vyzva byla napsana rovnou do mailu, kdyz uz tam byla iformace o nutnosti precteni prilohy, nez aby se to muselo extra psat do prilohy.Asi áno. Vďaka funkcii "poslať tento dokument mailom" (File->Send to) v MS Word-e. Snáď dlho potrvá, než niekto tromfne v tomto smere príhodu, ktorá sa stala mne. Ako reading confirmation mi prišla správa od používateľa Lotus Notes - mail s priloženou "One Note Database" o veľkosti niekoľko sto kB.
Vrchol idiocie je, kdyz mi z jednoho nejmenovaneho uradu prisel mail s prilohou. V mailu bylo napsano, ze si mam orecist prilohu.To je ještě nic není. Já nedávno psal do jednoho obchodu (dotaz na dostupnost a cenu zboží) a přišel mi od nich e-mail s předmětem „Dokument1“ ale text zprávy úplně chyběl a místo toho tam byla příloha „doc1.docx“, ve které byl jejich dopis (beztak tu věc měli o tisícovku dražší než jinde, celkově lameřina).
dop*dele, mail je nahrada za dopisyJá nedávno použil přesně tenhle argument na osobu, která se pokoušela oeslat asi třistamegový soubor e-mailem, přitom onen soubor nejspíš ani neprošel SMTP serverem jejich poskytovatel, protože na náš mailserver nic nedorazilo (logu jsem kontroloval). Když se divila, proč to nejde poslat, tak jsem se jí zeptal, jestli by pračku posílala tak, že by jí zkusila vecpat do poštovní schránky
... Fakt bych takovehle lidi trestal rakoskou do chodidel.Moc mírný trest ... lidé, co tohle dělají, by si zasloužili minimálně samostatné oddělení pekla (výběr vhodného trestu je ponechán na zvrhlosti čtenáře).
Ale musím říct, že se mi moc líbí, že ať se udělá to, či ono, pokaždá se najde dost lidí, kteří to zkritizují a ještě nutí ostatním něco, co si sami myslí, že je správné a ještě jim nadávají... Materiály, ze kterých jsem čerpal: http://www.abclinuxu.cz/zpravicky/thunderbird-zpristupni-posilani-velkych-souboru#1já bych si tedy s dovolením vyprošoval být prvním příkladem k tomu "nutí" a "nadávají" kritika, to ano, a považoval bych za velmi nešťastné, kdyby všichni jenom tupě přitakávali a schválili kdejakou blbost, jen aby se někdo necítil pohoršen nesouhlasem ale kde vidíš, že bych někomu něco nutil? - považuješ snad za nucení to, že jsem vyjádřil nelibost nad tím, že namísto podpory standardů se vymýšlí nové blbosti? ... nebo to, že jsem následně několikrát odpálkoval pseudoargumenty proti použití toho standardizovaného řešení (přičemž jsem se zároveň ale několikrát vyjádřil ve smyslu, že posílání extra velkejch souborů nepodporuju)? a co se týče nadávání, rovněž, kde to v tom vidíš, nebo seš přecitlivělej a vadí ti, že jsem RFCčka označil slovem "blbejch" místo "docela jednoduchých"?
bral jsem ho spíše jako jakýsi "baseline" jedné části názorůmno ... ale nic
"zato ty jsi sežral kopec chytrý kaše ", tak to už bych za trochu pejorativní považoval...jistě, ale to je již v kontextu reakce na "super kecy nějakého chytráka", tedy někde úplně jinde než v reakci na kterou jsi odkazoval
http://www.abclinuxu.cz/clanky/komiks-xkcd-949-prenos-souboruPodle popisku obrázku jsem to jeden čas taky dělal