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.
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.
Byla vydána verze 1.6.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus. Nejnovější verze Lazarusu je postavena na Free Pascal Compileru 3.0.0. Podrobnosti v poznámkách k vydání.
Tiskni
Sdílej:
20.2.2016 16:21
Petr Tomášek | skóre: 39
| blog: Vejšplechty
ale hlavně z jednoho projektu můžeš dělat nativní aplikaci pro Qt, Gtk, Win32 nebo Carbon pro (MacOS)Jak to souvisí s tím, že máš v systému další samostatný textový editor a pár věcí okolo na další programovací jazyk?
To mají všechno zahodit a udělat jen nějakej blbej plugin do Eclipse?Tak pokud jim Eclipse připadá super, tak proč ne. Pokud jim připadá lepší mít vlastní, pak zase nevidím důvod se za každou cenu omezovat na FreePascal. Ale třeba je někde na webu dobré zdůvodnění, proč je můj dojem špatný.
podobně fungují wxWidgets.To je taky IDE? Na webu píšou, že je to GUI library, tedy toolkit.
Jak to souvisí s tím, že máš v systému další samostatný textový editor a pár věcí okolo na další programovací jazyk?V systému máš to, co si tam nainstaluješ. Někomu stačí nano, někdo si nainstaluje Lazarus a pak nepotřebuje Emacs, Sublimetext nebo Eclipse.
Tak pokud jim Eclipse připadá super, tak proč ne. Pokud jim připadá lepší mít vlastní, pak zase nevidím důvod se za každou cenu omezovat na FreePascal. Ale třeba je někde na webu dobré zdůvodnění, proč je můj dojem špatný.Evidentně jim Eclipse tak super nepřipadá, když pracují na vlastním IDE/RAD a vydali novou verzi.
Lazarus je jednak widget toolkit (analogie s wxWidgets) a taky IDE predevsim s vlastnim GUI designerem. Ano, mohl bys to prebouchat jako pluginy do Eclipse nebo Netbeans, ale bylo by to prilis mnoho prace a narazel bys na ruzne omezeni pluginove architektury zminenych IDE, abys dosahl funkcionality alespon blizici se Lazarusu nebo Delphi.
To mají všechno zahodit a udělat jen nějakej blbej plugin do Eclipse?
Když už, tak spíš do Netbeans 
Ale chápu, že vlastní IDE už dlouho, že se jim ho nechce zahazovat.
stači otevřit obyčejný Evaluate/Modify dialog a rovnou psát: TBytesStream.Create(bytes).savetofile..... a ono se to vykoná v kontextu právě aktuálního stavu programu...
V Netbeans tohle máš, včetně napovídání. Eclipse to tuším umí taky.
lea rax,[rbp+0x20] mov rbx, rax ; pracuj s rbx a už nešahej na raxVygeneruje vám zbytečnou mov instrukci, přestože s hodnou v rax už vůbec nepracuje. Taky má pomalé výjimky, používá k tomu setjmp() a longjmp(). V changelogu 3.0 se sice píše, že už používá "nativní výjimky", ale to asi pouze v případě windows, v linuxu tam pořád generuje setjmp().
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
20.2.2016 16:36
20.2.2016 16:49
21.2.2016 21:47
20.2.2016 17:17
21.2.2016 11:32
:-/
GUI toolkit, který není jen nějaký wrapper
Proč proboha zavádět další? Aby mohla každá aplikace vypadat jinak? (od toho jsou přece styly/témata/look-and-feel…)
new(std::nothrow)). Je-li napsán v C, očekávám, že kontroluje návratové hodnoty z malloc() a když selže, tak mi probublá třeba ENOMEM chybu až k místu volání, s tím, že já se pak můžu zařídit podle aplikace (záchrana dat, či abort, pokud záchrana není pro danou aplikaci třeba, ale hlavně, nechat to na mně a né samovolně volat abort()).
22.2.2016 00:41
xkucf03 | skóre: 49
| blog: xkucf03
A co rozdělit aplikaci na dvě části (procesy)? A když dojde k sestřelení GUI, to důležité zůstane běžet na pozadí a můžeš se k tomu připojit z jiného UI nebo to v klidu samo doběhne, uloží soubory, uvolní zdroje…
Na abort() je špatně hodně věcí.Třeba?
Pokud vám jde alespoň trochu o data, tak si nemůžete dovolit použít jazyk, či knihovnu, kde je nenastavitelně volán abort(), když selže alokace.To už jsi psal. Chápu, že v některých případech může mít smysl selhávající alokaci ošetřit, ale příklad s náhlým překotným ukládáním dat mě tak úplně nepřesvědčil.
Přitom vzpamatovat se z takové věci nemusí být nemožné, třeba zavřu všechny soubory, co se nezměnily a tím dostanu třeba haldy paměti, která mi bude stačit na záložní uložení neuložených dat, a nebo můžu fungovat dát s méně soubory.Podle mě je hlavní problém mít vůbec neuložená data, bez kterých se neumím obejít. Volání
abort() tak jenom ukáže už existující problém.
A srovnávat to s pojistkami je mimo, tam je zase řešení jiné (záložní zdroj třeba).Není to mimo. A nesrovnával jsem to pouze s pojistkami. Je jedno, jestli je to baterka v laptopu, pojistky, vykopnutý kabel z UPS nebo pád systému. Software, který udržuje důležitá data a nestará se o jejich konzistenci a včasné uložení, není dobrý software. Očekával jsem proti
abort() trochu silnější argumenty.
Ale proč abort()? Třeba otevírám nový, velký, soubor a prostě nemám dostatek paměti. Proč by mi měl program kvůli takový věci spadnout, když prostě můžu soubor neotevřít? Nebo proč by mi měl spadnout 10 sekund na to, protože už nebudu mít paměť na zobrazení tlačítka? Můžu nepotřebné soubory zavřít, čímž dostanu více paměti, a inforomovat uživatele, co se stalo. A když se nepodaří ani to, prostě urobím zálohy a končím.Proč ne, to je validní use case. Ale zase na druhou stranu na Linuxu nejčastěji dopadneš tak, že všechny alokace projdou, ale systém v jednu chvíli tvoji appku nemilosrdně sestřelí.
O uložení se třeba podle typu stará uživatel aplikace (příklad editor obrázků), ale proč bych mu neudělal zálohu, když je to v mé moci, a místo toho bych ho měl připravit i třeba o půl minuty práce a musím spadnout?A proč mu neděláš zálohu průběžně, nejlépe ve formě nějakého logu jako to dělá vim, abys ho ochránil i proti mnohem častějším problémům?
22.2.2016 11:03
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Přitom vzpamatovat se z takové věci nemusí být nemožné, třeba zavřu všechny soubory, co se nezměnily a tím dostanu třeba haldy paměti, která mi bude stačit na záložní uložení neuložených dat, a nebo můžu fungovat dát s méně soubory.Na Linuxu velmi nepravdepodobne.
Na Linuxu velmi nepravdepodobne.Pokud jde o overcommit, tak ten jde vypnout.
Jestli to ale neprovede stack unwind a nespustí destruktory (nebo jak tomu říkaj, ten Drop trait?), tak to může být stále problém, že nebude dost paměti na záchranu dat. Ale určitě lepší než přímý abort().Pochybuju, že to dělá stack unwind, popravdě, ono člověku v tom handleru stejně moc nezbude nic jinýho než abortnout. Jenže ono je to celkově problematické, jsou vůbec programy, které se v OOM situaci chovají korektně? Pokud člověk OOM očekává - např. alokuje místo pro nějaká potenciálně obrovská data (rastrová grafika,...) - může v Rustu použít
std::heap::allocate, zkontrolovat, jestli alokace proběhla, a pokud ano, udělat z toho bežnej boxovanej pointer nebo něco takového.
Z tvého komentáře soudím, že se o rust zajímáš, není nějaký použitelný GUI toolkit, který není jen nějaký wrapper na gtk/qt?Slyšel jsem o Conrodu, ale zkušenost s tím nemám. Příležitostně přispívám do Gtk-rs, čili binding pro GTK, IMHO to je dobrá cesta.
Pokud člověk OOM očekává - např. alokuje místo pro nějaká potenciálně obrovská data (rastrová grafika,...) - může v Rustu použít std::heap::allocate, zkontrolovat, jestli alokace proběhla, a pokud ano, udělat z toho bežnej boxovanej pointer nebo něco takového.Problém ale je, že se taková alokace může podařit jen-tak-tak a pak selže jiná alokace někde jinde a dostanu abort(). Z toho důvodu použití alokátoru není záchrana před pádem.
Příležitostně přispívám do Gtk-rs, čili binding pro GTK, IMHO to je dobrá cesta.Třeba teď jsem koukal na ten Gtk-rs a vidím v příkladu
let window = gtk::Window::new(gtk::WindowType::Toplevel).unwrap();Proč to vůbec takto dělat, aby to vracelo Option<> nebo Result<>, když samotné gtk_window_new "nemůže" selhat. Tím "nemůže" myslím právě to, že se vytváří GObject a to "nemůže" selhat. A to proto, že pokud k selhání dojde, je to ze strany glib automatický abort(). Tudíž takový wrapper přidává programátorovi naprosto zbytečnou práci (unwrap()), a falešný pocit, že může ošetřit selhání.
Problém ale je, že se taková alokace může podařit jen-tak-tak a pak selže jiná alokace někde jinde a dostanu abort(). Z toho důvodu použití alokátoru není záchrana před pádem.No, anebo neselže nic, ale v nějaký chvíli ti proces zabije OOM killer a stejně s tím nic neuděláš. Stejně mi ale není jasný, jak bys to chtěl zpracovávat, i kdybys mohl. Třeba dejme tomu, že ti aplikace v C++ odchytí
bad_alloc. Co s tím budeš dělat? Nejspíš na to budeš mít handler někde dost vysoko (tzn. dost blízko main()) a tam ti stejně celkem nezbude nic jinýho, než aplikaci ukončit, protože kontext, ve kterém chyba nastala, je stejně už dávno ztracen. A data bys mohl zachránit jedině tak, že by se zapisovaly v destruktorech, ale to mi přijde jako dost prasárna - destruktor by neměl provádět I/O operace.
Jedině, že bys měl ošetření bad_alloc na každým kroku, což by asi tak zdesetinásobilo velikost kódu, to mi nepřijde prakticky reálně možné.
Navíc ve chvíli, kdy systému dojde pamět, tak je systém stejně celkově naprosto nepoužitelný, protože prakticky všechno stojí zablokováno na I/O swapu a všechno je šíleně pomalý a uživatel ti stejně nejspíš mašinu vyresetuje než stihneš něco smysluplného udělat. Snažit se v té chvíli o nějaké I/O na záchranu dat je IMHO naprosto marné.
Takže klidně používej Gtk nebo Qt a OOM neřeš, nemá to cenu Důležitý data si vyzálohuj dopředu, jak píše pavlix...
Proč to vůbec takto dělat, aby to vracelo Option<> nebo Result<>, když samotné gtk_window_new "nemůže" selhat.Snažil jsem se to najít ve zdrojácích, ale tam už to není. Zřejmě v nové verzi ten Option/Result odstranili. Příklady používají stabilní verzi z crates.io, takže tam to asi ještě neprobublalo...
22.2.2016 16:31
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Třeba dejme tomu, že ti aplikace v C++ odchytí bad_alloc. Co s tím budeš dělat?
Preto sa občas alokuje časť pamäte (od pár kB po pár MB), ktorá sa pri výskyte chyby pri alokácii uvoľní aby sa program mohol bezpečne ukončiť s uložením dát, alebo aby mohol niečo zatvoriť a podobne.
Preto sa občas alokuje časť pamäte (od pár kB po pár MB), ktorá sa pri výskyte chyby pri alokácii uvoľníSpíš použije na bezpečné ukončení, ne? Jinak jsem dost skeptický k tomu, že by to v praxi skutečně fungovalo, zejména na běžným desktopu - asi by musel být jednak vypnut overcommit a taky by ten program musel ukládat na jiný device než ten se swapem, protože ten bude IMHO beznadějně vytížen... Musel by tak mít stěští a být včas naschedulován... Prostě, to celkově moc nevidim. Vy jste to někdo testoval?
22.2.2016 17:34
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Ja osobne som to nikdy nerobil, ani neviem ako vyradiť z činnosti OOM, ktorý by to zabil tak či tak. Táto technika o ktorej píšem sa používala na systémoch s primitívnymi OS, v súčasnosti si to možno viem predstaviť niekde na embedded, kde to má človek celé pod palcom.
22.2.2016 20:32
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
v súčasnosti si to možno viem predstaviť niekde na embedded, kde to má človek celé pod palcom.Tam nepouzijete dynamickou alokaci, jinak to nemate az tak 'pod palcom'.
Pochybuju, že to dělá stack unwind, popravdě, ono člověku v tom handleru stejně moc nezbude nic jinýho než abortnout. Jenže ono je to celkově problematické, jsou vůbec programy, které se v OOM situaci chovají korektně?Neznám a u běžných aplikací ani nevěřím. Nemá smysl se patlat s kódem pro OOM, který nikdy nikdo nebude pořádně testovat. Myslím, že je v aplikacích už dost problémů například s ošetřením signálů, na které by se dalo zaměřit. Failující malloc na Linuxu, který při OOM střílí procesy jak na běžícím páse a přednostně střílí ty, které potřebuješ, bych už vůbec neřešil. Podle mě by mělo maximálně smysl mít nějaký oom nebo dokonce pre-oom handler, který by pracoval nezávisle na kódu, který se snaží alokovat. Jeslti glibc nic takového nemá, dalo by se to tam jednoduše dohackovat.
22.2.2016 11:06
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Protože já nejsem schopný nic naprogramovat, když to nemůžu naprogramovat tak, aby se mi to zdálo dokonalé.Pokud jde pouze o programy, možná by stálo za to vyzkoušet vývoj formálně verifikovaného SW v nějakém tradičním jazyce jako je například Coq nebo Isabelle (novější jazyky jako Idris mají stále mnoho bugů).
Tak se nech zaměstnat někde, kde budeš testovat nebo dělat revize kódu – budou ti za to ještě platit (ne jako v diskusích)
23.2.2016 07:14
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
23.2.2016 08:18
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
.