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.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Společnost Škoda Auto zveřejnila na Printables bezplatné 3D modely příslušenství do svých vozů (držáky na nápoje, pomůcky pro vedení kabelů, mincovníky, háčky na USB kabely a čepice pro kapsy na zadních stranách opěradel sedadel, držáky na telefony a úchyty pro horní upevnění bezpečnostních pásů).
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 170 (pdf).
Dnes v 16:00 (14:00 UTC) budou opraveny 2 kritické zranitelnosti s CVSS 9.2 v PHP.
Nizozemská policie 13. října 2026 zabavila v datacentru Amsterdam Science Park server italského poskytovatele internetových služeb Autistici/Inventati (A/I), a to na základě americké žádosti o mezinárodní právní pomoc.… více »
Zdravim vsechny,
Vstup
Ma nekdo nejaky napad na chytry algoritmus?
#!/usr/bin/perl
use 5.010;
use warnings;
use strict;
use List::Util qw{first};
use Benchmark;
our $VERSION = 0.001;
my $string =
'234781802319q8019810328103982104398021483049823094830498023982094823028340932840923830483201223';
my @multiregexp = ( qr{ \A \d+ . \z }msx, qr{ \$ }msx, );
timethese(
1000000,
{
more => sub {
my $trueregexp = first { $string ~~ $_ } @multiregexp;
},
one => sub { my $tt = $string ~~ m{\A \d+ . \z|\$}msx ? 1 : 0; },
one_better =>
sub { my $tt = $string ~~ m{\A \d+ . \z|\A .* \$ .* \z}msx ? 1 : 0; },
}
);
mi vypíše
Benchmark: timing 1000000 iterations of more, one, one_better...
more: 3 wallclock secs ( 2.72 usr + 0.00 sys = 2.72 CPU) @ 367647.06/s (n=1000000)
one: 14 wallclock secs (13.69 usr + 0.01 sys = 13.70 CPU) @ 72992.70/s (n=1000000)
one_better: 12 wallclock secs (12.06 usr + 0.00 sys = 12.06 CPU) @ 82918.74/s (n=1000000)
když $string upravím a přidám na konec $, tak
more: 3 wallclock secs ( 3.21 usr + 0.00 sys = 3.21 CPU) @ 311526.48/s (n=1000000)
one: 12 wallclock secs (13.74 usr + 0.00 sys = 13.74 CPU) @ 72780.20/s (n=1000000)
one_better: 1 wallclock secs ( 2.04 usr + 0.00 sys = 2.04 CPU) @ 490196.08/s (n=1000000)
a když smažu q z takto upraveného $string
more: 3 wallclock secs ( 2.18 usr + 0.00 sys = 2.18 CPU) @ 458715.60/s (n=1000000)
one: 1 wallclock secs ( 1.39 usr + 0.00 sys = 1.39 CPU) @ 719424.46/s (n=1000000)
one_better: 0 wallclock secs ( 1.36 usr + 0.00 sys = 1.36 CPU) @ 735294.12/s (n=1000000)
atp.
first ještě dá na výstup, který ten regexp bude true
ještě se to dá otestovat jako
more_better => sub {
my $tt = $string ~~ @multiregexp ? 1 : 0;
}
které je nejrychlejší ve všech předešlých případech
use 5.010;
use warnings;
use strict;
use List::Util qw{first};
our $VERSION = 0.001;
my $string =
'23478180231x98019810328103982104398021483049823094830498023982094823028340932840923830483201223$';
my @multiregexp = ( qr{ \A \d+ . \z }msx, qr{ \$ }msx, );
my $trueregexp = first { $string ~~ $_ } @multiregexp;
say 'tento regexp vyhovuje ', $trueregexp;
a když to nebude dostatečně rychlé, tak to chce vědět více o těch regexp-ech popř. o tom řetězci, aby se dalo navrhnout něco efektivnějšího
Takze dekuji vsem za kometare.
Spojeni do jednoho velkeho regexpu jak je navrzeno vyse by snad splnilo podminku na rychle vyhledavani, nicmene jsem skoncil na tom ze je potreba i pomerne rychla reakce na to kdyz uzivatel nejaky regulani vyraz prida/ubere/zmeni a konstrukce toho dloooouheho regularniho vyrazu a jeho kompilace je prilis pomala.
Vysledne reseni je nakonec zalozene na tom, ze ty regularni vyrazy - tedy alespon vetsinaz nich ma v sobe nejaky pevny retezec, napriklad "[0-9]ABC[0-9]" a pomoci techto retezcu lze udelat index a v tom indexu najit podmnozinu regexu ktere se pak matchuji sekvencne. Vetsinou jsou to regexy slozitejsi nez v tom prikladu, ale obvykle to jde a tech par stovek regexu, ze kterych se neda nejaky rozumny retezec vyextraovat se bude prochazet sekvencne az kdyz se nenajde jinde.
Tiskni
Sdílej: