Vládní CERT upozorňuje na kritickou zranitelnost v GitLab Community Edition (CE) a Enterprise Edition (EE). Zranitelnost CVE-2026-85706 typu path traversal v Repository Commits API dosahuje skóre CVSS 10.0. Kvůli nedostatečnému omezení cest a chybějícímu vynucení autentizace může za určitých podmínek neautentizovaný útočník číst libovolné soubory ze serveru GitLab, a získat tak přístup k citlivým datům a konfiguraci instance.
Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Správce fotografií Shotwell byl vydán ve verzi 33.0 (GitLab). Hlavní novinkou v tomto vydání po dvou letech je přechod na GTK4.
Na YouTube byly publikovány videozáznamy přednášek a na Flickru fotografie z konference EuroPython 2026.
Byl vydán Debian 13.7, tj. sedmá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Jiří Eischmann se v příspěvku Fiasko jménem W Social na svém blogu věnuje evropské sociální síti W: "W Social je příkladem toho, že se problémy sociální sítí nedají řešit od exekutivního stolu. Když na začátku tohoto roku v Davosu oznámili vznik nové sociální sítě W Social, politici se mohli přetrhnout ve chvalozpěvech. Konečně evropská sociální síť a ještě s ověřením identity. … Jak se ukázalo, když v Davosu W Social oznamovali, neměli kromě
… více »Výrobce hardwarových kryptoměnových peněženek Trezor upozorňuje na bezpečnostní incident u společnosti Brevo, kterou využívá k odesílání newsletterů. Útočník na e-mailové adresy odeslal phishingový e-mail.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za srpen 2026. Aplikace XApp mají vlastní webovou stránku xapp-project.org. Představena byl čtečka EPUB s názvem Xepub a kalendář Clockenstein.
Byla vydána nová verze 3.2.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
zdravím, v pythonu začínám a nemám takový přehled o jazyce a knihovnách
Řešil jsem problém s parsováním textového vstupu (text oddělený rourama, ale na každém řádku jiný počet sloupců a také některé položky obsahovaly znak '\r') - takže celkem legrace
Jeden "blok" (nebudu říkat řádek, protože to není prvada) vypadá třeba takhle:
|START|ahoj | text|zase nejaky text ktery je docela dlouhy| polozka|STOP|
základní smyčka programu načítá tento jeden blok (jediné co vím, že začíná přesně |START| a končí přesně |STOP|) pomocí sys.stdin.read(1). jednotlivé položky ukládám do pole, které po přečtení jednoho bloku zpracuji a vyhodím na výstup
dneska sem ale zjistil, ze na vstupu budou asi 4GB (pri soucasnem vykonu by to trvalo asi 8h), takze: jak zefektivnit vstup? (docela by to chtelo
)/p>
jednotlivé položky ukládám do pole, které po přečtení jednoho bloku zpracuji a vyhodím na výstupOtázka zní jinak, co to znamená zpracuje? Je možné zpracovat jeden token a ihned ho vypsat, nebo je potřeba mít celý soubor načtený v poli a až potom zpracovávat? Je možné třeba pustit čtení v jednom vláknu a zpracovávání (po načtení nějakého minimálního vstupu) ve druhém? BTW: pokud je výkon kritický a budeš zpracovávat 4GB soubory, poohlédl bych se spíše po C.
které po přečtení jednoho bloku zpracuji a vyhodím na výstupasi sem se zeptal spatne: jak moc je v pythonu efektivni sys.stdin.read(1) ? ja jsem spise javista... takze do Ccka bych se vubec nehrnul
- radeji mam jazyky vyssi urovne
$ seq 1000000 > milion.txt $cat read #!/usr/bin/python import sys while (sys.stdin.read(1)): pass $ time cat milion.txt | ./read real 0m13.338s user 0m13.233s sys 0m0.068s
Tiskni
Sdílej: