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.
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).
Na konferenci HotOS XVII (17th Workshop on Hot Topics in Operating Systems) konanou 12. až 15. května v Itálii byl přijat také vědecký článek s názvem A fork() in the road. Jedním z autorů je Andrew Baumann z Microsoftu a Microsoft daný článek již zveřejnil na svých stránkách (pdf). Dle autorů článku systémové volání fork() do moderních operačních systémů již nepatří a na školách by se o něm mělo mluvit pouze jako o historickém artefaktu.
Tiskni
Sdílej:
Thanks to the success of Unix, future systems will be stuck supporting fork for a long time; nevertheless, an implementation hack of 50 years ago should not be permitted to dictate the design of future OSes.Zajímavé, že tohle říká zrovna Microsoft.
Z Microsoftu je jen jeden ze čtyř autorů článku, ale i tak (a s ohledem na publikování přes Microsoft) se automaticky nabízí interpretace "nedokázali jsme to pořádně implementovat, tak to musí být k ničemu".
Článek samotný má hlavu a patu a stojí za přečtení (čímž netvrdím, že se vším souhlasím). Výjimkou je právě ten nechutně bulvární úvod, který sice perfektně plní úlohu přilákat pozornost (i médií), ale autoři se pak nemohou divit, že málokdo bude brát zbytek vážně.
posix_spawn()
Nemám na to úplně jasný názor, ale našel jsem tohle, což mi přijde celkem rozumné: posix_spawn is stupid as a system call
Exactly. The number of useful and important things you can, want, and need to do between a fork and an exec is far too great to make it one call, in all but the simplest cases. I had this exact argument with a Windows API proponent who felt that fork+exec was crazy (not related to OOM issues, just having more than one call). But the number of flags and arguments you'd need to replicate that behavior is insane and you'd STILL run into situations where you can't do what you want.
Fork+exec definitely has its downsides in some of the technical implementation requirements, but from a higher level language perspective it's brilliant.
A nestačí mít nějaký rodičovský proces, který toho obsahuje minimum, má otevřené jen nezbytně nutné zdroje… a jen spouští podprocesy (které už s těmi různými zdroji pracují)? Ono asi dělat fork() „z prostředka“ běhu větší aplikace není úplně šťastný nápad (tam by asi zase bylo lepší použít vlákna).
Komplikované… zrovna v tomhle případě mi přijde lepší zavolat nějakou službu desktopového prostředí (třeba přes ten D-Bus). Pak to máš i jednotné a dokumenty se ti otvírají v aplikacích, které sis nastavil, ale ne že si to bude řešit každý po svém a jeden typ souboru se ti bude otvírat pokaždé v jiné aplikaci podle toho, jestli jsi na něj klikl ve Firefoxu, Dolphinu nebo Chromiu atd.
Případně by to šlo řešit tak, že by ta složitější aplikace měla jeden rodičovský proces a pak potomky, ve kterých by běželo GUI a všechno ostatní… a kdyby některý z těchto potomků chtěl spustit externí program, tak by o to požádal svůj rodičovský proces a nedělal by fork() sám.
Jinak nemám nic proti tomu, aby existovalo nějaké jednoduché standardní API pro spuštění nezávislého procesu. Ale nemyslím si, že by to měla být jediná cesta pro spouštění procesů.
11.4.2019 16:17
Gilhad | skóre: 20
| blog: gilhadoviny
Jak řešíš případy, kdy název souboru obsahuje mezery?
11.4.2019 16:03
Gilhad | skóre: 20
| blog: gilhadoviny
Pokud moc neprogramuješ a stačí ti volaní system(), tak na jeho použití není zlého nic. Jen jsou tu dva zádrhele: A) System() používá fork(), B) někteří programují víc a potřebují dělat i složitější věci, na které samotný system() nestačí a ti fork() potřebují.
Se system() bude problém i u celkem základních úloh. Příkaz se předává včetně svých parametrů jako jeden textový řetězec, takže se tam ztrácejí hranice mezi jednotlivými parametry – nemůžeš jen tak poslepovat řetězec ze vstupů, které si odněkud získal, protože v těch vstupech můžou být třeba mezery (např. v názvu souboru) a musíš to správně escapovat. Předávat si zde strukturovaná data ve formě textu je zlo – jednak je to nesmyslné, protože ty ten řetězec musíš poskládat a vzápětí ho Bash parsuje, a jednak je to náchylné k chybám (viz třeba nedávná chyba dirty sock ve snapd, kde si taky předávali strukturovaná data ve formě textu a samozřejmě se jim to rozsypalo – až tak moc, že z toho byla lokální eskalace práv…). O otravné práci navíc ani nemluvě.
Zajímavé by mi přišlo, mít nějakou možnost asynchronního spouštění procesů. Měl bys frontu (buď pro uživatele, relaci nebo aplikaci) a ta by měla nastavený nějaký maximální počet procesů. A do té fronty bys pak mohl sypat1 požadavky2 na spuštění procesu. Nějaký démon by tyhle procesy postupně spouštěl (pokud by pro ně byly volné procesy, jinak by čekaly ve frontě, než na ně přijde řada). Volitelně by ses mohl dotazovat na výsledek (stavový kód, dobu běhu atd.) nebo se přihlásit k asynchronnímu odběru událostí – dostal bys informaci, že proces skončil nebo že třeba něco vypsal na standardní výstup.
[1] ať už přes D-Bus nebo nějakou C funkci
[2] strukturovaně – tzn. ne jen jeden textový řetězec, ale hezky název programu, jednotlivé parametry, proměnné prostředí atd.
11.4.2019 18:38
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Zajímavé by mi přišlo, mít nějakou možnost asynchronního spouštění procesů.Něco takového jsem si před časem ubastlil. Potřeboval jsem spouštět úlohy (řádově desetisíce relativně malých úloh) na různých strojích na síti, vkládat (atomicky, asynchronně) úlohy do fronty, případně je mazat apod. Výsledek (stdout, stderr, exitcode) se uloží k hotové úloze (ne že bych to někdy skutečně použil, stačí, když to v pořádku doběhne). Na jednotlivých strojích si pustím tolik workerů, kolik chci (ručně, šla by udělat i systemd unita). Vím, že existuje hromada složitých programů pro clustery a pro gridy, ale já fakt hledal "něco jako"
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
11.4.2019 01:53
11.4.2019 09:34
| parallel, ale s možností ty úlohy vkládat postupně a ze sítě. Využil jsem vlastnosti SKIP LOCKED v PG, čímž je fronta rovnou i atomická a současně je to síťové bez práce. V ideálním případě by to mohlo být i distrubuované, aby tam nebyla ta centrální db, ale to už by se zase blížilo těm hotovým grid bazmekům.
Multithredové programování má spoustu velice užitečných použití, a to, že ty osobně jsi ho zatím třeba nepotřeboval na tom nic nemění.Ja se treba cim dal tim vic priklanim k myslence, ze vicevlaknovy beh aplikaci je pouze uspesny omyl, ktereho se budeme jeste dlouho zbavovat. Z meho pohledu je to velmi spatna abstrakce, ktera prinasi vic problemu nez resi. Jsou lidi, kteri zastavaji nazor, ze vlakna v Unixech nemaji co delat (uz jenom kvuli problemum s fork()) a myslim, ze by se dalo bez vlaken velice pekne obejit, ... kdyby v Unixu bylo rozumne IPC.
Můžeš uvést nějaký příklad „rozumného“ IPC?
A musíš to mít nutně v UNIXu/POSIXu? Vždyť tohle se dá řešit právě těmi knihovnami a frameworky. OS je většinou o úroveň níž, řeší sdílenou paměť, procesy, MQ atd. – a nad tím už si postavíš API jaké potřebuješ. A co jsem četl, tak:
Goroutines are multiplexed onto multiple OS threads
tzn. je to akorát abstrakce nad vlákny a takové knihovny existují ve všech možných jazycích.
A musíš to mít nutně v UNIXu/POSIXu?Nemusim. Podstata meho sdeleni byla v tom, ze kdyby to tam bylo, rada veci by se dala delat jinak a lip.
Ale to reagujes uplne na neco, o cem nemluvim a co ani neni dulezite. Ja se tu bavim o podpore IPC na strane jazyka. Pokusim se to rozebrat trosku obsirneji. Vlakna jsou prilis lakavy koncept na to, nezaclenit ho do OS. Na urovni jadra jejich podpora neni slozita, podpurneho kodu v uzivatelskem prostoru taky neni moc potreba. Pridani vlaken do vyssich programovacich jazyku je trivialni. Neni potreba nijak upravovat jazyk. Programator muze sdilet data mezi vlakny, nemusi nic resit. Muze programovat tak, jak programoval vzdy, jen se tu a tam prida nejaky ten zamek nebo semafor. IMHO toto zdanlive pohodli stoji za uspechem a celkovou mizerii prace s vlakny. Pokud mas jednovlaknovy program, da se nad kodem rozumne uvazovat stylem if-neco-tak-neco. V pripade vicevlaknovych aplikaci toto absolutne pada, ztracis garance temer vseho. Sdilena data v rezimu pro zapis jsou na uchopeni jeste horsi nez pouzivani globalnich promennych a goto dohromady. Pristup k datum muzes zamykat, ale kolik lidi dokaze napsat kod, ktery nebude obsahovat nejaky skryty race-condition nebo deadlock? A kdyz jsem tak chytrej, co ma byt teda alternativou? Jako mnohem cistejsi mi prijde vytvorit samostatne (oddelene) procesy, ktere mezi sebou komunikuji zasilanim zprav. Takto nejenom, ze neztratis ruzne garance jako v pripade vicevlaknovych aplikaci, ale stale muzes nad kodem uvazovat stylem if-neco-tak-neco. Odpadne ti velke mnozstvi starosti, ktere plynou z toho, ze jedno vlakno muze zapsat/cist cokoliv, co patri tomu druhemu. Dalsi bonus, ktery tim ziskas, je modularita. Tim, ze jednotlive procesy mezi sebou komunikuji zasilanim zprav, ziskas jednoznacne definovane a testovatelne rozhrani mezi jednotlivymi castmi kodu! (cf. chuchvalec vlaken sdilejici, co zrovna potrebuji). Ze to jde a dava smysl, ukazuje treba architektura Chromu. Proc se tento pristup nepouziva vic, je podle me tim, ze celkove aparat, ktery poskytuji soucasne IPC+programovaci jazyky neni, pro programatora tak komfortni jako vlakna. Kdyby se to zjednodusilo na uroven treba Erlangu nebo kanalu v Go, asi by potom sahlo vic programatoru. A kdyz se to zjednodusi jeste vic, tak to budou lidi pouzivat aniz by tusili, ze vlastne nejake IPC pouzivaji, viz roury mezi programy. A tim se dostavam zpatky k uzitecnosti fork().Goroutines are multiplexed onto multiple OS threadstzn. je to akorát abstrakce nad vlákny a takové knihovny existují ve všech možných jazycích.
Proc se tento pristup nepouziva vic, je podle me tim, ze celkove aparat, ktery poskytuji soucasne IPC+programovaci jazyky neni, pro programatora tak komfortni jako vlakna.
Spíš výkon a paměťová náročnost. Jak jste správně podotkl, napsat pořádně složitější multithreadovou aplikaci je těžké. Kdyby to nemělo své výhody, proč by si s tím vývojáři dávali tu práci?
Spíš výkon a paměťová náročnost.Nejsem si jisty, do jake miry je toto jeste skutecny problem. Obzvlast ve svete, kde rada vyvojaru si mysli, ze vzit vykreslovaci jadro z prohlizece se vsim vsudy k tomu dva runtimy pro javascript, ktere si mezi sebou vykladaji pomoci HTTP a udelat z toho desktopovou aplikaci, je dobry napad. Ale dost sarkasmu. Rezie, kterou zasilani zprav, muze byt v nekterych situacich problem. I kdyz si myslim, ze toto je misto, kde bychom si dnes snad mohli dovolit polozit trochu vykonu na oltar bezpecneho programovani.
Jak jste správně podotkl, napsat pořádně složitější multithreadovou aplikaci je těžké.Je to tezke, ale kdyz to clovek udela blbe, neni tam zadna prekazka nebo indikace, ktera by ho upozornila, ze to udelal blbe. Takze clovek snadno nebude dojmu, ze to zase tak tezke nebylo, i kdyz tam nechal treba potencialni problem. Na druhou stranu, pokud mas izolovane moduly, u kterych musis navrhnout dobre rozhrani pro vymenu dat, uz to boli (dobry navrh rozhrani vzdy boli) a prostredky, ktere prog. jazyky nabizi, to nedelaji vubec jednodussi.
Kdyby to nemělo své výhody, proč by si s tím vývojáři dávali tu práci?Ze setrvacnosti? Z falesneho pocitu, ze to prece neni tak slozite a ze to zvladnou?
Souhlasím, že pracovat s vlákny, řešit zámky a souběh je dost ošemetné a spousta programů tím trpí, je to častý zdroj chyb… Nicméně tohle srovnání mi nepřijde úplně fér:
Jako mnohem cistejsi mi prijde vytvorit samostatne (oddelene) procesy, ktere mezi sebou komunikuji zasilanim zprav. Takto nejenom, ze neztratis ruzne garance jako v pripade vicevlaknovych aplikaci, ale stale muzes nad kodem uvazovat stylem if-neco-tak-neco. Odpadne ti velke mnozstvi starosti, ktere plynou z toho, ze jedno vlakno muze zapsat/cist cokoliv, co patri tomu druhemu.
Protože sis to zjednodušil tím, že jsi úplně škrtl přístup ke společným datům a nahradil ho posíláním zpráv. Ovšem jak se to liší od vícevláknového programu, kde se akorát zdržíš sahání na jedna data z více vláken a místo toho si budeš posílat zprávy přes nějakou frontu?
Ono na úskalí vláken upozorňují i mnoho let staré knihy… a programátoři snad ve všech jazycích na tyhle problémy nějak reagují a vytvářejí různé knihovny a abstrakce, které tu paralelizaci řeší. Takže já se na to dívám spíš tak, že vlákna nejsou nějaké bytostné zlo, ale jen nízkoúrovňový koncept, se kterým běžný aplikační programátor normálně nepřijde přímo do styku. Existují různá pohodlnější a bezpečnější řešení pro Javu, C++ a další jazyky. Dokonce jsem nedávno koukal, že programátor ZeroMQ napsal obdobu gorutin/kanálů v céčku: libmill.
Je otázka, jestli je pro tohle nutné mít podporu přímo v syntaxi jazyka – mít k tomu ten syntaktický cukr. Možná naopak kvalitu a pružnost jazyka dokazuje lépe to, že tam takovou věc šlo dopsat jako knihovnu a postavit to nad stávající univerzální syntaxí (ať už to jsou funkce, šablony nebo třeba anotace). V té pružnosti budou možná nejdál jazyky jako Lisp nebo Haskell (tipuji, nemám s nimi moc zkušenost), ale jak je vidět, realizovat to jde i v celkem běžných jazycích jako je C++ nebo Java.
Nemusim. Podstata meho sdeleni byla v tom, ze kdyby to tam bylo, rada veci by se dala delat jinak a lip.
Asi by to posloužilo jako jednotný návrhový vzor, ze kterého by implementace v jednotlivých jazycích vyšly. Souhlasím, že nějaká standardizace resp. jednotný vzor by nebyly od věci. Přesto by ale asi možnost ručně pracovat s vlákny nezmizela – stejně jako asi nezmizí možnost ručně spravovat paměť.
Protože sis to zjednodušil tím, že jsi úplně škrtl přístup ke společným datům a nahradil ho posíláním zprávA to jde, zjednodusit si veci tak, aby se v tom clovek vyznal. Jinak data neni problem sdilet, pokud jsou nemenna nebo v rezimu CoW. Pokud potrebujes mit nejaky sdileny prostredek, da se odpovednost za nej jednomu procesu a ostatni to s nim vykomunikuji. Viz Rust.
Ovšem jak se to liší od vícevláknového programu, kde se akorát zdržíš sahání na jedna data z více vláken a místo toho si budeš posílat zprávy přes nějakou frontu?Mas tam ty garance, ze ti zadne vlakno OPRAVDU nehrabe, kam nema. Zmizne ti, cela kategorie problemu, kterymi by ses musel zabyvat.
Ono na úskalí vláken upozorňují i mnoho let staré knihy… a programátoři snad ve všech jazycích na tyhle problémy nějak reagují a vytvářejí různé knihovny a abstrakce, které tu paralelizaci řeší.A stale nic, co by slo rozumne pouzit. Treba v Jave jsou monitory, ale chybu udelas ani nemrknes, muj oblibeny vzor (i kdyz ve skutecnem kodu to byva jeste zasmodrchanejsi).
public class SharedData {
private List<Object> data = new ArrayList<>();
public synchronized void add(Object o) {
data.add(o);
}
public synchronized List<Object> getData() {
return data;
}
}
Vsimni si, ze jsem udelal obe metody synchronized, tak to musi byt v poradku!
Takže já se na to dívám spíš tak, že vlákna nejsou nějaké bytostné zlo, ale jen nízkoúrovňový koncept, se kterým běžný aplikační programátor normálně nepřijde přímo do stykuJa to vnimam spis jako spatne navrzeny (nedomysleny) koncept.
Existují různá pohodlnější a bezpečnější řešení pro Javu, C++ a další jazyky. Dokonce jsem nedávno koukal, že programátor ZeroMQ napsal obdobu gorutin/kanálů v céčku: libmill.Neznal, jsem diky za info.
Je otázka, jestli je pro tohle nutné mít podporu přímo v syntaxi jazyka – mít k tomu ten syntaktický cukr. Možná naopak kvalitu a pružnost jazyka dokazuje lépe to, že tam takovou věc šlo dopsat jako knihovnu a postavit to nad stávající univerzální syntaxí (ať už to jsou funkce, šablony nebo třeba anotace).Je opet spise podruzne, jestli to bude knihovna nebo soucast jazyka. Dulezite je, aby to bylo snadno pouzitelne s minimalnim usilim (viz erlang, go nebo roury). To je jeden z problemu, proc lidi dnes radeji sahnout po vlaknech a sdileni vseho, protoze je to pro ne pohodlnejsi.
Mas tam ty garance, ze ti zadne vlakno OPRAVDU nehrabe, kam nema. Zmizne ti, cela kategorie problemu, kterymi by ses musel zabyvat.
S tímhle se dá souhlasit, nicméně je to otázka přístupu – jestli nabídnout programátorovi jen omezené možnosti a nedovolit mu udělat chybu, nebo mu dát k dispozici víceméně všechno a jen ho varovat, že některé věci můžou být nebezpečné. Ono záleží dost na aplikaci/projektu – někde se hodí to omezené prostředí a někde naopak potřebuješ mít občas možnost dělat ty nízkoúrovňové a nebezpečné věci.
Vsimni si, ze jsem udelal obe metody synchronized, tak to musi byt v poradku!
Tohle je opravdu hodně učebnicový příklad chyby – v praxi to bývá pestřejší. Nicméně synchronized v Javě je hodně nízkoúrovňová věc, kterou využije spíš autor nějaké knihovny nebo frameworku než aplikační programátor, který se má soustředit na byznys logiku. Ten by měl používat nějaké vhodné knihovny a abstrakce, nějaké vyšší API a ne muset řešit tu synchronizaci takhle ručně.
Ja to vnimam spis jako spatne navrzeny (nedomysleny) koncept.
Což o to, operační systém by šel postavit i bez toho a mít jen oddělené procesy, které si mezi sebou posílají zprávy. Ale mělo by to asi dost negativní dopady na výkon. Ono i když nepoužíváš vlákna a máš jen procesy, tak si stejně mezi nimi někdy předáváš data pomocí sdílené paměti, protože prostě nechceš kopírovat velké bloky dat skrze nějakou rouru nebo zprávy. Tou zprávou si třeba jen předáš informaci, že ve sdílené paměti čekají nějaká data na zpracování. Takže vláken ses sice zbavil, ale ten obtížný úkol (přistupovat k jedněm datům z více procesů) tam máš stále.
A ty vyšší abstrakce bývají stejně postavené na nějakých zámcích, sdílené paměti, monitorech, vláknech… akorát od nich programátora odstíní, aby tyhle nízkoúrovňové mechanismy neviděl a nemohl v nich udělat chybu. Klidně můžeš mít API, které z pohledu programátora vypadá, že posílá zprávy, ale vnitřně bude ta data předávat přes sdílenou paměť, nebo můžeš mít jednoduché a bezpečné API pro paralelní zpracování, které ale uvnitř bude používat vlákna, akorát o tom programátor ani nebude vědět a nebude s těmi vlákny přímo pracovat – jen někam nasype úlohy a pak si jinde vyzvedne výsledky. A na tohle už existuje plno knihoven snad ve všech jazycích. Jak jsem psal – o úskalích vícevláknového přístupu se ví už dlouhé roky a řešení jsou.
To je jeden z problemu, proc lidi dnes radeji sahnout po vlaknech a sdileni vseho, protoze je to pro ne pohodlnejsi.
Nevím, nemám k tomu statistiku, nedokážu posoudit, kolik lidí to dělá. Na základě pozorování mi spíš přijde, že se dneska hodně lidí upíná k nějakým technologiím, o kterých si myslí, že je to stříbrná kulka, která za ně vyřeší všechny složité problémy a oni jsou v bezpečí… jenže ztrácí respekt a soudnost. Pak z toho vznikají takové chyby, jako že někdo sice používá Golang (to by přece mělo být bezpečné!), jenže v něm poslepuje textový řetězec z neošetřených vstupů a způsobí vážnou bezpečnostní chybu. Přitom byla patrně vadná už ta myšlenka předávat si strukturovaná data ve formě textového řetězce. Jenže když někomu nedocházejí takovéto základní věci, tak ho nezachrání ani „bezpečný“ jazyk.
S tímhle se dá souhlasit, nicméně je to otázka přístupu – jestli nabídnout programátorovi jen omezené možnosti a nedovolit mu udělat chybu, nebo mu dát k dispozici víceméně všechno a jen ho varovat, že některé věci můžou být nebezpečné. Ono záleží dost na aplikaci/projektu – někde se hodí to omezené prostředí a někde naopak potřebuješ mít občas možnost dělat ty nízkoúrovňové a nebezpečné věci.Tato argumentace me nechava ledove klidnym. Uz jsem ji zazil pred cca 20 lety, kdy se vedly vasnive diskuze, ze garbage collectory jsou spatne, protoze maji rezii a ze programator potrebuje mit moznost "prasit" s pameti, aby dosahl nejlepsiho mozneho vykonu. Spravny programator(tm) chyby nedela, protoze vzdy uvolni pamet, atd. atd.,
Což o to, operační systém by šel postavit i bez toho a mít jen oddělené procesy, které si mezi sebou posílají zprávy. Ale mělo by to asi dost negativní dopady na výkon.Docela oblibeny byl i argument, ze Java je zbytecne pomala, protoze pri kazdem pristoupu do pole testuje, jestli nahodou neprekrocils jeho mez, a ze spravny programator potrebuje pointerovou aritmetiku (a spravny programator(tm) si dokaze pristup za meze pole pohlidat sam).
Takže vláken ses sice zbavilMinimalne jeden obri problem odstranen.
Ono i když nepoužíváš vlákna a máš jen procesy, tak si stejně mezi nimi někdy předáváš data pomocí sdílené paměti, protože prostě nechceš kopírovat velké bloky dat skrze nějakou rouru nebo zprávy. Tou zprávou si třeba jen předáš informaci, že ve sdílené paměti čekají nějaká data na zpracování.Jednak tech mist, kde toto je realny problem bude IMHO docela malo. Intuitivne bych treba rekl, ze to bude i pripad renderovaci jadra prohlizece, ale prekvapive to zase takovy proble neni. Pokud potrebujes sdilet data jde to v rezimu pouze pro cteni (aniz by to delalo jakykoliv problem, na coz se vyborne hodi fork()) nebo je fajn, kdyz OS pro tyto veci nabizi zero-copy nastroje. (Tam trosku smerovala i ta poznamka o rozumnem IPC). A jeste jedna vec, sdilena pamet, do ktere muze zapisovat vice ruznych procesu/vlaken, neni dobry napad i ze softwarove inzenyrskeho hlediska. Za sdilene prostredky by mela byt zodpovednost vzdy na jednom miste...
A ty vyšší abstrakce bývají stejně postavené na nějakých zámcích, sdílené paměti, monitorech, vláknech… akorát od nich programátora odstíní, aby tyhle nízkoúrovňové mechanismy neviděl a nemohl v nich udělat chybu.Aneb zameteme problem pod koberec, podobne jako kdyz stavis dum na pisku (muze to fungovat hezky, ale pak te to dozene). Tyto abstrakce, protoze jsou postaveny na vlaknech, problem neresi jen skryvaji. Problem je, ze implicitne je povoleny jakykoliv pristup do pameti jakemukoliv vlaknu. Predstav si, ze mas souborovy system, kde vsechny soubory maji povolene cteni i zapis (protoze kontrola opravneni ma prece dopad na vykon). Kontrolu budes delat jen tam, kde hrozi nejaky problem a nastavis si prava pro pristup (pouzijes zamek), s tim, ze kazdy program ma pravo ten zamek ignorovat (vykaslat se na kontrolu zamku). Prijde ti to jako dobre navrzeny souborovy system? A v pripade vlaken to povazujeme za normalni vychozi stav....
o úskalích vícevláknového přístupu se ví už dlouhé roky a řešení jsou.To je hodne optimisticky nazor.
Tato argumentace me nechava ledove klidnym. Uz jsem ji zazil pred cca 20 lety, kdy se vedly vasnive diskuze, ze garbage collectory jsou spatne, protoze maji rezii a ze programator potrebuje mit moznost "prasit" s pameti, aby dosahl nejlepsiho mozneho vykonu. Spravny programator(tm) chyby nedela, protoze vzdy uvolni pamet, atd. atd.,
Zřejmě jsi přehlédl tu část: „Ono záleží dost na aplikaci/projektu“. A před těmi dvaceti lety: dost možná to bylo taky nedorozumění vycházející z toho, že není nějaké jedno programování, ale že jsou různé úlohy/projekty vyžadující různé postupy. Asi jsi byl v roli aplikačního programátora a bavil ses s někým, kdo to nechápal a snažil se ti nacpat svoje nízkoúrovňové postupy, na které byl zvyklý a které pro svoji práci možná opravdu potřeboval, ale nechápal, že pro tvoji práci jsou nevhodné. Taky jsem to zažil.
Mě např. udivuje, kolik věcí se dodnes píše v tzv. čistém céčku, i když je to pro dané úlohy naprosto nevhodně nízkoúrovňový jazyk a bylo by lepší použít nějaký vyšší → méně kódu, méně chyb, zanedbatelný negativní dopad na výkon (nebo dokonce jeho zlepšení). Když už, tak mi tedy dává smysl apelovat na to, aby lidé psali ve vyšších jazycích a používali nějaké dobré knihovny, frameworky a návrhové vzory. A ne apelovat na to, aby se z těch nízkoúrovňových jazyků nebo systémů odstranily nějaké „nebezpečné“ funkce.
Docela oblibeny byl i argument, ze Java je zbytecne pomala, protoze pri kazdem pristoupu do pole testuje, jestli nahodou neprekrocils jeho mez, a ze spravny programator potrebuje pointerovou aritmetiku (a spravny programator(tm) si dokaze pristup za meze pole pohlidat sam).
Ale málokdo píše v Javě operační systém.
Aneb zameteme problem pod koberec, podobne jako kdyz stavis dum na pisku (muze to fungovat hezky, ale pak te to dozene). Tyto abstrakce, protoze jsou postaveny na vlaknech, problem neresi jen skryvaji.
Tak by to bylo, kdyby použití vláken (nebo třeba té sdílené paměti) vedlo vždy k chybě. Ale tak to není. Použití těchto věcí pouze zvyšuje pravděpodobnost, že programátor udělá chybu. A tu knihovnu, framework nebo operační systém by měl psát někdo dostatečně zkušený a pečlivý, aby tu chybu neudělal a měly by tam být i dostatečné QA procesy, které ty chyby eliminují. Pak to není dům na písku nebo střepy pod kobercem, ale spíš zbraň zamčená v trezoru, od které má klíče jen někdo zodpovědný a použije ji, až k tomu bude legitimní důvod.
Predstav si, ze mas souborovy system, kde vsechny soubory maji povolene cteni i zapis
To je jiný případ, protože souborová oprávnění chrání jednoho uživatele před jiným, který by mohl mít špatné úmysly – proto to nemůže být na dobrovolné bázi. Ovšem ty abstrakce chrání programátora, aby neublížil sám sobě resp. svému programu – proto na dobrovolné bázi být můžou. Pokud vytvoříš abstrakci takovou, že lidi stejně radši budou používat ty nízkoúrovňové nebezpečné postupy, tak ta abstrakce asi není dost dobrá a nemá kvality, které od ní její uživatelé vyžadují.
Ano, něco může být dané setrvačností – např. když se něco učí na školách nebo když je někdo zvyklý celý život sdílenou paměť a nechce se mu se učit nějaké nové knihovny. Ale tohle jednak nemůže trvat věčně (pokud jsou abstrakce užitečné, tak si k nim lidé cestu najdou) a jednak je to spíš chyba těch škol než toho, že existují nějaké nízkoúrovňové nebezpečné techniky.
Asi jsi byl v roli aplikačního programátora a bavil ses s někým, kdo to nechápal a snažil se ti nacpat svoje nízkoúrovňové postupy, na které byl zvyklý a které pro svoji práci možná opravdu potřeboval, ale nechápal, že pro tvoji práci jsou nevhodné. Taky jsem to zažil.Ty diskuze byly napric softwarovou komunitou a tyto argumenty pouzivali bezne i lidi, co nedealali nic jineho nez mastili desktopove aplikace nad WinAPI.
Když už, tak mi tedy dává smysl apelovat na to, aby lidé psali ve vyšších jazycích a používali nějaké dobré knihovny, frameworky a návrhové vzory.A v tech vyssich jazycich potkaji vlakna, ktera umoznuji pristupovat kdykoliv a k cemukoliv.
A ne apelovat na to, aby se z těch nízkoúrovňových jazyků nebo systémů odstranily nějaké „nebezpečné“ funkce.Klidne at v tech nizkourovnivych vecech zustanou, ... ale jenom tam, ve vyssich programovacich jazycich je to pruser. Obzvlast, kdyz k tomu neni od OS rozumnejsi alternativa.
Ale málokdo píše v Javě operační systém.Takze pro vyssi prog. jazyky dava smysl zavrhnout nizkourovnove koncepty na ukor toho, ze programy budou bezpecnejsi i kdyz mirne pomalejsi?
Tak by to bylo, kdyby použití vláken (nebo třeba té sdílené paměti) vedlo vždy k chybě. Ale tak to není. Použití těchto věcí pouze zvyšuje pravděpodobnost, že programátor udělá chybu.Explicitni alokace/uvolneni/pristup k pameti taky nevede vzdy k chybe, ale je to nesporny zdroj problemu, a presto nikomu dnes neprijde divne, ze programovaci jazyky a jejich prostredi explicitne omezuji pristup k pameti, aby se temto problemum predeslo a programator nemohl udelat celou skalu chyb.
A tu knihovnu, framework nebo operační systém by měl psát někdo dostatečně zkušený a pečlivý, aby tu chybu neudělal a měly by tam být i dostatečné QA procesy, které ty chyby eliminují.Takze misto toho, abychom se spolehli na to, ze urcite typy chyb vubec nenastanou, tak se budeme tiset spolehat na to, ze kazdy vi, co ma delat a kdyz nekdo chybu udela, tak ji nekdo vcas vsimne.
spíš zbraň zamčená v trezoru, od které má klíče jen někdo zodpovědný a použije ji, až k tomu bude legitimní důvod.Pokud pristoupim na tve prirovnani, tak v takovem pripade, je to sice trezor, ale kteremu chybi zadni stena a kdokoliv si muze tu zbran vyzvednout, protoze neni zadny prostredek, ktery by mu v tom branil.
Ovšem ty abstrakce chrání programátora, aby neublížil sám sobě resp. svému programu – proto na dobrovolné bázi být můžou.Podobne jako dynamicke a staticke typy. Jenomze s vlakny si muzes vybrat jen tu dynamickou variantu.
Ovšem ty abstrakce chrání programátora, aby neublížil sám sobě resp. svému programu – proto na dobrovolné bázi být můžou.A chrani i tym programatoru pracujicich na jednom programu?
Pokud vytvoříš abstrakci takovou, že lidi stejně radši budou používat ty nízkoúrovňové nebezpečné postupy, tak ta abstrakce asi není dost dobrá a nemá kvality, které od ní její uživatelé vyžadují.S tim se da souhlasit, viz moje prodchozi komentare, ze kdyby existovala v mainstreamovych jazycich a OS rozumna podpora IPC a procesu, bez vlaken bysme se obesli a meli bychom o radu problemu min.
Ano, něco může být dané setrvačností – např. když se něco učí na školách nebo když je někdo zvyklý celý život sdílenou paměť a nechce se mu se učit nějaké nové knihovny.Byly doby, kdy globalni promenne byly standardem a jejich vymyceni dlouhy proces, ktery se dodnes nepodarilo dokoncit.
Ani v jednom pripade si nemohu dovolit, psat stylem "sem pridam jeste mutex, treba to zacne fungovat", nebo ekvivaletne "sem pridam timeout kdyz neprijde zprava".
Podobny problem je to v C. Clovek nemuze mit pusteny Valgrind a pridavat free(), tak jak mu to "poradi", ale musi mit nejaky (myslenkovy) framework, jak pracuje s pameti. Ja proti GC nic nemam, stejne tak bych ocenil i to lepsi IPC, ale vidim zde spis prinos v tom, ze to odstrani trivialni chyby, nez ze by to byla spasa, a vlakna se dala pouzivat i po deseti pivech.
11.4.2019 17:26
Jendа | skóre: 78
| blog: Jenda
| JO70FB
13.4.2019 21:19
aaaBBB`rm -rf ~`ccc.pdf.
Apr 11 12:57:57 st dbus-daemon[3431]: [session uid=1002 pid=3431] Activating via systemd: service name='org.gnome.evince.Daemon' unit='org.gnome.Evince.service' requested by ':1.534' (uid=1002 pid=4432 comm="evince /home/mono/mono.pdf") Apr 11 12:57:57 st systemd[2212]: Starting Evince document viewer... Apr 11 12:57:57 st dbus-daemon[3431]: [session uid=1002 pid=3431] Successfully activated service 'org.gnome.evince.Daemon' Apr 11 12:57:57 st systemd[2212]: Started Evince document viewer.
11.4.2019 13:06
Gilhad | skóre: 20
| blog: gilhadoviny
11.4.2019 13:01
Gilhad | skóre: 20
| blog: gilhadoviny
Fork is used byalmost every Unix shell,Ano! A sam taky pomerne casto zamerne pouzivam (source foo; command) nez abych resil nejake dalsi exportovani promennych a vytvareni dalsiho scriptu. Stejne tak se pouziva subshell pro "cat foo | while read line; do; ... done" <=> "cat foo | (while read line; do; ... done)". Takove veci by se bez forku delaly hodne spatne. A to ani nemluvim o tom kdyz mam subshell se zmenou file deskriptoru 0,1,2
11.4.2019 21:25