Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 161 (pdf).
Po delší době vývoje vyšla nativní linuxová verze virtuálního bubeníka MT-PowerDrumKit 2 ve formátu VST3. Mezi testovanými hosty jsou Reaper, Ardour, Bitwig a Carla.
Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Společnost Kagi stojící za stejnojmenným placeným vyhledávačem vydala (𝕏) alfa verzi linuxové verze (flatpak) svého proprietárního webového prohlížeče Orion.
Firma Bose se po tlaku uživatelů rozhodla, že otevře API svých chytrých reproduktorů SoundTouch, což umožní pokračovat v jejich používání i po plánovaném ukončení podpory v letošním roce. Pro ovládání také bude stále možné využívat oficiální aplikaci, ale už pouze lokálně bez cloudových služeb. Dokumentace API dostupná zde (soubor PDF).
Jiří Eischmann se v příspěvku na svém blogu rozepsal o open source AdGuard Home jako domácí ochraně nejen před reklamou. Adguard Home není plnohodnotným DNS resolverem, funguje jako DNS forwarder s možností filtrování. To znamená, že když přijme DNS dotaz, sám na něj neodpoví, ale přepošle ho na vybraný DNS server a odpovědi zpracovává a filtruje dle nastavených pravidel a následně posílá zpět klientům. Dá se tedy používat k blokování reklamy a škodlivých stránek a k rodičovské kontrole na úrovni DNS.
AI Claude Code od Anthropicu lépe rozumí frameworku Nette, tj. open source frameworku pro tvorbu webových aplikací v PHP. David Grudl napsal plugin Nette pro Claude Code.
proč ne c na lowlevel?? :O :O
Takže jakmile kupa namatlaných skriptíků přeroste v projekt, je to děs ladit a udržovat.
+1, taky si myslím. Ale setkal jsem se i s lidmi, kteří v Perlu píší větší věci a libují si v tom. Osobně to moc nechápu, přijde mi to hodně neefektivní.
Na druhou stranu, na ty krátké skripty nebo dokonce „one-linery“ je ten Perl skvělý. Je to podobné jako třeba Bash – je to sice prasárna, ale pokud je ten program/skript dostatečně krátký na to, abys ho udržel celý v hlavě, tak to nevadí a ta „prasáckost“ ti naopak pomáhá.
Pokud chceš napsat nějakou věc, která vezme data z ERP, napočítá nějaké struktury a uloží to do redisu, tak je perl jasná volba. Pokud máš půl hodiny na to vymyslet nějaký cgi skript, který vezme nějaká data odněkud a vysype z toho nějaké XML nebo json, tak zase perl. Pokud chceš vzít excelový soubor (fuj) a dostat obsah buňky A12 jako text na výstup, vezmeš perl, ale výsledek nebude moc portabilní, protože bude používat nějaký modul. Pokud chceš napsat gui aplikaci, která bude fungovat na androidu, ios, linuxu a ve Windows, která se ovládá přes dotykový display a komunikuje s http serverem, tak si na to perl samozřejmě nevezmeš a uděláš to v pythonu / kivy nebo něčem jiném.
Ta anketa by měla být nějak 2D - napřed zjistit "co děláš" a pak "co na to máš oblíbené". Pak bychom nepřekvapivě došli k závěru, že golfová hůl č. 5 je výborná na třetí jamku na Slapech, ale na squash nebo plavání není úplně populární.
), ale pak už mě napadá fakt jenom bash nebo php a to bych fakt nevěděl, co vzít raději.
Nebo C#?
metoda(objekt) misto objekt.metoda(). Tohle je nejprimitivnejsi priklad kde je rozdil v citelnosti maly, horsi to je, kdyz to je nekolik zretezenych volani a kdyz ty funkce maji nekolik parametru.
Slysel jsem ze ma podstatne pomalejsi kompilaci - to se jako fakt kompiluje jeste pomaleji nez C++?Obvykle ano, což neznamená, že se nedají C++ zdrojáky zprasit tak, aby se kompilovaly pomaleji.
/target/ folderu? Protože build artefakty dovedou být velké, ale třeba můj už docela rozsáhlý data storage server v Rustu má jako binárka momentálně 291M (Debug build) / 35M (Release)
Je to sice Axum web framework, ale ten rozdíl od Actixu nebude velký.
To záleží co píšeš,To jistě.
99% věcí, co píšu já, běží v Pythonu tak rychle, že bych v C nezískal nic, prostě bych to jako uživatel programu nepoznal.Ano, ovšem dost možná při tom voláš netriviální množství nativních modulů psaných v C/C++, cythonu nebo nedejbože ve fortranu a máš to štěstí, že pro tvoje účely už je někdo napsal před tebou (a teď nemám na mysli to, že samotný CPython je psaný v C).
Boomeři se bojí, čirá hrůza svírá jejich srdce ledovými prsty. Boomeři mají přesilu tři ku jedné, dobrý poměr pro každého JavaScripťáka! Dnes milí zoomeři zachráníme svět před starými temnými a hloupými způsoby a ohlásíme budoucnost, která bude světlejší než si umíme představit. Poděkujte geekové, Javascriptu a Pythonu k jejich statečným procentům. K vítězství!
Python pouzivaj boomeri, je to zaostaly jazyk, ktery nepatri do 21. stoleti.Zaostalý? Už jsem slyšel python nazývat vším možným, ale zaostalým teda fakt poprvé.
Jeste by mohli pridat garbage collector, zrychlit, zlepsit REPL, zlepsit podporu modulu (kdyz importuju modul, tak mam dostupny vzechny symboly z nej bez nejakyho prefixu) a vic to odseparovat od Apple ekosystemu.:D Já nějak nedokážu poznat, jestli je tohle trolling, ale jestli jo, tak bravo.
Prostě cvičená opice, nic víc není a v životě nejspíš nebude.
Jako sorry, ale lidi typicky mají nějaké důvody, proč používají python, a swift se s těmi důvody nepřekrývá prakticky vůbec.
To jsou takové ty věčné spory mezi programátory… Asi nejrozumnější vysvětlení tohoto rozporu, co jsem slyšel, spočívalo v tom, že se liší podstata práce a cíle těch lidí. Cílem jedněch je vytvořit software. A cílem jiných je zpracovat nějaká data nebo obecně vyřešit nějaký konkrétní jednorázový úkol. A přestože v obou případech to navenek vypadá, že ti lidé píší kód, jsou programátoři a dělají to samé, ve skutečnosti se jejich práce podstatně liší a z toho pramení i odlišné preference co se týče jazyka.
GIL uz je temer minulosti - uzpusobene jsou uz ruzna vnitrni a externi API a zbyvaji pouze velke knihovny jako numpy apod. Sleduji jiz nekolik let progress a fakt uz je vetsina praci hotovych. https://github.com/ericsnowcurrently/multi-core-python Smutne je, ze na tom dela jenom par malo lidi a to jen par hodin mesicne - ta nejbolavejsi vetsina prace uz je snad 4 roky stara a od te doby se to tahne po promilich nez procentech k finalu.Tak ono hlavně historicky tu byl jython, ironpython a pypy s stm a nikdy se to moc neujalo, imho protože většina lidí prostě použije multiprocessing a má pokoj.
GIL a absence použitelného parallelismu na úrovni jazyka.Co je pro tebe použitelný paralelismus na úrovni jazyka?
A pochybuji že by se cokoliv novějšího byť jen vzdáleně přiblížilo genialitě příkazu PAR v Algolu 68
NumPy mi prijde jako takovy divny jazyk v jazyce...Pokud za jazyk v jazyce považuješ zrovna numpy, co pak je skoro každá knihovna v C++ s šablonami a přetíženými operátory? Já naopak považuji za ohromnou přednost numpy (oproti třeba matlabu, jejž někteří z pro mne nepochopitelných důvodů stále používají), že je to pořád python se vším všudy, co ten jazyk nabízí, a pracuje se s tím ve srovnání s jinými věcmi fakt snadno.
Je hrozne pomaly. Vim ze existuje PyPy nebo Cython, ale pocita se default.No jo, ono je totiž hrozná práce napsat
pypy script.py místo python3 script.py. Jinak default počítáš i u javascriptu, a u C počítáš defaultní implementaci, nebo tam ti to problémy nedělá?
Podpora OOP je takova zvlastni, treba ze to jaky ma trida parametry se definuje uvnitr konstruktoru.Aha. Takže kdyby se to definovalo někde jinde, tak je to jako lepší jo? Já jsem třeba tenhle dojem nikdy neměl. Ale oproti třeba selfu je tohle pořád dost v pohodě.
NumPy mi prijde jako takovy divny jazyk v jazyce...S tím souhlasím.
Jak uz bylo napsano, podpora paralelismu. Je proste videt, ze ten jazyk byl navrhnut pred 30 lety.To jsou bizarně nepravdivé blbosti, které tu vidím opakované už po několikáté. Jazyk má podporu paralelismu úplně normální. Threading, procesy, korutiny. Referenční implementace jazyka momentálně používá GIL, což mimo jiné znamená, že paralelismus s použitím threadů prakticky nevyužívá vícero jader. Což může a nemusí být vada, on ten GIL má taky pár výhod, které jsem například ocenil až nedávno (například všechny standardní datové struktury mají atomické změny a jsou thread safe by default). Paralelismus ale pořád funguje, ve smyslu že pro tvůj kód to vypadá, jako že vícero věcí běží zároveň, jen z toho nevyždímeš CPU výkon, ale třeba pro net/disk bound operace to funguje. Pokud ho potřebuješ (což já v práci občas jo), tak proste místo threadingu použiješ multiprocessing. Ano, bude to mít větší memory footprint, ale v typických use cases jsou to desítky megabajtů navíc (tuším něco jako 30MB?), což je nepodstatné.
No jo, ono je totiž hrozná práce napsat pypy script.py místo python3 script.py.Před pár lety jsem s tím měl nějaký problémy, nevím jestli se situace změnila.
Jinak default počítáš i u javascriptuAno, tam jako default beru V8.
Aha. Takže kdyby se to definovalo někde jinde, tak je to jako lepší jo? Já jsem třeba tenhle dojem nikdy neměl. Ale oproti třeba selfu je tohle pořád dost v pohodě.Ano, přirozený mi přijde dát to nahoru do té třídy, stejně jako v jiných jazycích.
Ano, přirozený mi přijde dát to nahoru do té třídy, stejně jako v jiných jazycích.To hrozně záleží na tom s čím jsi dělal. Jsou jazyky kde to tak je a jazyky kde to tak není a celý pocit přirozenosti máš jen protože jsi si na něco zvykl.
Paralelismus ale pořád funguje, ve smyslu že pro tvůj kód to vypadá, jako že vícero věcí běží zároveň, jen z toho nevyždímeš CPU výkon
Takže asi jako takový secí stroj, který neseje :-)
Takže asi jako takový secí stroj, který nesejeTo není tak úplně pravda. Chápu proč můžeš mít ten pocit, ale reálně používám threading v py docela často a mám z toho ten benefit, akorát prostě ne na CPU bound úlohy. Ale třeba na psaní nějaký workerů co paralelně dělají se sítí / aws / whatever je to použitelné velmi dobře.
go func()) a synchronizace pomocí channels mi taky dost vyhovuje.
Takže to, co jsem před tím měl v pythonu bůh ví jak řešení (většinou přes multiprocessing.pool.map), tak teď si naspawnuju tolik procesů, kolik přirozeně z hlediska návrhu programů plyne (klidně tisíce) a potom si posílají zprávy přes chan. Nějak je mi to velmi přirozené, myslím message passing různých nezávislých procesů.
Něco jsem o motivaci k přechodu na golang v létě napsal.
deno compile main.ts
Jako my trolove jsme porad stejni jen JS uz nikoho netriggeruje tak jsme ho vymenili za Rust. Ale i Perl vypada nadejne, krasny priklad love/hate materialu, to si jeste vychutname
Tiskni
Sdílej: