Přední technologické společnosti (Adobe, Cadence, Capital One, Cisco, Cloudera, Cloudflare, Cognition, CrowdStrike, Databricks, Dell Technologies, DoorDash, Elastic, HPE, Hugging Face, IBM, LangChain, Linux Foundation, Microsoft, NAVER, NetApp, Nous Research, NVIDIA, OpenClaw, Palantir, Palo Alto Networks, Red Hat, Reflection AI, Salesforce, SAP, ServiceNow, Siemens, SK Telecom, Snowflake, SpacexAI, Synopsys, Thinking
… více »Krabix.cz je online 3D konfigurátor krabiček pro 3D tisk s exportem do STL. Běží přímo v prohlížeči. Nic se neposílá na server.
Nadace Open Home Foundation spustila veřejnou preview verzi komunitní databáze zařízení pro Home Assistant. Má fungovat jako „Wikipedie pro chytrá zařízení".
Na stránce nového panelu Firefoxu přibudou nové widgety. Například denně aktualizována interaktivní křížovka.
PGSimCity (GitHub) je webová 3D vizualizace vnitřního fungování databázového systému PostgreSQL v podobě města. Vytvořena pomocí umělé inteligence.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.0 a 24.04-1.4. Nová verze 24.04-2.0 již počítá s výřezy pro fotoaparát (notch) a zaoblenými rohy displeje. Webový prohlížeče Morph přešel z Chromia 87 na Chromium 134. Do shellu Lomiri byl přidán editor snímků obrazovky.
Byly zveřejněny informace o kritické zranitelnosti CVE-2026-64600 pojmenované RefluXFS (technické detaily) v XFS. Je tam již od verze Linuxu 4.11, tj. rok 2017. Jedná se o lokální eskalaci práv. Neprivilegovaný uživatel může editovat libovolný soubor, například klidně zrušit rootovské heslo v /etc/passwd. Videoukázka na Vimeo. V upstreamu je zranitelnost opravena.
OpenAI / ChatGPT má dnes výpadky (OpenAI Status, DownDetector).
Poskytovatel hostingu svobodných/open-source projektů Codeberg po hlasování na valné hromadě vydal stanovisko k využívání LLM. Kvůli vytěžování infrastruktury a rostoucím cenám hardwaru, ale také hrozbám pro spolupráci v komunitě se k LLM staví kriticky. Nebude poskytovat hosting projektů vytvářených LLM agenty.
Jack Dorsey představil (𝕏) open source týmovou komunikační platformu Buzz (GitHub) s cílem snížit závislost na Slacku a GitHubu.
Neúspěšně bojuji s CR+LF vs LF. Na serveru poslouchám netcatem a na něj se připojuji telnetem z Windows. Problém je v tom, že windows mi posílá CR+LF, ale netcat očekává zakončení řádku pouze LF. Důsledek je takový, že když výstup netcatu sypu rourou někam dál, pošlou se mi do ní data až po přerušení spojení.
Já ovšem potřebuji data posílat okamžitě, CR+LF nahradit LF...
Stojím na tomto bodě:
nc -l -k -t -p 2000 | sed -e 's/\r/\r\n/g'
Zajímavé je, že když výstup přesměruji do souboru, třeba takto:
nc -l -k -t -p 2000 > output.logtak se tam vše zapisuje okamžitě. Resp. pokud si jej otevřu ve vimu, je to tam. Cat apod. neukáže nic...
Poradí mi někdo, jak toto chování/problém vyřešit nebo obejít?
Trošku jsem pokročil:
nc -l -p 2000 | tr '\n\r' '\n'kupodivu funguje přesně, jak jsem chtěl.
Průšvih je, že chci netcatem volat skript, který vstup zpracuje a podle toho vyhodí nějaký výstup, takže něco ve stylu:
nc -l -p 2000 -e read.sh
read.sh:
#!/bin/bash while true; do read input echo $input>input.log echo "Recorded: $input" done
Ovšem tím jsem s problémem zase na začátku, protože opět nevím, jak ten vstup v read.sh vzít a prohnat ho něčím co ho zkonvertuje CR+LF na LF.
input=${input%$'\r'}
sed -e 's/\r/\r\n/g'tak úplně \r neodstraní. Asi spíš chcete
sed 's/\x0d$//g'Popřípadě totéž se sed -u, abyste ještě nenarazil na problém bufferování výstupu a data se vypisovala opravdu po řádcích. Jinak lépe než čachrovat s vimem a catem je lepší použít "od":
$ echo -ne 'aaaa\r\n' | sed 's/\x0d$//g' | od -t x1 0000000 61 61 61 61 0a 0000005
Máte pravdu. Prohnal jsem to čistě "od" a zjistil jsem, že řetězec je zakončen samotným CR (x0d), zkoušel jsem tedy
netcat -l -p 2000 | sed -u 's/\x0d/\x0a/g'což mi průběžně nevypisuje nic, až když se přeruší spojení, tak se vypíše vše najednou.
Druhý pokus ve formě
netcat -l -p 2000 | tr '\r' '\n'vypisuje pěkně průběžně.
Ovšem pokud kterýkoliv z těchto dvou výstupů přesměruji do souboru, tak se mi v obou případech zapíše do souboru až po přerušení spojení. Začínám mít obavy, že se standardními nástroji v Linuxu to dohromady nedám. Možná by bylo nejjednoduší to celé napsat v Pythonu...
což mi průběžně nevypisuje nic, až když se přeruší spojení, tak se vypíše vše najednou.Zní to jako problém s I/O buffery. Ve skutečnosti to není "po přerušení spojení" ale něco jako 4kb dat.
Tiskni
Sdílej: