Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
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.
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
13.10.2011 20:46
Fluttershy, yay! | skóre: 93
| blog:
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
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“.
13.10.2011 17:34
Fluttershy, yay! | skóre: 93
| blog:
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
14.10.2011 00:36
Fluttershy, yay! | skóre: 93
| blog:
13.10.2011 18:13
Fluttershy, yay! | skóre: 93
| blog:
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
15.10.2011 10:22
Fluttershy, yay! | skóre: 93
| blog:
15.10.2011 11:09
Fluttershy, yay! | skóre: 93
| blog:
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...
15.10.2011 14:13
Fluttershy, yay! | skóre: 93
| blog:
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]
15.10.2011 14:59
Fluttershy, yay! | skóre: 93
| blog:
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( ) )
15.10.2011 16:34
Fluttershy, yay! | skóre: 93
| blog:
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
15.10.2011 23:42
Fluttershy, yay! | skóre: 93
| blog:
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.
16.10.2011 13:50
Fluttershy, yay! | skóre: 93
| blog:
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...
15.10.2011 21:23
Fluttershy, yay! | skóre: 93
| blog:
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
