Richard Hughes oznámil, že službu Linux Vendor Firmware Service (LVFS) umožňující aktualizovat firmware zařízení na počítačích s Linuxem, nově sponzoruje také společnost NVIDIA.
Edvard Rejthar na blogu zaměstnanců CZ.NIC představil svou aplikaci SlideRshow (GitHub). Funguje jako prohlížeč fotek, ale i jako jejich organizér a prezentátor. Neinstaluje se, běží přímo v prohlížeči. Bez serveru. Offline.
Kermit, tj. protokol pro přenos souborů, vznikl před 45 lety. Při této příležitosti byla po 15 letech od vydání poslední stabilní verze 9.0.302 vydána nová stabilní verze 11 implementace C-Kermit. S podporou IPv6.
První verze konverzního nástroje Pandoc byla vydána před 20 lety. Jeho autor John MacFarlane při tomto výročí rekapituluje jednotlivé etapy vývoje a přidávání nových funkcí – rozšíření nejen Markdownu a podporu mnoha dalších formátů.
Srpen přinesl nejen další spalující vedro, ale také Virtuální Bastlírnu s neméně žhavými novinkami. Využijte tedy předpovědi na deštivý čtvrteční večer a od 20:00 se připojte online k tomuto neformálnímu setkání kutilů, techniků a vědců, kde se strahovskými bastlíři proberete nejzajímavější věci, na které jste narazili za poslední měsíc. Pokud jde o novinky, řeč zcela jistě přijde na systém INDX pro tiskárny Průša, který na konci
… více »Firma T-Mobile blokovala „dezinformační web“ AC24 bez toho, aniž by k tomu měla závazný pokyn orgánů veřejné moci. Píše to ve svém rozsudku Městský soud v Praze, který po čtyřech letech uzavřel kauzu blokace zmíněného webu. Operátor musí uhradit škodu ve výši 35 tisíc korun. Advokát společnosti T-Mobile se snažil i u odvolacího senátu argumentovat tím, že firma jednala v dobré víře, když na stránky omezila přístup poté, co ji k tomu vyzvalo
… více »Padla obžaloba v bitcoinové kauze. Státní zástupkyně chce pro Blažka 6,5 roku vězení, pro Titze 8 let.
Z aktuálních globálních statistik společnosti Statcounter: na desktopu má Linux celosvětově podíl 7,53 % (USA 11,92 %, Česko 4,31 %, Slovensko 4,36 %) a Firefox celosvětově podíl 6,51 % (USA 10,86 %, Česko 11,07 %, Slovensko 13,61 %).
Na GitHubu byl publikován seznam 55 kritických bezpečnostních chyb v SQLite s přiřazenými CVE čísly. JFrog Security informuje, že se jedná jenom o AI slop, části kódu na které CVE odkazují, v daných verzích vůbec neexistují. Upozorňuje také, že čísla CVE jsou přiřazována bez ověřování.
Příspěvek na blogu Google Security popisuje, jak tým Chrome Security využívá umělou inteligenci k zásadnímu zrychlení a zlepšení procesu odhalování, třídění a opravování bezpečnostních chyb v prohlížeči Chrome. Díky AI byla nalezena kritická chyba, která byla v kódu přes 13 let. Ve verzích Chrome 149 a 150 bylo opraveno více chyb než v předchozích 23 verzích dohromady.
Já jen dodám, že to je právě ten problém, to přeposílání.Tak tohle lidem zkuste vysvětlit. Přesměrování čehokoliv na Google je přece samozřejmost.
Přesměrování něčeho mimo mailserver je v dnešní době nefunkční věc.Zopakuju, co jsem napsal: tak to zkuste vysvětlit lidem. Přesměrování čehokoliv na Google je samozřejmost.
musí se naladit SRS a další věci (nikdo to na serverech nemá nastaveno) a i tak to nebude ideální.Mám a není
Zejména když se do toho zamotá DMARC, který aplikuje pravidla platná na obálkovou adresu odesílatele na adresu odesílatele ve zprávě.
Pokud mají třeba vlastní řešení, tak zakázat možnost přesměrování na externí adresy, nebo k tomu dát jednoduché poučení, ať to nedělají a nastaví si vybírání.Zakázat - no jestli nám přijdete pomoct se zvedáním telefonů, tak klidně, ale vemte si s sebou tak deset lidí na výpomoc
Dát poučení - nikdo ho nečte.
Proto je v dnešní době nejlepším řešením si nastavit automatické vybírání schránky.Mně přijde nejlepší řešení dát přeposílající server/obálkovou adresu do allowlistu. Jenže to by Google nesměl být capitalism gone amok:
Něco z toho lze řešit pomocí SRS, které se nasadí na ten přeposílací serverUž jsem psal - jde to, ale selže DMARC, protože mechanismus standardizovaný pro obálkové adresy aplikuje na adresy ve zprávě. Na to se musí použít ARC, to určitě povede k nějakému dalšímu problému, takže kolečko, kdy monopolní Google každých pár let vymyslí nový standard, aby lidem provozování vlastních poštovních služeb co nejvíc znepříjemnil, může pokračovat. Samozřejmě ze svých serverů rozesílají spam taky, ale s tím se nic dělat nedá. Prostě "capitalism gone amok" to vystihuje přesně. A nikdo si na ně nedošlápne, když mají obrat větší než HDP států, kde nabízejí své služby.
Pritom by možno stačilo označiť v google mail :"Toto nie je SPAM." Vidim problém, že niektorí to buď neoznačia alebo to umýselne urobia. Potom google nevie čo vlastne s tým má urobiť.
Iný prístup je poučenie, že správa čo prišla do schránky sa považuje za doručenú. Ďalšie doručovanie už nie je na zodpovednosti Vysokej školy.
Přidáš si doménu, oni ti na základě toho vygenerují DNS záznamKouknu. Ale jinak dobrý, co 10000 domén? To je teda separátní problém, ale úplně podobný - maily poslané přes tenhle server (relay pro desktopové poštovní klienty) občas zahučí u googlu v černé díře. A to ten server je nastavený extra paranoidně, aby se přes něj nespamovalo, i když lidem ukradnou přihlašovací údaje. Fakt neberu to, že Google zahazuje maily na základě nějakých platných důvodů (mailservery fakt mám nastavené dobře včetně PTR a spol.) Prostě házejí klacky pod nohy konkurenci. Ostatně totéž platí i pro jejich ostatní aktivity třeba u webu.
Nic co by jí mohla škola nabídnout.Ne každá škola má po ruce kvalifikovaného ajťáka, který bude schopen něco takového vyrobit. A naopak každá učitelka si může doma (nechat) postavit všechno tak, jak chce, aniž by kvůli tomu bylo potřeba pořádat výběrové řízení. (Ve kterém před lepším řešením snadno vyhraje lépe vypapírované řešení.)
zajistit si alespoň trochu slušnou konektivitu by snad problém být nemělJe to zakázka, musí to projít přes výběrové řízení, což pro začátek znamená, že někdo (ten ajťák, kterého škola nejspíš nemá) musí vědět, co vlastně chce. Napsat do zadání "trochu slušná konektivita" ke kýženému výsledku nepovede.
bohužel od té doby, co o obsazení těchto postů rozhodují politické klikyTedy od vzniku škol.
A ano, výklad s projektorem na ukázky a tabulí na kreslení s komunikujícími a dotazujícími se studenty a kolegy naživo video v žádném přídě plně nenahradí.Přímý přenos s nějakým jabberem, matrixem nebo něčím takovým na kladení dotazů, by nešel? (Tím neříkám jako náhrada přednášky naživo, ale furt lepší než offline video.)
Pozor, počáteční prodleva je velmi vysoká, video se přeposílá přes NGINX z VLC jako RTMP stream (Pokud by někdo uměl poradit, jak počáteční prodlevu zkrátil, radu velmi uvítám). Poté je již latence přenosu i ke mě domů 1.5 sekundyVzhledem k tomu, že se tam prakticky nic nehýbe, tipnul bych si, že zdroj toho videa neposílá moc B-snímků, protože všechno jde řešit rozdílem oproti předchozímu. Tj. že počáteční latence není nic jiného, než čekání na to, až ten enkodér nějaký B-snímek vyrobí, i když to potřeba není. Pokud by to tak bylo, mohlo by stačit vynutit generování B-snímků v kratších intervalech
/usr/bin/vlc -I dummy v4l2:///dev/video0:chroma=yu12:width=1920:height=1080:fps:30 --sout=#transcode{vcodec=h264,acodec=none,vb=1200,fps=30,venc=x264{preset=ultrafast,tune=zerolatency,keyint=30,bframes=0,ref=1,level=30,profile=baseline,hrd=cbr,crf=20,ratetol=1.0,vbv-maxrate=1200,vbv-bufsize=1200,aud,lookahead=0,repeat-headers=1}}:std{access=rtmp,mux=ffmpeg{mux=flv},dst=xxx}
Na druhou stranu se mi i podle nějaké dokumentace a dalšího zdá, že ffplay na začátek nabírá nejdříve buffer nějaké, celkem značné velikosti a teprve potom začne řešit co v něm vlastně má.
Dobře chodící připojení z VLC jako klienta se mi nastavit nepodařilo. Vždy to bylo s velkou prodlevou.
Předem díky za případné další nápady.
Na druhou stranu se mi i podle nějaké dokumentace a dalšího zdá, že ffplay na začátek nabírá nejdříve buffer nějaké, celkem značné velikosti a teprve potom začne řešit co v něm vlastně má.Těžko říct. Zkusil jsem a zdálo se mi to taky - mplayer s
-nocache i mpv s --cache=auto a no přehrávání spustí v podstatě vždycky stejně, nějakých půl minuty po spuštění programu. Na druhou stranu tohle
mkfifo stream rtmpdump -r rtmp://147.32.86.117/live/mzapo100 --live --quiet >stream mpv --cache=no streampřestane přehrávat nějakých 5 sekund po ukončení toho rtmpdump. Což ovšem může znamenat, že zahodí zbytek cache, když narazí na konec dat v tom souboru. Jinak jsem to spletl, není to B-snímek, ale (velké i) I-snímek. Zkuste se podívat na parametry sout-x264-keyint/keyint, možná to pomůže. Jestli jsem dobře pochopil, tak při výchozí hodnotě můžou být při 30fps v intervalu 8 sekund.
ten keyframe/iframe interval jsem se právě snažil zkrátit tou volbou keyint=30... a to jsem to v tom příspěvku to "keyint" hledal, než jsem odpověděl. No jo, tak příště
Tiskni
Sdílej: