Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
i--;
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. \*/
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;
free(dmr);
R.I.P.
Nasledujúci týždeň mením pozadie pracovnej plochy na tento wallpaper.
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]
interface_a.interface_b.interface_d[ i ].interface_c.foo( interface_x.interface_y.get_neco( ) )
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>
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...
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ěžuje Těch nemainstreamových až experimentálních jsou mraky.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.
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.
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?
Tiskni Sdílej: