Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
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 ...
V našem "kapřím" rybníku je pořád štikou, ne? Kde neni (až taková) poptávka, nebude nabídka.
$ 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
$ 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
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
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
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
[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 msa proc to neobratit v neco jineho ze ? :)
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 5A koukám, že google je na tom o kus líp
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
Nelibi nepouzivej, nepomlouvej
? To neni vtip?
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).
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í.
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.
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.
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.
du -sh Maildir/ 658M Maildir/
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.
Tiskni
Sdílej: