Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
1. re-INITE: skoro bych rekl, ze jeho pouzivani je velmi nerozumne. A nejen proto, ze nekteri klienti ho "nerozdychaji", ale zejmena proto, ze tim ztratite kontrolu na RTP streamem a nebudete schopen zabijet "uhnile" hovory.
2. userid: S tim jsem se tez nesetkal a IMHO se jedna spise o chybu, nez starou/novou versi. Ale kdyz to Asterisk zkousne (jeko ostatne kde co , tak proc ne...
Hezky den!
kokoska.rokoska
1. Cesta RTP: pokud neni potreba "prekonavat" NAT a Asterisk je spravne nastaven, tak po re-INVITE Asterisk samozrejme "vypadne z kola ven"
2. Traskodovani: ja se domnivam, ze se nejedna o bug, ale u umysl. Pri generovani noveho INVITE totiz Asterisk nabizi v SDP celou sadu kodeku nastavenou pro konkretniho peera (a v poradi definovanem administratorem - ten preci vi, co dela, ze . A vcelku pochopitelne akceptuje odpoved od peera. Zvysuje se tim pravdepodobnost uspesneho spojeni a tim, ze vychazite vstric klientskym zarizenim, tak sice mozna zvysite zatez systemu, ale statisticky skoro urcite zkvalitnite samotnou komunikaci - kazdy klient ma prece duvod, pro si nastavil prave takove poradi kodeku...
Druha moznost je posilat v SDP odchoziho INVITE jen to co prislo "z druhe strany" - tuto filozofii razi FreeSWITCH. Vyhnete se tim transkodovani, ale znacne snizite uzivatelum komfort.
Jedinou (byt pofiderni) moznosti by bylo pouziti Asteriskova soucasneho systemu a nasledne zaslani re-INVITE zpet "na sebe". Ale to by byla velka cunarna, jak jiste uznate
1. Rychlosti: Ano, soucasna kvalita linek (nepocitame-li nektere wifi spoje) je uz dostatecna pro G.711 a kdo muze at ho pouziva...
Problem muze nastat pouze pri mnoha soucasnych hovorech z firemnich PBX - pouhych 20 soucasnych hovoru spotrebuje na upstreamu od ustredny temer 2 Mb/s. A u roadwarrioru dokonce dvojnasobek...
2. G.711a <-> G.711u: Prehazet poradi bitu skutecne na prvni pohled kvalitu nezhorsi Ale i zde existuji uskali - naroste latence spoje (problem pro echocancel a jitterbuffer) a protoze nepouzivame (aspon vetsina ne) HW prevodniky, tak velmi pravdepodobne naroste i jitter. Takze i trasnkodovani "alaw" <-> "ulaw" je vhodne se vyhnout
1. Prudeni vyrobcu: v tom s Vami samozrejme souhlasim
2. Prepojeni hovoru: tam by IMHO re-INVITE vubec nemel prijit do hry. Pro prepojeni hovoru by mel byt pouzit bud REFER na klientske strane nebo transparentni prepojeni na strane PBX (u Asteriska je implementovano pomoci "kodu" z features.conf)
3. Dohled nad RTP: znovu opakuji, ze IMHO existuje velmi zavazny duvod, proc udrzovat kontrolu nad RTP. A tim duvodem je prave zminovana moznost zabijeni "uhnilych" hovoru. Aneb tech, u nichz signalizacne nedoslo k ukonceni a pritom RTP uz davno netecou. My nemame na "ustredne" velky provoz (max 15 000 hovoru mesicne), ale i tak je takovych hovoru nekolik desitek kazdy mesic. Operatori by Vam zajiste potvrdili, ze procento takto nasilne ukoncovanych hovoru vubec neni zanedbatelne...
Asterisk 1.0.7-BRIstuffed-0.2.0-RC7k, Copyright (C) 1999-2004 Digium. Written by Mark Spencer ========================================================================= Connected to Asterisk 1.0.7-BRIstuffed-0.2.0-RC7k currently running on server (pid = 8691) server*CLI> reload Feb 27 13:58:09 NOTICE[8692]: indications.c:397 ast_unregister_indication_country: Removed default indication country 'us' Feb 27 13:58:09 WARNING[8692]: chan_sip.c:8703 reload_config: Unknown dtmf mode 'auto', using rfc2833 Feb 27 13:58:09 WARNING[8692]: pbx_config.c:1663 pbx_load_module: Invalid priority 'n' at line 10 Feb 27 13:58:09 WARNING[8692]: pbx_config.c:1663 pbx_load_module: Invalid priority 'n' at line 11 Feb 27 13:58:09 WARNING[8692]: pbx_config.c:1663 pbx_load_module: Invalid priority 'n' at line 12
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz