Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Hello Mirek, >> Hi, i would like to send donation (about 100 - 1000 euro) on madwifi >> project to fully implement DFS and TPC futures, but i dont know what is >> missing, or what is not working corectly and i dont know specifications >> of DFS and TPC futures. Can you tell me what is missing, or what need to >> be done to fully support those futures? Well, a simple question, but a difficult answer. An 802.11h compliant client has to implement - Dynamic Frequency Control - TPC (Power Control) - Radar Detction The behaviour of a client differs from that of an AP. And the Network has to be managed on 5 GHz (not "AD-HOC" -> a card in this regulatory domain must not allow to be set to AD-HOC mode). DFC: When an AP is powered on, it has to choose a channel (randomly - for e.g. not starting every time with "1"). It should chect for radar. The time before he uses this channel (transmitting, broadcasting it's SSID) is specified. The AP has to scan ervery 24h for N seconds for a new channel (and no radar should be detected - it has to wait 1 min, if i remember correctly). Ideally it should find a channel which currently is not in use. Problem: The specification insisists in waiting if there's radar. Thus a Link which is up 24h/day, has a downtime by spec of 365 minutes a year(!). RD: if radar is detected, the AP should "shut down" the channel immediately. Thus it has to find a new channel. The channel where radar is detected, should be marked persistantely for no-use for n hours (i think it was 1 hour). Persistantly means, the mark should be honourd even after reboot / powercycle. Problem: DOS Attack. If every channel is marked, the Link is dead. A client searches for / follows the AP. Ideally the client does not probe actively (MAC layer protocol), this means, it is silent until it has seen "his" AP. Imagine you have a link, not with AP and client, but with two APs and WDS. And both APs have to do RadioRetection. Well, how they'll find each other? How they both signalize that they've detected radar? RD of a client: i do not remember exactly. I think it's a should, but not a must. If a client detects RD and the AP honours: -> possible DOS attack by a random client.. TPC: A client should to TPC. If not, the EIRP should be, if i remember correctly, 3dB lesser than regulatory maximum. But TPC should not be difficult to implement. 1W EIRP in Europe on 5GHz is interesting, because it's better than 100mW on 2.4GHz (even when considering FreeSpaceLoss). For our link we've built, we first thought to use two WRAP Boards running linux. But imhow, MadWifi does not match the requirements. Finaly, i decided to buy a licensed 802.11h AP, and use the WRAP board as client. With the half the max. EIRP (TPC for a client conforming to the spec); RD is tested (but i do not know if it response "in time", due to the spec, and there's a potential problem because it do not know if the client could tell the AP that he had to shut down the channel. Fortunately, it did not happen since the few weeks the link is already up). As far as i think, a madwifi card could not be used as 802.11h AP, because too much is missing. For all those things (TPC, DFC, RD and some more) there are detailed requirements in the spec. A fully compliant driver has to be conform to them. The regulations are a pain. Unfortunately, here in europe the 5GHz band is in military use. And they are pedantic with everything.. Furthermore, this band is in use for Plane->Airport radar (the main reason why RD is specified); thus it's understandable, why they insist on this mechanism. The spec we're talking about is http://webapp.etsi.org/action/OP/OP20050729/en_301893v010301o.pdf Our authority (BeNetzA (previously RegTP)) refers to this spec (which is nerby still a draft) for further details. I think the development should go in these steps: - implement all the 802.11h client specs - ideally: certify them with a decent card (for e.g. atheros wistron cm9, which is widely in use) - implement the 802.11h AP specs - certify this one too - think about WDS Btw, A great problem i personaly had, was that it's not easy to make messurements in this band. I configured the card to use n mW, and tried to interprete the result with a wlan sniffer. A card which may be certified for madwifi should be calibrated to the power settings as well. And now, is it what you liked to hear? ;) Regards, - Thomas
Tiskni
Sdílej: