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.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
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í
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
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: