Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Základním principem copy-on-write je pozdržení vytvoření celkové kopie objektu tak dlouho, dokud to není potřeba - tedy dokud se do objektu nezapisuje. Při realizaci této metody se třídy, které mají mít tuto vlastnost, vybaví počítadlem, které se inkrementuje při vytvoření kopie; při zápisu do daného objektu se pak v případě, že počítadlo je nenulové (tedy existuje kopie), vytvoří fyzická kopie objektu a původní počítadlo se dekrementuje. Implementačně se třída využívající copy-on-write obvykle obalí do jiné třídy, která zajišťuje tuto funkcionalitu.
Při implementaci je tedy potřeba odchytit dvě operace - vytváření kopie a zápis do objektu. Vzhledem k tomu, že je náš projekt napsán v C++, to umožňuje snadno rozlišit, které objekty jsou modifikovatelné, a které ne (díky klíčovému slovu const). Vytvořili jsme tedy obalující třídu (šablonu), která při vytváření kopie objektu (ať už pomocí kopírovacího konstruktoru či virtuální metody clone) zvýší vnitřní počítadlo. Navenek je dále schopna se "přetypovat" na původní třídu - a to za pomoci konstantních metod (které nevytváří kopii objektu) i nekonstantních metod (u kterých se naopak kopie objektu vytváří). Tohoto je možno dosáhnout mimo jiné pomocí operátor *, ->, případně operátoru přetypování.
Zde je vhodné zmínit jednu nepříjemnou vlastnost C++:class Trida { const int& get() const; int& get(); }; Trida t; const Trida& c; const int& a = c.get(); //Zavola se const metoda const int& b = t.get(); //NEzavola se const metoda!
Pro copy-on-write by bylo vhodné, aby se při přiřazení do proměnné b volala konstantní metoda, zatímco ona se volá nekonstantní (která v kontextu copy-on-write způsobí zbytečnou kopii). Tento problém lze vyřešit buď magií se šablonami (jen v omezené míře; viz dále), přejmenováním nekonstantní metody (třeba na mutable_, neboť mutable je klíčové slovo) nebo použitím ošklivé konstrukce.
Pro náš projekt jsme postupně vyzkoušeli dvě implementace, které se liší přístupem k danému problému - jedna implementuje copy-on-write pro konkrétní třídy (interně nazvaná COW), druhá obaluje všechny objekty v mapě objektů (interně SharedDataPointer). Obojí však řeší problém domén, což jsou naše reprezentace proměnných analyzovaného programu. Všechny třídy, kterých se copy-on-write týká, jsou pak potomci třídy Domain.
V tomto přístupu bylo snahou při vytváření instance domény vytvořit objekt, který se bude tvářit jako doména (bude potomkem třídy Domain) a interně si bude držet instanci vlastní domény, pro kterou bude dělat delegaci volání metod. Protože v projektu často pracujeme i se základní třídou Domain, implementuje třída COW všechny metody této třídy. Pro přetypování z Domain na potomka používáme vlastní šablonovou funkci, což umožňuje nejen přetypování z COW třídy na instanci obalené třídy, ale zároveň to řeší (s pomocí menší šablonové magie) problém s přiřazením nekonstantních objektů do konstantních (více viz zde).
Vlastnosti tohoto přístupu:V našem projektu máme mapu, která drží všechny proměnné použité při analýze programu. Dalším řešením tedy je při ukládání do této mapy obalit veškeré domény, a při jejich čtení nedělat kopii a při zápisu ano.
My jsme se nakonec rozhodli pro druhý přístup, neboť vyžaduje méně změn v kódu a protože většina dat je uložena na jednom místě. Pro efektivní využití bylo však potřeba kód ještě projít a zjistit místa, kde dochází ke kopiím - spousta těch míst totiž tvořila kopii i v momentě, kdy to nebylo potřeba (třeba operátor porovnávání). A jaké byly výsledky (měřili jsme čtyři programy z Coreutils) ?
Díky použití copy-on-write se nám povedlo nejen náš projekt zrychlit, ale především ho učinit použitelným pro další programy (již se zvládneme zpracovat více než 70 programů z Coreutils). Zároveň to náš projekt zrychlilo, neboť již není potřeba provádět operace na objektech, které byly kopiemi jiných objektů.
Projekt canal se zabývá statickou analýzou nad programy v jazyce C přeloženými do LLVM bytecode (potenciálně však i pro další jazyky přeložené do LLVM). Tento přístup umožňuje zjistit nadmnožinu všech možných hodnot proměnných v programu. Naší snahou je toto umožnit nad co největším množstvím programů. Tento projekt je vytvářen pod Fakultou informatiky Masarykovi univerzity a podporován společností Red Hat.
Tiskni
Sdílej:
Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.
Samozrejme se vtira otazka, odkud prichazi ten pozadavek vytvaret kopie, ktere pak nejsou potreba.Tuhle otázku jsem níže naťuknul taky.
Při realizaci této metody se třídy, které mají mít tuto vlastnost, vybaví počítadlem, které se inkrementuje při vytvoření kopieTuhle část snad chápu, takže tuším, že tím máš namysli asi spíš že se inkrementuje místo vytvoření fyzické kopie, tudíž to „při vytváření kopie“ by rozhodně zasloužilo reformulovat. Ale to už jsem řešil v jiné diskuzi, že mnozí mají stále ještě náhled na OOP pokažený implementačními detaily C++. Obecný popis toho, co chceme dělat, by neměl vyžadovat přepnutí mozku na C++ mód :D. Takhle, já tě nechci nijak prudit, ale celý ten článek vypadá jako když jsi ho psal pro sebe, tedy pro člověka, který do toho vidí. Já jsem z něj byl schopný pochytit co obecně obnáší copy-on-write (což už jsem znal), nějaké ty statistiky jak to pomohlo. Ale že bych bez zkoumání samotného kódu chápal, co se vlastně děje, jestli se to nějak uplatí i u nových objektů, a hlavně, proč je pro daný projekt relevantní zrovna kopírování existujících objektů. A když už popisuješ konkrétní metody jak toho dosáhnout, tak bych chtěl nejdřív vědět, co daná metoda obnáší, a pak teprve pracovat se specifickými pojmy jako šablonová funkce apod. Něco ve stylu (a teď kecám, protože jsem to zdaleka všechno nepochopil)... Nové instance tříd se vytvářejí běžným způsobem. Ale protože canal dělá … a k tomu potřebuje často udržovat kopie již existujících instancí, které z důvodu, že …, často zůstávají nezměněné, a protože bychom neradi měnili celý datový model, rozhodli jsme se použít metodu copy-on-write. Umožnuje nám to ušetřit paměť, protože nemusíme alokovat … až do chvíle, kdy se do nového objektu zapisuje. A teď bych očekával technické vysvětlení toho, jak je možné se vyhnout té alokaci… Místo stovek bajtů pro celý objekt tak můžeme alokovat proxy objekt, který obsahuje informaci, že je zatím nezměněný a odkaz na datový objekt, který využíváme pouze pro čtení. První zápis pomocí proxy objektu způsobí zkopírování datového objektu a zrušení příznaku pouze pro čtení. Od této chvíle se prostřednictvím proxy objektu čte a zapisuje nový datový objekt. Když se nový proxy objekt klonuje, znovu se označí jako read-only. Ve skutečnosti je tam potřeba ten reference counting kvůli dealokaci, ale nechtěl jsem ty ukázky příliš komplikovat. Minimálně takhle nějak bych si představoval text, který mi má předat něco nového.
na dva způsoby řešení (pro třídu a pro místo)Subjektivně vnímám, že tento účel nesplnilo.
že to může mít opravdu velký přínosTento účel splnila ta tabulka časů a nebyl by k tomu potřeba zbytek článku.
šlo mi především o to ukázat, že když už se rozhodnete ho využít, abyste měli nějakou inspiraci jak.Opět subjektivně vnímám jako nesplněné.
Pro mne z toho plyne důležitá zkušenost, že jsem to měl napsat před dvěma měsíci, když jsme to implementovali, a ne až nyní - v ten moment bych nejspíš napsal dvakrát tak dlouhý zápisek, který by to rozebíral víc ze široka (a tedy by i nejspíš pokryl věci, které ti tam chybí).To je dost možné. Ono taky záleží na tom, jak moc má člověk na to psaní chuť a čas.
Tento článek už upravovat nebudu, neboť by to nejspíš vyžadovalo kompletní přepsání, a to se mi z různých důvodů nechce.Není zapotřebí vypilovávat tenhle jeden článek, spíš se opravdu těším na zlepšení u těch příštích :).
Tento článek už upravovat nebudu, neboť by to nejspíš vyžadovalo kompletní přepsání, a to se mi z různých důvodů nechce.Já být tebou, tak to moc nehrotím. V čechách je problém najít texty o programování, které jsou určeny lidem, jenž už o programování něco vědí. Takové to běžné meziprogramátorské povídání, které se dá najít třeba na redditu. Co ovšem není problém, je sehnat tu tisíc úvodů do něčeho, zas a stále znova. Nechápu proč, imho nemusí být každý blogpost srozumitelný pro všechny kdo náhodou půjdou kolem.
Očekávané nadávky na C++ pod článkem týkající se C++.Zřejme jsi si spletl vlákno.
nicméně tím, že druhý odstavec ho „jakoby“ vysvětluje spoustu lidí zmátl a očekávali, že se tedy dozví co to ten COW je.Což mimochodem není můj případ, jak se gogloid mylně domníval.
Přesto bych byl rád, aby takovéto články vznikaly.To už jsem psal výše. Kdyby se vytáhly obsah i forma do srozumitelné úrovně, rád bych to viděl mezi vydanými články.
Pochopil jsem, že žádný jazyk, který existoval, existuje a bude existovat podle zastánců čistého OOP neobsahuje to správné a dokonale čisté OOP.Smalltalk.
Pochopil jsem už dávno, že mainstreamově prezentovaná touha po správném OOP je chiméra, něco jako sektářská víra.To je samotná touha po čistě OOP jazyce. V praxi velmi rychle zjistíte, že jsou běžné situace, které s OOP jazykem řešíte půl hodiny při odtržení jednorázové definice od jejího použití, zatímco s dobrou podporou funkcionálních jazyků to máte za pět minut a přehledně (třeba řazení podle řetězce xorovaného nějakou hodnotou — funktor vs. lambda).
Mě hlavně fascinuje, jak všichni hledají to správné OOP.Mě spíš facinuje, že jsi můj příspěvek sice nepochopil, zato ti to nijak nebrání dělat chytrého.