Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
$ cat log.file " " $ sed 's/" "/"_"/g' log.file "_"
#include <stdio.h>
int main()
{
int c;
int inside = 0;
while ((c = getchar()) != EOF) {
if (c == '"') inside = !inside;
if (inside && c==' ') c = '_';
putchar(c);
}
return 0;
}
Zpracování chyb a/nebo parametrů si doplňte za cvičení.
#!/bin/bash ZAMENA="_" IFS= while read line ; do quote=0 while read -n 1 char ; do if [ "$char" == " " ] ; then if [ $quote -eq 0 ] ; then outchar=" " else outchar="$ZAMENA" fi elif [ "$char" == '"' ] ; then quote=$((1 - quote)) outchar='"' else outchar="$char" fi echo -n "$outchar" done <<<"$line" echo doneObecne v ulohach takoveho typu vynika Perl. Tady je reseni v Perl'u:
$ perl -pe 's/".*?"/($s=$&)=~s: :_:g;$s/eg' soubor.logNa zaver uvedu srovnani rychlosti vsech 3 reseni (vcetne programu v C, napsaneho Michalem Kubeckem):
$ ls -sh /var/log/messages 716K /var/log/messages $ time uvozovky.sh < /var/log/messages > /dev/null real 2m12.561s user 1m57.610s sys 0m6.001s $ time perl -pe 's/".*?"/($s=$&)=~s: :_:g;$s/eg' /var/log/messages > /dev/null real 0m0.038s user 0m0.030s sys 0m0.008s $ time uvozovky_c < /var/log/messages > /dev/null real 0m0.071s user 0m0.059s sys 0m0.005sMuzete si vsimnout, ze reseni v Perl'u je dokonce rychlejsi nez v C.
[~]$ gcc -o uvozovky_c uvozovky.c -O2 [~]$ time ./uvozovky_c < /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null real 0m4.195s user 0m3.174s sys 0m0.201s [~]$ time ./uvozovky_c < /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null real 0m3.492s user 0m3.112s sys 0m0.132s [~]$ time ./uvozovky_c < /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null real 0m3.250s user 0m3.079s sys 0m0.132s [~]$ time ./uvozovky_c < /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null real 0m3.301s user 0m3.098s sys 0m0.137sPodobne,
[~]$ time perl -pe 's/".*?"/($s=$&)=~s: :_:g;$s/eg' /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null real 0m2.278s user 0m1.806s sys 0m0.154s [~]$ time perl -pe 's/".*?"/($s=$&)=~s: :_:g;$s/eg' /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null real 0m2.003s user 0m1.807s sys 0m0.154s [~]$ time perl -pe 's/".*?"/($s=$&)=~s: :_:g;$s/eg' /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null real 0m2.004s user 0m1.814s sys 0m0.152sSamozrejme, prvni start Perlu muze byt i pomalejsi nez C, tady mu pomohlo to, ze ja jsem meril rychlost perlu az po c-ku. Neni nic divneho na tom, ze Perl muze byt rychlejsi nez C. Vzlast kdyz si uvedomite, ze pouzivate getchar() misto operaci cteni celeho bloku.
Vzlast kdyz si uvedomite, ze pouzivate getchar() misto operaci cteni celeho bloku.
Zapomínáte na to, že streamové operace v libc mají vlastní bufferování, takže vkládat tam ještě druhý buffer by bylo zbytečné a program by to naopak zpomalilo. Není tam ani overhead na volání getchar(), protože to je ve skutečnosti makro. Samozřejmě by šel program trochu zrychlit načítáním celých bloků pomocí read() a jejich zápisem pomocí write(), pak by Perl neměl nejmenší šanci, ale to už by bylo na úkor přehlednosti.
Samozřejmě jsem používal průměr druhého až čtvrtého běhu programu, nejsem tak hloupý, jak vypadám.Nevypadate vubec hloupe, vase prispevky tady a na cz.comp.linux vzdy povazuji za velice duveryhodne. Ale stava se, ze i mistr tesar se utne, takze jsem nevedel, jestli jste nahodou nezapomel na ten cache.
Takže tvrdím, že někde děláte chybu, pravděpodobně v těch optimalizacích.V minulem prispevku jsem uvedl prikaz, pomoci ktereho to prekladam. Optimalizaci mam nastavenou na level 2. Jak to mate vy?
Zapomínáte na to, že streamové operace v libc mají vlastní bufferování, takže vkládat tam ještě druhý buffer by bylo zbytečné a program by to naopak zpomalilo.Plny souhlas.
Samozřejmě by šel program trochu zrychlit načítáním celých bloků pomocíTak tady nesouhlasim s tim, ze by to zrychlilo program jen trochu.read()a jejich zápisem pomocíwrite(), pak by Perl neměl nejmenší šanci, ale to už by bylo na úkor přehlednosti.
[~]$ cat uvozovky_read_write.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define BUFSIZE 512
int main()
{
char *buf_in = malloc(BUFSIZE);
char *buf_out = malloc(BUFSIZE);
char c;
int i, j, n;
int inside = 0;
j = 0;
while (n = read(0, buf_in, BUFSIZE)) {
for (i = 0; i < n; i++) {
c = buf_in[i];
switch (c) {
case '\n': inside = 0; break;
case '"' : inside = !inside; break;
case ' ' : c = inside ? '_' : ' ';
}
buf_out[j++] = c;
if ( j >= BUFSIZE ) {
write(1, buf_out, BUFSIZE);
j = 0;
}
}
}
if ( j ) {
write(1, buf_out, j);
}
return 0;
}
[~]$ gcc -O2 -o uvozovky_read_write uvozovky_read_write.c
[~]$ time ./uvozovky_read_write < /usr/src/linux-2.6.14.2.tar.bz2 > /dev/null
real 0m0.641s
user 0m0.326s
sys 0m0.202s
A skutecne Perl nema sanci.
-O3 -fomit-frame-pointer' plus optimalizaci pro procesor. Co se týká přechodu na 'read()' a 'write()', skutečně jsem ho hodně podcenil, rozdíl je v některých případech i řádový. Zdá se, že režie streamových funkcí v glibc je větší, než jsem si pod vlivem dřívějších testů myslel.
Zdá se, že režie streamových funkcí v glibc je větší, než jsem si pod vlivem dřívějších testů myslel.Dost velký čas sežere zbytečné zamykání, při použítí getchar_unlocked() a putchar_unlocked() se to celkem zrychlí.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define BUFSIZE 65536
int main()
{
char *buf = malloc(BUFSIZE);
char *c, *end;
int n;
int inside = 0;
while (n = read(0, buf, BUFSIZE)) {
end = buf+n;
for (c = buf; c < end; c++) {
switch (*c) {
case '\n': inside = 0; break;
case '"' : inside = !inside; break;
case ' ' : if (inside) *c ='_';
}
}
write(1, buf, n);
}
return 0;
}Proč ty data přesýpat z jednoho místa na druhé fakt nechápu.
$ time ./uvozovky_read_write </var/cache/apt/archives/openclipart-png_0.17+dfsg-1_all.deb >/dev/null real 0m1.716s user 0m0.580s sys 0m0.270s $ time ./uvozovky_read_write_orig </var/cache/apt/archives/openclipart-png_0.17+dfsg-1_all.deb >/dev/null real 0m1.926s user 0m0.800s sys 0m0.340sKrom toho ten půlkylovej buffer byl fakt dobrej vtip. Vůbec vám nevadí, že tráví v kernelu skoro stejně dlouhej čas jako v userspace? Ten
uvozovky_read_write_orig má samozřejmě zvětšenej buffer taky, jinak by měl něco kolem 600ms v kernelspace. Toho času real si nevšímejte, nejsem na tom App Serveru sám
Tiskni
Sdílej: