Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Společnost OpenAI představila text-to-video AI model Sora 2 pro generování realistických videí z textového popisu. Přesnější, realističtější a lépe ovladatelný než předchozí modely. Nabízí také synchronizované dialogy a zvukové efekty.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.0, tj. první stabilní vydání založené na Ubuntu 24.04 LTS.
Rakouská armáda přechází na LibreOffice. Ne kvůli licencím (16 000 počítačů). Hlavním důvodem je digitální suverenita. Prezentace v pdf z LibreOffice Conference 2025.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) upozorňuje na sérii kritických zranitelností v Cisco Adaptive Security Appliance (ASA) a Firepower Threat Defense (FTD) a Cisco IOS, CVE-2025-20333, CVE-2025-20363 a CVE-2025-20362. Zneužití těchto zranitelností může umožnit vzdálenému neautentizovanému útočníkovi spustit libovolný kód (RCE). Společnost Cisco uvedla, že si je vědoma aktivního zneužívání těchto zranitelností.
Ochrana uživatelů a zároveň příznivé podmínky pro rozvoj umělé inteligence (AI). Ministerstvo průmyslu a obchodu (MPO) připravilo minimalistický návrh implementace evropského nařízení o umělé inteligenci, tzv. AI aktu. Český zákon zajišťuje ochranu občanům a bezpečné používání AI, ale zároveň vytváří pro-inovační prostředí, ve kterém se může AI naplno rozvíjet, firmy mohou využít jeho potenciál a nebudou zatíženy zbytečnou administrativou. Návrh je nyní v meziresortním připomínkovém řízení.
Dle plánu Linus Torvalds odstranil souborový systém bcachefs z mainline Linuxu. Tvůrce bcachefs Kent Overstreet na Patreonu informuje, že bcachefs je nově distribuován jako DKMS modul.
PIF, Silver Lake a Affinity Partners kupují videoherní společnost Electronic Arts (EA) za 55 miliard dolarů (1,14 bilionu korun).
gvim
a nevolal všude po qvimu
v Qt.
Mimochodem Bram je asi taky strašný Windowsák, protože gvim
(alespoň ve verzi 6.4) nemá klasické gtk2 open/save dialogy, což je bohužel situace, ze které nemám radost vůbec (pokud si bude každý autor gtk programů psát vlastní file dialogy, bude to ještě horší, než je to teď). Ale co, hlavně, že jsou ty gtk dialogy tak slvěle intuitivní.
BTW: zrovna u gvimu je mi to jedno, používám :set guioptions=
/někde/01/něco/jiného
do /někde/02/něco/jiného
stejně rychle, jako u kteréhokoliv jiného dialogu s cestou, budu moc rád xdvi
.
Jinak je problém spíš v tom, že pro autory Gtk je těžké pochopit, že i když oni ten svůj výtvor považují za vrchol dokonalosti a pohodnosti používání, nemalá část uživatelů ho hodnotí úplně jinak…Tezke pochopit? Ja myslim, ze to chapu dobre, akorat je jim to fuk, protoze maji svoji cilovou skupinu "zakazniku" a te to vyhovuje.
Jisteze urcita cast startu se travi i v kodu KDE, jinak to nejde. Obzvlast kdyz kod KDE knihoven je na rozdil od kodu rxvt obecny a dela toho daleko vic[...]No jo, ale jak rxvt ukazuje, většina toho, co dělá KDE při té své inicializaci knihoven, je milé Konsoli úplně nanic a jen zdržuje. Jistě že napsat to tak, aby se vždy inicializovalo všechno, je daleko jednodušší, ale pak se autoři nesmí divit, že jim lidé nadávají, že je to ukrutně pomalé. (Hint: toto není filipika proti KDE, spíš obecně proti mentalitě tvůrců desktopových prostředí.)
Kdo si mysli, ze vyvojari KDE jsou amateri, kteri neumi programovat, a ze on by to dokazal v pohode napsat rychleji, je vic nez vitan to zkusit.Když oni ti, kteří by možná uměli, se raději spokojí s rxvt, jelikož to stejně všechno, co potřebují, dokáže
Co se tyka toho dokumentu od Ulricha Dreppera, ten samozrejme znam. Z technickeho hlediska zajimavy, ale taky ukazuje, ze lide pracujici na nizkourovnovych vecech jako kernel nebo glibc nemaji moc poneti, jak vlastne pracuji veci, ktere je pouzivaji.Věřím, že to ponětí mají, jen s C++-kovým ABI se bohužel nic moc nadělat nedá – příšerně dlouhá jména a hromady relokací se sotva dají linkovat efektivně. Neříkám, že by to nemohlo být rychlejší, ale rychlé určitě ne. Ať se na to dívám z kterékoliv strany, vždy mi vychází, že to opravdu je chyba C++ a že by naopak autoři ABI měli víc přemýšlet nad tím, jakou režii která konstrukce má. Ostatně, když za všechno může dynamický linker, proč si KDEčkáři nenapíší vlastní? Proti rozsahu celého KDE maličkost ;)
Soucasti inicializace Konsole v ramci kodu knihoven je nahrani stylu widgetu, inicializace fontu (fontconfig+xft, aby to umelo janevimco), nahrani ikon, vytvoreni menu, atd.Opravdu se mi nechce věřit, že na tyhle v podstatě jednoduché záležitosti je potřeba řádově několik miliard strojových instrukcí.
Napsat si na to kod zvlast? A jaky by byl potom smysl kdelibs, kdyz by si stejne kazdy ten kod napsal zvlast?Ne, ale například by aplikace mohla dopředu knihovně napovědět, co bude potřebovat, aby se nemuselo zbytečně inicializovat všechno.
"Optimalizovat" (tj. osekat, samozrejme, ne doopravdy optimalizovat) kod v kdelibs tak, at je to rychlejsi? A co potom flexibilita, jakou clovek potrebuje od knihoven?Viz výše.
A co treba rychlost vyvoje aplikaci?To je konečně argument, který dává smysl. Pokud je cílem KDE psát aplikace rychle a nikoliv rychlé, skládám své zbraně a odcházím z kolbiště :)
No my jsme si ho samozrejme tak trochu napsali, rikame mu kdeinit :).Ehm, kdeinit má opravdu k dynamickému linkeru daleko, je to spíš obludný hack, který se snaží všemu dynamickému linkování vyhnout. Takže to opravdu stále nevypadá, že by někdo ukázal, jak lze C++ linkovat rozumně.
Prekvapeni, ze jo :( ? Vetsina veci pri startu je vlastne strasne rychla, jen se jich dela moc a ono se to nasklada.Stokrát nic sice umořilo osla, ale kdyby tohle byla samá nic, musely by jich být miliony. Spíš bych řekl, že u většiny těch věcí si nikdo moc nelámal hlavu, jak rychlé jsou, protože jsou přeci jednoduché, a ono se to pak naskládalo...
Navic hodne z toho jsou inicializace knihoven, ktere KDE pouziva, a s tim se potom dela neco daleko hur (treba jednu dobu inicializace fontconfigu byla az 1/3 startu KDE aplikace).Zrovna fontconfig je udělaný tak šíleně, že je skoro svatou povinností autora desktopového prostředí ho přepsat ;)
[...] nebo program, ktery bude existovat, bude delat, co se od nej chce a bude jen pomaly?To je tak trochu protimluv – aby byl program použitelně (či ještě lépe příjemně) rychlý, je přeci součást toho, co se od něj chce.
Jisteze by to slo. Staci treba umyslne porusit to povetsinou zbytecne pravidlo, ktere -Bdirect porusuje, a je to :).Nesouhlasím, -Bdirect vyřeší pouze zlomek všech problémů. Pokud knihovna obsahuje desítky tisíc příšerně dlouhých symbolů a srovnatelný počet relokací, bude se sotva linkovat rychle. Přitom značná část těch symbolů nejspíš vůbec nepotřebuje být zvenku viditelná a většiny relokací by se také šlo zbavit. Ale to už jsme trochu odbočili, ona se stejně většina času netráví v dynamickém linkeru. Zkusil jsem si teď strace na Konsoli a překvapilo mne, že při startu provede 5721 syscallů, z čehož například několik stovek se zabývá úplně zbytečným prohledáváním všech možných i nemožných adresářů v /usr/share/icons ... to zrovna nevypadá na věci, které je při startu nezbytné udělat.
Zkusil jsem si teď strace na Konsoli a překvapilo mne, že při startu provede 5721 syscallů, z čehož například několik stovek se zabývá úplně zbytečným prohledáváním všech možných i nemožných adresářů v /usr/share/icons ... to zrovna nevypadá na věci, které je při startu nezbytné udělat.Zvláštní, že mně
strace -c konsole
dává jen 1008 syscallů.
"Samotna poucka rika, ze se maji vybrat jen dve z nich, protoze vsechny tri mit nejde".Jenže ta poučka hovoří o čase potřebném na vývoj, ne o rychlosti výsledku, není-liž pravda?
A vubec, kdyz je to tedy vsechno takova trivka, co si usetrit cas a misto tohohle povidani mi zkratka rovnou poslat ty patche?Rád bych, ale tohle bohužel není na pár patchů, nýbrž na dosti zásadní redesign. Asi raději zůstanu u toho rxvt a podobných starých dobrých aplikací
Rekl bych, ze setrvacnost (tedy krom toho, ze na Windows je vsechno totalne spatne, ELF je prece skvely a tak).No tak ja by som povedal, ze to je jeden z najhlavnejsich problemov. Plno ludi nadava na windows, ale vacsina vobec netusi, ako funguju. Ked si clovek zacne citat v ich SDK, tak dojde na to, ze kopec veci je tam robenych na co najvacsiu rychlost. To, ze to nefunguje az tak ako autori mysleli, je vec zlej implementacie, ale nechcem tu obhajovat windows. Pravda je, ze teoreticky sa da navrhnut super system, kde je vsetko abstrahovane, ale asi by ten vykon za vela nestal (volat na kazdu vec funkciu..). Preto sa mi paci java, lebo tam sa to zoptimalizuje viacmenej za behu
Dneska je nejvetsi problem pomalost cteni z disku.Ale ved tie kniznice sa strankuju postupne, ako sa vykonava kod, nenahravaju sa vsetky naraz a cele. Niekde v ld je taky prepinac, co oprofiluje kod tak, aby boli funkcie ktore sa casto volaju "pri sebe", teda najlepsie na jednej stranke, zabera to potom menej pamate a malo by sa to aj rychlejsie nacitat. Skusal to niekto?
A ne, kernel to vicemene neumi. Dokud si neumi ta data poskladat na disku na jedno misto a precist to naraz, tak to proste bude trvat dlouho.Tak si urobte FUSE ovladac ktory tie data na to jedno miesto da a hotovo
Treba sa len dohodnut, ktore hlavne kniznice ktory priestor dostanu a ostatne nemusia by prelinkovane.Ale přesně tohle linuxový prelink dělá, ne?
Ja som si vzdy myslel, ze toto robi IO scheduler, ze preusporaduva poziadavky tak, aby sa data citali z disku co najefektivnejsie.To samozřejmě scheduler dělá, ale jen tehdy, když o těch všech požadavcích ví, tedy když vzniknou najednou. Pokud nějaký program čte soubory postupně, těžko s tím kernel něco zmůže
Ale přesně tohle linuxový prelink dělá, ne?Tak kde je problem s adresnym priestorom? Mam taky dojem, ze to robi len s nejakym prepinacom, ale ide o to, ze to ide nastavit.
To samozřejmě scheduler dělá, ale jen tehdy, když o těch všech požadavcích ví, tedy když vzniknou najednou. Pokud nějaký program čte soubory postupně, těžko s tím kernel něco zmůžeTak to si musim pozret ako ta cache vlastne funguje, lebo takto sa mi zda akoby nahradzala zbytocne diskovu cache.
A preco to vlastne nemoze fungovat na 100% ako pri DLLkach? Tie su vlastne prelinkovane vsetky.Důvod je jednoduchý: i386 má tak maličký adresní prostor, že se do něj nemají všechny nainstalované knihovny šanci vejít. O něco vzdáleně podobného se pokouší zde již zmiňované prelinkování: podívá se, které knihovny se používají současně a zkusí je předpřipravit pro umístění na takových adresách, aby se pokud možno vešly a navzájem nepřekrývaly. Když za běhu nastane jakákoliv kolize, dořeší se to stejně jako normálně relokacemi.
Tiskni
Sdílej: