Microsoft poskytl FBI uživatelské šifrovací klíče svého nástroje BitLocker, nutné pro odemčení dat uložených na discích třech počítačů zabavených v rámci federálního vyšetřování. Tento krok je prvním známým případem, kdy Microsoft poskytl klíče BitLockeru orgánům činným v trestním řízení. BitLocker je nástroj pro šifrování celého disku, který je ve Windows defaultně zapnutý. Tato technologie by správně měla bránit komukoli kromě
… více »Spotify prostřednictvím svého FOSS fondu rozdělilo 70 000 eur mezi tři open source projekty: FFmpeg obdržel 30 000 eur, Mock Service Worker (MSW) obdržel 15 000 eur a Xiph.Org Foundation obdržela 25 000 eur.
Nazdar! je open source počítačová hra běžící také na Linuxu. Zdrojové kódy jsou k dispozici na GitHubu. Autorem je Michal Škoula.
Po více než třech letech od vydání verze 1.4.0 byla vydána nová verze 1.5.0 správce balíčků GNU Guix a na něm postavené stejnojmenné distribuci GNU Guix. S init systémem a správcem služeb GNU Shepherd. S experimentální podporou jádra GNU Hurd. Na vývoji se podílelo 744 vývojářů. Přibylo 12 525 nových balíčků. Jejich aktuální počet je 30 011. Aktualizována byla také dokumentace.
Na adrese gravit.huan.cz se objevila prezentace minimalistického redakčního systému GravIT. CMS je napsaný ve FastAPI a charakterizuje se především rychlým načítáním a jednoduchým ukládáním obsahu do textových souborů se syntaxí Markdown a YAML místo klasické databáze. GravIT cílí na uživatele, kteří preferují CMS s nízkými nároky, snadným verzováním (např. přes Git) a možností jednoduchého rozšiřování pomocí modulů. Redakční
… více »Tým Qwen (Alibaba Cloud) uvolnil jako open-source své modely Qwen3‑TTS pro převádění textu na řeč. Sada obsahuje modely VoiceDesign (tvorba hlasu dle popisu), CustomVoice (stylizace) a Base (klonování hlasu). Modely podporují syntézu deseti různých jazyků (čeština a slovenština chybí). Stránka projektu na GitHubu, natrénované modely jsou dostupné na Hugging Face. Distribuováno pod licencí Apache‑2.0.
Svobodný citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 8. Přehled novinek v příspěvku na blogu.
Byla vydána verze 1.93.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Svobodný operační systém ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, slaví 30. narozeniny.
Společnost Raspberry Pi má nově v nabídce flash disky Raspberry Pi Flash Drive: 128 GB za 30 dolarů a 256 GB za 55 dolarů.
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: