Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Pro moddery Minecraftu: Java edice Minecraftu bude bez obfuskace.
Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
13.10.2011 14:41
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
13.10.2011 20:34
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
14.10.2011 13:38
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
14.10.2011 15:55
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
13.10.2011 22:27
belisarivs | skóre: 22
| blog: Psychobláboly
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
13.10.2011 11:53
13.10.2011 12:12
13.10.2011 20:46
i--;
13.10.2011 16:33
poky74 | skóre: 36
| blog: Zápisník
| Vrchlabí
Nedokážu říct proč, ale tenhle komentář mě silně vnitřně zasáhl, v kladném slova smyslu.
Zatím asi nejlepší "rip" co jsem četl.
/\* \* If the new process paused because it was swapped out, \* set the stack level to the last call to savu(u_ssav). \* This means that the return which is executed immediately after \* the call to aretu actually returns from the last routine which \* did the savu. \* \* You are not expected to understand this. \*/
13.10.2011 12:30
xkucf03 | skóre: 49
| blog: xkucf03
13.10.2011 14:35
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
médium -> médii
Přejatá podstatná jména (z latiny nebo řečtiny), která mají před -um samohlásku, skloňujeme v jednotném čísle a v 1., 4. a 5. pádě množného čísla podle vzoru „město“, ostatní pády množného čísla jsou podle vzoru „moře“.
RIP, dmr
"C is quirky, flawed, and an enormous success."
"UNIX is very simple, it just needs a genius to understand its simplicity."
dennis_ritchie = NULL;
.
13.10.2011 23:57
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
13.10.2011 12:46
free(dmr);
14.10.2011 07:31
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
R.I.P.
Nasledujúci týždeň mením pozadie pracovnej plochy na tento wallpaper.
14.10.2011 08:49
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Worse Is Better
A teď vážně ( ten smajlík znamená, že to myslím z legrace). Myslím, že C hned tak nenahradíme. Třeba takový kernel si dost těžko dovedu představit napsaný v něčem jiném...
ty vyšší jazyky umožňují zapsat všechno, co u mí C (případně by je stačilo trochu rozšířit)
Jistě, když jsou turingovsky úplné.
Je to úplně jedno, ale ono je C jaksi široko daleko nejjednodušší, takže se překladač dobře portuje.
Jistě, když jsou turingovsky úplné.[joke] Hehe to by chtělo vytvořit jazyk, který by byl víc než turingovsky úplný. Například by emuloval orákulum
. [/joke]
[sarkasmus] Napr. bych rekl ze zjisteni jak funguje rozsahlejsi program v Pythonu, nebo zjisteni co opravdu dela nejaka funkce v Jave, je mnohem tezsi, nez ziskat pravdivou odpoved z kristalove koule [/sarkasmus]
Určitě ne vždycky. Ale rozhodně je to příjemnější, než louskat zápis ve stylu
interface_a.interface_b.interface_d[ i ].interface_c.foo( interface_x.interface_y.get_neco( ) )
13.10.2011 22:59
import bflmpsvz as x
<xsl:call-template name="nějakáFunkce">
<xsl:with-param name="parametr1" select="h:html/h:body/node()[1]"/>
</xsl:call-template>
Zato ta Java je dost jednoduchá, dá se snadno zorientovat i v cizím kódu a těch záludností je tam minimum.
nebo zjisteni co opravdu dela nejaka funkce v JaveKdyž už tak metoda – pokud skutečně „funkce“, tak je to statická metoda a tam je to ještě jednodušší.
Když už tak metoda – pokud skutečně „funkce“, tak je to statická metoda a tam je to ještě jednodušší.Sorry, to byl trochu "technický překlep".
Jinak ano, java je jednoduší ale u Javy se mi právě moc nelíbí jak koncept interfaces, tak špagetový způsob tvorby metod : chci provést nějakou operaci, zavolám metodu A( ), ta volá metodu B( ), ta volá C( ) > D( ) > ... a až konečně metoda J( ) něco udělá. Je to extrémní příklad - uznávám - ale dost dobře to ilustruje situaci. Další věcí která nikdy u mě nebudila důvěru automatizovaná zpráva zdrojů. Přiznávám, je to osobní a neobjektivní pohled člověka zvyklého na způsoby a styl v C/C++ ...
Moc nechápu, jak můžeš házet Javu a Python do jednoho pytleNetvrdím že Java je to stejné co Pýthon, osobně ji snesu raději (Moje averze ke krajtám je tak velká, že pokud je to jen trochu možné, tak se aplikacím v pýthonu na sto honů vyhnu). To samé o javovských programech říci nemohu, ale najdu-li odpovídající alternativu, pak jsem nemilosrdný...
a ty vyšší jazyky umožňují zapsat všechno, co u mí C (případně by je stačilo trochu rozšířit)No jo, ale za jakou cenu? Cim vyssi mira abstrakce, tim narocnejsi a slozitejsi je potom i vysledny program...
15.10.2011 18:59
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Pánové, vy jste dvojka
15.10.2011 23:35
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
K napsání operačního systému je potřeba trochu nepřenositelného assembleru a libovolný vyšší programovací jazyk, od Ady k Lispu.Chci vidět výkon takového systému.
ukazatelová aritmetika je pak naprostá zbytečnostV kernelu?
Jistý mainstreamový operační systém není napsaný v plain C a na jeho výkon si myslím nikdo nestěžujeK napsání operačního systému je potřeba trochu nepřenositelného assembleru a libovolný vyšší programovací jazyk, od Ady k Lispu.Chci vidět výkon takového systému.
Těch nemainstreamových až experimentálních jsou mraky.
To si piš. Abych to zkrátil: Jsem extrémista a unix hater, sežerte mne! :-Pukazatelová aritmetika je pak naprostá zbytečnostV kernelu?
a Windows pokud vím mají kernel z velké části v C++Ne-e, pokud vím, tak kernel je z většiny v C, v C++ budou tak maximálně některé drivery. A pak vyšší věci, samozřejmě (shell,...). Ten článek o Lisp Machines jsem četl, no, určitě to je z hlediska IT docela zajímavá technologie, ale beru to osobně spíš jako zajímavost než něco, co by mohlo v reálu soutěžit s mainstreamem... No a jinak co se týče hrůzy C a UNIXu, zkus se na to podívat takhle
Mluvit o rychlosti programovacího jazyka je dost problematické. Prakticky má smysl bavit se o konkrétních implementacích. Například virtuální stroj Selfu dokázal zpracovavat čtyři instrukce bytekódu jedinou instrukcí assembleru.
Řekl byste dnes, že Self je rychlejší než Java? A řekl byste to v době, kdy nejrychlejší virtuální stroj Javy byl napsán v Selfu? Řekl byste dnes, že JavaScript je rychlejší než Dart?
Například virtuální stroj Selfu dokázal zpracovavat čtyři instrukce bytekódu jedinou instrukcí assembleru.Na x86? TO musel bejt zajímavej bytekód
.
Řekl byste dnes, že Self je rychlejší než Java? A řekl byste to v době, kdy nejrychlejší virtuální stroj Javy byl napsán v Selfu? Řekl byste dnes, že JavaScript je rychlejší než Dart?Jo to nevím, ale řekl bych, že céčko je rychlejší než všechny výše jmenované.
Řekl byste dnes, že JavaScript je rychlejší než Dart?Dneska možná, ale za rok už stěží, a to v obou implementacích (DartVM i Dartc)
Kolik taktů trvá v Lispu získání třeba padesátého prvku pole o délce 100? V assembleru x86 to trvá jednu instrukci, třeba mov ah,[bx+50].Pekelně záleží na implementaci, dnešní Common Lispy (kde je pole jako zabudovaný datový typ) pravděpodobně vygenerují něco podobného.
) by na architektuře, kde jde přímo sebrat několik bajtů okolo zadané adresy, bylo hooodně neefektivní.
Čistý jazyk LISP se ale na kernel pro "moderní" procesory nehodí, protože zesložiťuje práci oproti konkurenci.
16.10.2011 19:58
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Kolik taktů trvá v Lispu získání třeba padesátého prvku pole o délce 100?
Jen k tomuto. Ta otázka předpokládá, že bude potřeba náhodný přístup k datům a zároveň, že to poběží na procesoru typu x86. Ani jedno z toho nemusí být splněno, jednak nutnost přístupu k náhodnému prvku může být chyba návrhu a také pro ten jazyk může (a je) k disposici speciální HW.
Lisp Machines ran the tests in parallel with the more conventional single instruction additions. If the simultaneous tests failed, then the result was discarded and recomputed; this meant in many cases a speed increase by several factors. This simultaneous checking approach was used as well in testing the bounds of arrays when referenced, and other memory management necessities (not merely garbage collection or arrays).připomíná bazvórdy jako ígr exekjůšn nebo bránč prídikšn.
Chci vidět výkon takového systému.A proč by se vyšší programovací jazyk měl negativně podepsat na výkonu?
.
Vždyť to eval může podporovat, ale pokud ho v celém programu nepoužiji, tak není důvod, aby program běžel pomalu.Pokud chceš udělat plnohodnotný perl OS, tak ho podporovat musíš, protože nemůžeš zaručít (ze všech programů co na něm poběží), že ani jeden nebude využívat eval. A nebo to můžeš zakázat, ale pak bych to nenazýval perlem. Já bych osobně C++ za nějak moc vyšší jazyk nepovažoval, hlavně pokud je právě staticky typovaný. To je jako analogie mezi strojákem a jazykem symbolických adres. U toho druhýho ses taky nemusel zajímat o to, na které přesně adrese má být jaká instrukce. Právě bych od jazyka vyššího než céčko očekával, že nebude brát v potaz, zda je proměnná řetězec nebo číslo. Ovšem bude to o něco pomalejší než statické typování. Mě by se třeba líbil jazyk, kde bych mohl uložit číslo do proměnný a pak ho číst jako řetězec, ale abych ho mohl použít i pro zápis do hardwaru (takové to unsigned val:4;). Zároveň abych ale mohl přímo indexovat prvky pole a třeba to pole překopírovat prostým přiřazením. Jazyk by byl vyšší, protože bych se nemusel starat o převody řetězec←→integer, dostal bych okamžitě (z hlediska zdrojáku) požadovaný index pole a nemusel bych se patlat s memcpy.
Právě bych od jazyka vyššího než céčko očekával, že nebude brát v potaz, zda je proměnná řetězec nebo číslo.WTF? Mluvíme o vyšších programovacích jazycích, nebo o programovacích jazycích se slabým typovým systémem? To jsou dvě různé věci. Nebo teda hodně různých věcí: silný vs. slabý typový systém, statický vs. dynamický typový systém, high-level vs. low-level jazyk, to jsou naprosto ortogonální věci. (Dokonce bych řekl, že pokud existuje staticky a zároveň slabě typovaný jazyk, pak je to právě Céčko.)
A proč by se vyšší programovací jazyk měl negativně podepsat na výkonu?Protože to znamená SW vrstvu navíc mezi kernelem a HW. Leda by ten vyšší jazyk podporoval přímo HW, ale ještě jsem neviděl, aby takovej HW byl rychlej...
Přijde mi, že mluvíš spíš o type-safe vs. -unsafe, než low-level vs. high-level jazyk.Ano. Snažil jsem se vysvětlit, proč by mi C++ v jádře nevadilo.
"Myslím, že jádro operačního systému by mělo být především spolehlivé. A ke spolehlivosti Vám může pomoci typový systém – silnější typový systém Vám dovolí přesněji popsat, co jednotlivé funkce dělají. "Ano, to máte naprostou pravdu. Já však vyjadřuji obavu z toho, že nástroje a abstrakce v C++ jsou natolik silné, že by víceméně spíš přispěly k nepořádku a nepřehlednosti celého projektu. Potom jde i spolehlivost do háje. Dost se bojím toho, že by to prostě správce projektu neudržel v únosné míře, nebo by musel silně omezit možnosti jazyka, které je možno v kódu pro daný projekt využít. Myslím, že taková drastická omezení by z něj udělaly jen o něco málo lepší C. A je otázka, jestli by se to potom vyplatilo. Já se domnívám, že asi ne.... To je ten nejhlavnější důvod proč jsem tolik proti převodu kernelu do C++.
A právě zde jazyk C naprosto selhává a C++ je na tom o něco málo lépe.Pro tyto účely vypadá velmi dobře programovací jazyk Habit.C je procedurální jazyk, a C++ je typový jazyk. Tomu myslím i odpovídá přístup k typům. Přiznám se,že Haskellu a jeho dialektům moc nerozumím, vím o něm jen základní informace (čistě funkcionální jazyk, statické typování, děsný způsob zápisu, vhodný a původně zamýšlený spíše pro akademické účely), nemluvě o jeho dialektech; takže v případě Habitu nemohu moc posuzovat.
Samozřejmě v obou případech jde o "bezpečnou" podmnožinu C++, takže takové fíčury jako rtti, exceptions nebo templates nejsou povolené.Neobhajoval tady někdo výjimky jako lepší způsob řešení jaderných chybových stavů, než GOTO? Že by astrolog?
Ne, výšin osvícení Velkého mistra Foo určitě nedosahuji, ještě se mám od něj čemu učit
14.10.2011 11:51
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Tiskni
Sdílej:
14.10.2011 20:24
