Po 9 týdnech vývoje od vydání Linuxu 7.0 oznámil Linus Torvalds vydání Linuxu 7.1. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a časem také na Linux Kernel Newbies.
Cheat Engine (Wikipedie) je s verzí 7.7 k dispozici už také pro Linux. Jedná se o proprietární skener/debugger paměti používaný především k cheatování v počítačových hrách.
Vláda USA nařídila společnosti Anthropic pozastavit přístup k modelům Fable 5 a Mythos 5 pro všechny cizince, včetně zaměstnanců Anthropicu.
Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
GCC 4.5 lze poprvé zkompilovat C++ překladačem.
Tiskni
Sdílej:
Nechápu moc význam takových zpráviček, já do toho moc nezasvěcený, jsem nepochopil, co z toho vyplývá a podobně :(
GCC 4.5 is the first release of GCC that can be compiled with a C++ compiler. This may not seem very interesting or useful at the moment (but take a look at the much improved -Wc++-compat option). However, this is only the first step of an ongoing project to use C++ as the implementation language of GCC. Except for some front-end bits written in other languages, notably Ada, most of GCC is implemented in C. The internal structures of GCC are under a continuous improvement and modularization aimed at creating cleaner interfaces, and many GCC developers think that this work would be easier using C++ than C. However, this proposal is not free of controversy, and it is not clear whether the switch would occur in GCC 4.6, later, or ever.
).
Imho by to mohlo znamenat lepší optimalizace v gcc, protože překladač C++ překládá stejně anebo lépe (ne hůře) než překladač C... Kdysi se o tom tady mohutně diskutovalo v blogu.imho se jednalo o jeden z uzasnych flamu s panem ponkracem v hlavnim roli.
překladač C++ překládá stejně anebo lépe (ne hůře) než překladač C[citation neeeded]
Pan děda.jablko by jistě udělal lépe, kdyby předložil nějaký zdroják v C, který by vygeneroval rychlejší, či lepší kód, než jeho efektivní ekvivalent v C++. Protože nic takového není už z principu možné, tak deda.jablko stojí argumenty na vodě.takze pane pankraci... stejne jako v matematice, pokud se nekdo vyslovi nejake tvrzeni, mel by jej dokazat. jinak se jedna o pouhou domenku a je potreba tak s ni i nakladat. ja jsem se zadneho takoveho tvrzeni o rychlosti C/C++ nedopustil, proto nemam potrebu cokoliv dokazovat.
protože bez lží, úskoků, umělých zneefektivnění C++, či Vaší neschopnosti psát v C++ prostě nepřinesete jediný zdroják v CHeh pomocí tohodle toho se dá zdroják odsoudit víceméně vždy :-/.
Je to jediná cesta, jak efektivně projekt udržet a nezbláznit se z toho, nehledat kvantilióny chyb, ambiguos identifiers, jak kooperovat s daleko větší graciézností ve více lidech a jak snadněji projekt udržovat.Ovšem zajímavý je, že mě obvykle vadí častější chyby ve velkých projektech. V těch menších se s nima ani nesetkávám.
.
Hmm v čem je napsaný kmail, konqueror a firefox? Například ty jsou poměrně nestabilní (vlastně celé KDE 3.5), tedy alespoň v porovnání s jádrem třeba.
.
Kmail, Konqueror a KDE 3.5 nestabilní? No to jsou mi věci....projdi si jejich bugzillu, ty backtracy si my, méně šťastnější, kterým to narozdíl od tebe padá (resp. padalo i v dobách KDE 3.5), fakt necucáme z palce
No moment. Tebe neučili ve škole, že každý program má alespoň jednu chybu? No a co takový moloch jako KDE, ale pod pojmem nestabilita si představuji něco opravdu jinéhoKmail, Konqueror a KDE 3.5 nestabilní? No to jsou mi věci....projdi si jejich bugzillu, ty backtracy si my, méně šťastnější, kterým to narozdíl od tebe padá (resp. padalo i v dobách KDE 3.5), fakt necucáme z palce
Navíc hodně záleží na systému, konfiguraci stroje, ... uživateli, ech sorry, to se tam dostalo nějakým nedopatřením...
Já mám dobu KDE 3.5.10 a dokud nenajdu nějaký "ekvivalent" tak u něj budu muset vydržet a šlape bez problému... :o)
To mi připomnělo včerejší oběd s kolegou z Monaca. On takový: "A co na projektu vůbec děláte, že je vás tolik?"
A projekťák odpověděl: "No, já jsem Project Manager, tady ten je Implementation Manager, tenhle je Documentation Manager a támhleten je Developer."
Reakce byla směšná, ale je spíš k pláči: "Tři manažeři na jednoho vývojáře?"
Ono to podle mě není o jazyku, ale spíš o schopnostech daného programátora / týmu. Se stejnými argumenty chodí javisté, zastánci C#, nebo Lael Ophir. Je to trochu o ničem. Se špatným, nedomyšleným konceptem, nevhodně použitými nástroji jazyka, nedostatečnou kontrolou vyjímek, chybových stavů (a pod...) se dá dokonale zmršit projekt v sebelepším programovacím jazyku... V opačném případě to můžete, podle mě, tvořit třeba v assembleru (máte-li k tomu potřebné znalosti a dispozice) a výsledek bude perfektní....
Chci říct, že to, jak bude projekt ve finiši vypadat a fungovat není podle mého názoru ani tak věcí jazyka, ale spíše lidí kteří na něm pracují. Konec konců stačí se podívat na projekty v tom poslední dobou tolik preferovaném Pýthonu...
Chci říct, že to, jak bude projekt ve finiši vypadat a fungovat není podle mého názoru ani tak věcí jazyka, ale spíše lidí kteří na něm pracují. Konec konců stačí se podívat na projekty v tom poslední dobou tolik preferovaném Pýthonu...Problém jednoduchých jazyků je v tom, že v nich programují jednoduší lidé.
Problém jednoduchých jazyků je v tom, že v nich programují jednoduší lidé.jak se podle tebe měří jednoduchost jazyka? - já jen, že kdysi jsme dostávali od matfyzáků takový úkolík napsat něco v jazyce, který měl asi tři instrukce ... pak na to navazovalo nějaké dokazování, že v tom jazyce lze řešit stejné úlohy jako např. v Pascalu a zobecnění, nevím přesně, už si houby pamatuju ... nicméně, někteří studenti jiných nejmenovaných VŠ nejenže takové úložky nedokázali řešit (a směle bez důkazu tvrdili, že to nejde), ale měli vážné problémy pochopit, i když už jim člověk to řešení předhodil ... přitom na první pohled ten jazyk vypadal přeci jednodušeji než třeba nějaké to Cčko nebo C++, ve kterém každý druhý již sepsal nějakou semestrálku ...
Imho by to mohlo znamenat lepší optimalizace v gcc, protože překladač C++ překládá stejně anebo lépe (ne hůře) než překladač C... Kdysi se o tom tady mohutně diskutovalo v blogu.Ano, s výsledkem, že nikdo nenašel případ, kdy by překládalo C++ lépe
.
Ale zrovna u překladače je to krapet zapeklité. Současné GCC je psané tuším v C89 (nebo tak něco) a k jeho přeložení stačí nějaké prehistorické GCC (nebo jiný prehistorický překladač), což se může hodit při bootstrappingu nějaké exotické platformy.