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 »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Tiskni
Sdílej:
Nebylo by lepsi, aby si kolega nasel praciUrčitě ne. Práce nic nevyřeší. Akorát krom toho, že nebude mít vůbec nic nebude mít ještě absolutně žádný čas min. do důchodu, kterého se pravděpodobně nikdy nedožije.
Ty jo, ty jses dobrej levicackej magor.Ten největší p. Jílek, ten největší
A jediným řešením jak se katastrofě vyhnout je přestat to podporovat, přestat donekonečna hledat zaměstnání a strat se víc o sebe a jak tuhle katastrofu přečkat, když už se jí nedá vyhnout.Jenže to, co dělá Jardík, podle mě není řešení. On to nepodporuje, ale ani k tomu není netečný - on se nechává podporovat. Tím zvyšuje průtok peněz mašinérií - sice opačným směrem, než kdyby pracoval (ve smyslu zaměstnání), ale zvyšuje.
A jediným řešením jak se katastrofě vyhnout je přestat to podporovat, přestat donekonečna hledat zaměstnání a strat se víc o sebe a jak tuhle katastrofu přečkat, když už se jí nedá vyhnout.je
sbalit pakle a utéct někam hodně daleko? Pokud to nebude někam hluboko do jihoamerického nebo afrického pralesa (a ani tam už bych si nebyl tak jistý), tak na novém stanovišti budeš nejspíš řešit tentýž problém.
Pokud to nebude někam hluboko do jihoamerického nebo afrického pralesaTo je daleko. Já mám pěkné, hluboké lesy vyhlédnuté už i u nás. Jinak někteří tak žijí i dnes (jednoho takového blázna mám dokonce v rodině přes pár kolen).
No jestli máš lepší řešení, tak sem s ním.Ty nemáš žádné řešení. Takže příště jenom postuluj problém a nesnaž se tvářit, žes to ty nebo Jardík fixnul.
Jak říkám, zde jsme se dostali do stavu, že už tady ani smrt nebere, všechna snaha marná. Všichni nech třeba shoří v pekle, hlavně abych do toho pekla se všema nemusel já. To by mě fakt sralo nejvíc.Nejsi v něm už? :) Bude válka?
Já mám pěkné, hluboké lesy vyhlédnuté už i u nás. Jinak někteří tak žijí i dnes (jednoho takového blázna mám dokonce v rodině přes pár kolen).OK, je pravda, že na tohle jsem nepomyslel (i když jsem o tom slyšel z vyprávění zcestovalých mudrců - o bačovi v Podkarpatské Rusi či kde). Osobně by se mi takový život asi nelíbil víc, než jakou pociťuji nechuť k systému, který popisuješ. Ale stejně se něčeho takového asi dožijeme…
Ty nemáš žádné řešení.Jaktože ne? Já se pokusím přežít, vy všichni se třeba udavte. Co na tom nevidíš jako řešení problému? Pro mě to řeší hodně
Nejsi v něm už? :)V tom stavu že budu muset do pekla se všema ostatníma? Pravděpodobně. Však ani nevíš jak mě to štve.
Bude válka?Ač vím vše, nejsem vědma. Ale obecně se nějaký SHTF scénář předpokládá. Ať už pomalý a agonický (třeba už v něm jsme), tak nějaká rychlovka.
Osobně by se mi takový život asi nelíbil víc, než jakou pociťuji nechuť k systému, který popisuješ.Znova opakuji: Máš-li lepší řešení, sem s ním.
Ale stejně se něčeho takového asi dožijeme…O tom nepochybuj ani na vteřinu. A když ne my, generace našich dětí určitě.
Jaktože ne? Já se pokusím přežít, vy všichni se třeba udavte. Co na tom nevidíš jako řešení problému? Pro mě to řeší hodněAha, myslel jsem, že řešíš, jak to přestat podporovat, ne jak to přežít. Mea culpa.
Znova opakuji: Máš-li lepší řešení, sem s ním.Co místo útěku a sbírání kořínků naopak zkusit, aby tvůj kousek civilizace s tebou přežil co nejdýl, než se situace uklidní? Postavit bunkr (kamarádi survivalisti tedy zastávají spíš politiku moving-target, takže nakoupit V3S
Aha, myslel jsem, že řešíš, jak to přestat podporovat, ne jak to přežít.Víš co by řekl John Connor? Teda krom toho, že Soudný den je neodvratitelný?
A jak to přestat podporovat?
Krok č.1: Přestat docházet do zaměstnání, přestat platit daně, přestat kupovat krámy které nepotřebuješ,…
Ale ne, teď vážně. Existují nějaké nástřely teorií udržitelného rozvoje či jakési permakultury, ale to je v současném stavu všem spíš k smíchu a existuje jen pár bláznů co se tím zabývá.aby tvůj kousek civilizace s tebou přežil co nejdýl,Nemožné a vyloučené. Můj kousek civilizace tvrdě narazí do zdi ve vysoké rychlosti. O tom nepochybuju. Jen bože dej ať u toho nejsem já.
Postavit bunkVšak to jsou ti blázni nejhrubšího zrna. Do smrti se valit konzervama v betonovém bunkru, no to bych radši pošel hlady. Fakt nevím jak si to jako představují.
Kde beres tu jistotu?Protože vidím to co ostatní ani nevnímají.
Jen bože dej ať u toho nejsem já.Neco me to pripomina.
S tím sledováním to máš těžký. Například v zákoně o evidenci obyvatel se píše:
Po úmrtí občana nebo prohlášení osoby za mrtvou se údaje v informačním systému uchovávají po dobu 75 let.
Tady ani po smrti nebudeš mít klid.
pěšky dojítProtip: s téměř nulovou TCO můžeš svoji rychlost i akční dosah zvýšit zhruba 5x. Stačí najít vyhozené kolo nebo koloběžku.
To samozřejmě předpokládá, že nejste v pozici prosebníka, pokud po úřadu něco chcete vy, není dobré mu to komplikovat. Já se ovšem nacházím v pozici opačné, po státu nic nechci, většinou chce stát něco po mně, tak ať si s tím poradí.Geniální myšlenka.
Grunte uz se konecne zabij. Vis ze to chces udelat. Udelas vsem radost. Vazne.Průhledné. Tohle by loki nikdy nenapsal.
otazkou ale zustava, kdo je teda falesni Jilek? Zeby SKK? Sledujte nas aj v dalsim blogu....Tobě ta SKK nějak leží v žaludku, pravý nepravý jílku. Kdoví, který z těch dvou. Ať je to tak, nebo onak, blb se nazapře.
Nějaký práva bych stále pak mohl mít, třeba by mě neměl majitel týrat, kvůli týrání zvířat??Na to bych nesázel, vzhledem k tomu, že většina zákonů proti týrání zvířat za moc nestojí...
tak pak už nemusím platit zdravotníBudeš muset platit poplatek za psa
No a když budu tím psem, tak pak už nemusím platit zdravotní?Ne, ale budeš muset při styku s úřady štěkat a radostně vrtět ocasem
Michal je kun, takze toho o problematice hodne vi. (zdroj)
Zasadni vec je, ze Vy si sam trvaly pobyt nezrusite. Vetsinou Vas musi nekdo odhlasit.To je pravda. Jediné, co pro to člověk může dělat je neodvolat se, popřípadě rovnou podepsat, že se možnosti odvolání vzdává.
Pro me to osobne byla vyhra, nebot jsem 15 let mel trvale bydliste v objektu, odkud jsem nemel ani klice. O obcasnem prebirani posty osobou stejneho jmena a prijmeni radeji nemluve.Znám víc lidí, kteří měli tímto způsobem problémy s kradením pošty.
Nikdo me nechtel odhlasit a ani nikam prihlasit.Nic moc situace.
Dobry odkaz je v tomto prispevku: http://www.abclinuxu.cz/blog/jarda_bloguje/2013/9/bezdomovcem#8ಠ_ಠ
Dobrý odkaz je v tomto příspěvku: http://www.abclinuxu.cz/blog/jarda_bloguje/2013/9/bezdomovcem#8 (Úředně bezdomovcem: Trvalé bydliště, proč ho mít a proč ne)
i keď nechápem, kam zmizel môj normálny editorKdyž klikneš na tlačítko Editor (překvapivě), zmizí ta javascriptová sračka a objeví se standardní editor tvého webového prohlížeče (textarea).
si pripadám ako jardík... ja tiež u neho neviem, či to čo píše myslí vážne, polovážne alebo je to niečo ako Radošinské naivné divadlo... ale ja si fakt nerobím srandu, chlievik na linky sa mi v tom normálnom editore, namiesto toho mám v okne, ktoré sa otvorí plno tých html a javascriptov či čo je to
Kdyz jsem byl mladsi a ted, tak jsem vetsinou poslouchal, to co zkusenejsi s praxi rikali, protoze jsem tak nejak tusil, ze jako starsi to jakoby najdu.goldenfish byl právě usvědčen ze lži.
<textarea>
a je na klientovi, co s tím udělá.
Jinak můj prohlížeč umí detekovat odkazy i při zobrazování.Jo, to jsem měl na mysli, a to jsem měl dopsat do původního příspěvku. IMHO to řeší Bystroushaakův problém bez toho, aby se tu musela rozvíjet vlákna nesouvisející s původním příspěvkem... oh wait! Zase součástí problému! °_° Přeplánuju se...
Proc ? Je to otravne, kdyz Vam nekdo opravuje formu, kdyz Vy delate ten obsah a ten, co opravuje tu formu vlastne neprida po Vas prispevek zadnou pridanou obsahovou hodnotu.Přidá užitnou hodnotu, protože ostatní se na ten odkaz konečně budou moct podívat.
Pointa: ty informace/obsah _byly_ dulezitejsi nez forma.Jo, jenže tohle tvrzení neříká, že forma je nepodstatná, jen že je míň podstatná. Stojím si za názorem, že by lidi měli na webu používat odstavce a odkazy, jinak je pro mě (a asi i pro ostantí) opruz to číst.
Zkuste nekoho v rozhovoru neustale opravovat s vyslovnosti a se skladbou vet. Vykasle se na Vas, nebot budete pusobit dojmem, ze Vas vlastne zajima neco jineho.Jenže já neopravoval gramatiku, ale neexistující odkazy.
Chapejte to i z te druhe strany.50 blogů mě to tu naučilo chápat i z druhé strany. Většinou na to říkám dík a chybu opravím. Diskuze jsou o něčem jiném, to ano, ale když někdo přidá odkaz, nepřijde mi adekvátní ho za to jebat.
Jenže já neopravoval gramatiku, ale neexistující odkazyA s mým přispěním zaplevelili diskusní vlákno rozrůstajícími se vlákny a pohřbili je tak pro neregistrované, kteří čtení mohou věnovat z nějakého důvodu pouze omezený čas (TLDR). Nemůžeš na mobilu použít prohlížeč, který ti automaticky promění URL v hypertextový odkaz?
Proč mají poslední dobou všichni, kdo jsou opraveni tendence brát to jako osobní útok?
Ono je dosť ťažko aj pri najlepšej snahe rozoznať opravné tendencie od osobného útoku. Najmä ak bol niekto už nejakým davom - ako to vravíte - stalkovaný, resp. mobbovaný. To video bolo výstižné a vtipné a každý by sa v tom mohol nájsť. Ale iste budú aj takí, ktorí v tom uvidia len tých druhých a seba nie.
odkazy
Niektoré problémy mi ako problémy nepripadajú.Napr si okopírujem toto:http://youtu.be/Q1KOOSw_hkY( aby som ilustrovala kto frčal na našich školských večierkoch:)) do súboru v text. editore (čo si otvorím za zlomok sek.), pravé tlačidlo myšky, Edit Hiperlink- Open Hyperlink alebo to hodím rovno do príkazového riadka prehliadača či do googla, a som doma. Kakaja problema?, :) Na druhej strane neodolám, ak vidím nejakú do neba volajúcu hrúbku, i keď som sama preklepová kráľovná a nepochopiteľne vyrobím občas štylisticky príšernú vetu a spravím tú hrúbku tiež. Hoci nechápem, ako sa to vlastne stane. Ale nie že by mi tie hrúbky tak vadili, tak ako mi nevadia ani ponožky v sandáloch. My sme sa kdysi museli oveľa viac vyjadrovať písomne a nemali sme nastavenú kontrolu pravopisu - to je podobné, ako keď žiaci dnes často nemajú zautomatizované tie mechanické počtové úkony, lebo im od ZŠ dovolili pri nich používať kalkulačky. Skrátka, jeden vie to a iný ono, aby som parafrázovala Wericha z tej slávnej rozprávky, a všetci dohromady vieme veľké to...:).
za pomoci toho "nenormálneho" editora:))
Niektoré problémy mi ako problémy nepripadajú.Napr si okopírujem toto:http://youtu.be/Q1KOOSw_hkY( aby som ilustrovala kto frčal na našich školských večierkoch:)) do súboru v text. editore (čo si otvorím za zlomok sek.), pravé tlačidlo myšky, Edit Hiperlink- Open Hyperlink alebo to hodím rovno do príkazového riadka prehliadača či do googla, a som doma. Kakaja problema?, :)Díky za návod. Na počítači ho vyselektuji a přetáhnu na urlbar taky, ale pointa toho na co nadávám je, že mnoho lidí v dnešních dobách není na počítači, ale na tabletech, mobilech a ebook readerech čí na terminálech kdesi na nádraží a tam to budou dělat jen pěkně blbě. Vím to z vlastní zkušenosti.
mnoho lidí v dnešních dobách není na počítači, ale na tabletech, mobilech a ebook readerech čí na terminálech kdesi na nádražíTo je strašná závislosť, ja tento svoj noutbúčik tiež milujem ( napr. včera som strávila deň tým, že som sa pokúšala vyrobiť amatérsky "klip" k pesničke - v noci som to po celodennej zábavke omylom zmazala:)) ale je to dosť ťažké hebedo, tak ho sebou neťahám a okrem toho nemám mobilný internet-našťastie.
§ 474 odst. 1 obč. zák. Společnou domácností ve smyslu ustanovení § 115 a § 474 odst.1 obč. zák. se rozumí podle ustálené judikatury soudů soužití dvou nebo více fyzických osob, které spolu žijí trvale a které společně uhrazují náklady na své potřeby. Společná domácnost zpravidla předpokládá společné bydlení v jednom nebo více bytech (k naplnění jejích znaků proto nepostačují např. občasné návštěvy); výjimka z tohoto pravidla je možná jen tehdy, jde-li o dočasný a přechodný pobyt jinde z důvodu léčení, návštěvy příbuzných, výkonu práce apod. Jde o spotřební společenství trvalé povahy, a proto společnou domácnost představuje jen skutečné a trvalé soužití, v němž její členové přispívají k úhradě a obstarávání společných potřeb (nepostačuje např. jen příležitostná výpomoc v domácnosti, společné trávení dovolených apod.) a v němž společně a bez rozlišování hospodaří se svými příjmy. Spolužijící fyzická osoba musí žít ve společné domácnosti tak, jako by byla členem rodiny; vyžaduje se, aby pečovala o společnou domácnost (obstaráváním domácích prací, udržováním pořádku v bytě, obstaráváním prádla a údržby šatů, přípravou jídla apod.) nebo poskytovala prostředky na úhradu potřeb společné domácnosti nebo aby byla odkázána výživou na zůstavitele.exekútor by nemal siahať na majetok rodičov neplatiča alebo dlžníka, tn by si mal počkať až na to, keď bude mať dlžník sám nejaký majetok... exekúcii sa radšej vyhnúť tak, že nijaký dlh nikde nevznikne
ps. ten algoritmus co popisuješ je už si myslím vymyšlený. Zbývá třebas vzít kousek toho kousek tohodle a plátek po plátku to dodělávat. Cesta nemusí být hnedka vytyčená a namalovaná dopředu. Stačí si určit přibližně směr a vydat se kupředu.
Co chtěl by jsi něco udělat? Práce je dost kolem dost a dost jenom se do toho pustit.
... v C zase musím moc psát, řešit návratový hodnoty chyb, protože nemám výjimky, neustále řešit malloc, free a spol.
Osobne mi pride, ze v C staci pisat priemerne vela. Za (zbytocne) ukecane jazyky povazujem skor javu (tu obvzlast) alebo c++. Samozrejme C povazujem za ukecanejsi jazyk nez python alebo haskell, ale tam nejde o moc ferove porovnanie.
Ako najvacsi problem C mi pride to, ze sa zvacsa neuci poriadne. Zvacsa ho davaju do uvodnych kurzov, kde sa preberie len velmi mala podcast jazyka a v dalsich kurzoch sa prejde na c++/javu/nieco ine. Vysledok je, ze ludia v C nevedia programovat a nakecaju o nom kadeco (casty nazor je napr. ze v C nie je mozne posielat funkcie ako parametre...).
Osetrenie chyb: Ak myslis errno, tak nie je nic jednoduchsie nez napisat macro, ktore to skontroluje pri kazdom zavolani (a pre vacsinu pouziti to bude stacit), nasledne sa cele osetrenie moze spravit zavolanim call(funkcia(parametre)), kde call je dane macro. Pokial by bola povaha vynimiek moc roznoroda je mozne pridat parameter pre povolene chyby, tj. definovat call tak, aby sa volal v tvare call(fcia(param), ENOSPC | ENOENT).
Vysledok v podstate nahradza vynimky s miernym overheadom (z hladiska pisania kodu), ale zas s vacsou kontrolou nad nimi.
malloc: ten je dnes potrebny jedine v pripade nutnosti realokovatelnej dynamickej velkosti dat, co nie je az tak caste. Nerealokovatelnu dynamicku pamat je mozne spravit pomocou indexacie velkosti pola premennou (aspon od c99). Navyse zvacsa (ak nie vzdy), ked je nutne mat realokovatelnu dynamicky alokovanu pamat, tak sa da na to mysliet uz v navrhu a na jednom mieste data alokovat, na druhom mieste realokovat, na tretom mieste dealokovat.
malloc: ten je dnes potrebny jedine v pripade nutnosti realokovatelnej dynamickej velkosti dat, co nie je az tak caste.Me prijde, ze typicka situace, kdy musim resit malloc, je system nejakych struktur a retezcu. Jiste, da se napsat asi funkce, ktera to cele alokuje a dealokuje, ale to taky neni vzdycky idealni, protoze casto je potreba pak ty pole menit nebo jsou jejich velikosti zname az v prubehu pouzivani te struktury (napr. prijde pozadavek ze site), takze se musi znovu (re)alokovat.
Nj, najdu sa mozno aj ine pripady, napr. ak treba alokovanu pamat mat aj po skonceni funkcie, v ktorej bola vytvorena, ale stale si myslim, ze ich nie je zas az tak vela (navyse je teoreticky mozne vsetku alokaciu indexaciou presunut do main, takze pamat bude dostupna v hociktorom bode programu).
Napr. nasledujuci kod predstavuje validny c99 program (to, ze je velkost znama az za behu nevadi, povoluje sa to prave od c99, do funkcii je mozne posielat array po pretypovani na (int *) uplne bez problemov).
#include <stdio.h>
#include <string.h>
void fill(int *a){
a[0]= 123456;
}
int main(){
int i;
scanf("%d", &i);
if(i < 1)
return 1;
int array[i];
fill(array);
printf("(%d, %d)\n", sizeof(array), array[0]);
return 0;
}
Samozrejme suhlasim s tym, ze niekedy je lepsie pouzit dynamicku alokaciu. Idea prikladu mala byt skor v tom, ze sa casto dynamicka alokacia pouziva tam, kde nie je zas az tak moc potrebna a da sa relativne jednoducho obist (+ ze ak niekto fakt moc chce, tak s trochou snahy sa dynamickej alokacii moze vyhnut skoro uplne).
Zrovna pri strukturach, ktore sa odkazuju na dalsie data mi pride ako dobry princip pouzivat jednu dealokacnu funkciu (resp. ich sadu podla typu struktury), ktora dealokuje vsetky jej ne-NULL podstruktury automaticky (rekurzivne napr. volanim dealokacnych funkcii podstruktur).
So sietovym programovanim nemam moc skusenosti a neviem, kde by mal byt v tomto pripade problem. Ak ide o to, ze na poziadavky zo siete sa pocuva v inom threade, tak bude asi lepsia dynamicka alokacia.
Obavam se ze tim bys hodne omezil vypocetni schopnosti.Přečti si někdy zdrojáky mplayeru nebo libav. Je to až k nevíře jak moc se tam alokuje i přesto že data expandují.
Kazdopadne uz by ale neplatilo "takže teoreticky může existovat libovolný program"Ok, tak asi úplně libovolný ne (ono to asi víc záleží na úloze než na programu samozném).
Obavam se ze tim bys hodne omezil vypocetni schopnosti. Pravdepodobne na vypocetni silu regularnich jazyku. Kdyz bys to udelal hodne chytre tak bezkontextovych jazyku.
Z hladiska realnej konecnosti pamate by to bolo, samozrejme, popisatelne konecnymi automatmi (ako v podstate vsetko ostatne), ale ak by sa abstrahovalo od jej konecnosti (i.e. velkost pamate nemusi byt fixna a pod. -- podobne sa to aj robieva), tak to pripomina skor linearne ohranicene turingove stroje (automaty pre kontextove jazyky -- jazyky typu 1) -- turingove stroje, ktore nemozu ist za svoj end marker.
tak to pripomina skor linearne ohranicene turingove strojelinearne ohraniceny TS muze mit pasku delsi nez vstup (jeji delka musi byt linearni funkce delky vstupu). Zatimco tady bys by omezeny jenom na delku vstupu. Takze silu omezenych TS by to nemelo.
To hej, ale aj na tom disku bude asi nejake volne miesto a predpoklad, ze je to volne miesto (lubovolne) linearne s ohladom na vstup mi pride na podobnej urovni ako standardny predpoklad, ze pamat je nekonecna.
Vlastne ide o slabsi predpoklad nez standardny predpoklad o nekonecnej pamati, kedze ak by sa predpokladalo, ze pamat je nekonecna, tak pri jej plnej alokacii clovek dostava priamo turingove stroje (samozrejme, v praxi to je obmedzene maximalnou velkostou virtualneho adresoveho priestoru).
Inak prirodzene plati, ze lubovolny sucasny program na realnom pocitaci je popisatelny regularnymi jazykmi prave vdaka konecnosti pamate, ale v praxi tento fakt nema moc velky vyznam.
Inak prirodzene plati, ze lubovolny sucasny program na realnom pocitaci je popisatelny regularnymi jazykmi prave vdaka konecnosti pamate, ale v praxi tento fakt nema moc velky vyznam.Ne tak docela. Napadaji me 2 scenare kdy to nemusi platit: - program ktery nejak komunikuje se svetem - i program ktery nekomunikuje bude popsatelny konecnym automatem jenom ve chvili kdy jeho instanci spustis na nejakym konkretnim stroji. Ten samotnej binarni kod / zdrojovy text popsatelny konecnym automatem byt nemusi...
Kazdy realny program (vynimkou mozu byt kvantove pocitace a kvantove vypocty, ale tam ide o iny princip) je obmedzeny maximalnou velkostou virtualneho adresneho priestoru a apriori konecny. Program, ktory komunikuje s vonkajsim svetom z neho dostane len konecne mnozstvo informacie, ktore je opat obmedzene maximalnou velkostou virtualneho adresneho priestoru. Nic z toho nedava nekonecnost, co je nutna podmienka pre nepopisatelnost konecnymi automatmi.
Samotne algoritmy (funkcie), samozrejme, pracuju s nekonecnymi datovymi typmi, takze podobnymi obmedzeniami netrpia a prave na ich zaklade vznikali hierarchie roznych jazykov. Ovsem tak isto plati, ze samotny algoritmus (abstrahovany na nekonecne datove typy) nejakeho realneho programu pracujuceho s konecnou pamatou alokovanou cez mmap by mohol patrit az do triedy turingovskych jazykov.
Dalsie uvahy by mohli smerovat k tomu ci je cely vesmir nekonecny a, teda, ci je mozne realne mat nekonecnu pamat. Afaik sa dnes predpoklada skor, ze je velkost celeho vesmiru konecna (nekonecnost sa pri kvantovych vypoctoch ziskava skor predpokladom na spojitost vesmiru).
Kazdy realny program (vynimkou mozu byt kvantove pocitace a kvantove vypocty, ale tam ide o iny princip) je obmedzeny maximalnou velkostou virtualneho adresneho priestoru a apriori konecny. Program, ktory komunikuje s vonkajsim svetom z neho dostane len konecne mnozstvo informacie, ktore je opat obmedzene maximalnou velkostou virtualneho adresneho priestoru. Nic z toho nedava nekonecnost, co je nutna podmienka pre nepopisatelnost konecnymi automatmi.I turinguv stroj ma *konecne* stavove rizeni. Pokud muze PC komunikovat se svetem tak si ho muzes zjednodusene predstavit jako hlavu TS.
TS sice ma konecnu mnozinu stavov, ale moze mat nekonecnu mnozinu vstupov a vystupov (to ziadny realny program nema a ani nemoze mat). Aj take buchiho automaty (co su v podstate konecne automaty nad nekonecnymi slovami) maju len konecnu mnozinu stavov pritom omega-regularne jazyky sedia v hierarchii niekde uplne inde (trieda obsahuje vyhradne jazyky nekonecnych slov...). Ani obycajna identita na prirodzenych cislach potom nie je na rozdiel od TS realizovatelna lubovolnym realnym programom. Vstup (ako aj vystup) lubovolneho realneho programu bude bez ohladu na povod vstupu vzdy limitovany maximalnou velkostou adresoveho priestoru (pripadne velkostou realnej pamate). S ohladom na vyssie popisane je potom lubovolny realny program vyjadrovacou silou v triede regularnych jazykov a existuju aj regularne jazyky nerealizovatelne lubovolnym realnym programom.
Dokaz, ze lubovolny konecny jazyk je akceptovatelny konecnym automatom je potom relativne jednoduchy. V podstate sa len vytvori konecna tabulka povolenych vstupov na zaklade ktorej je potom jednoduche napisat vysledny konecny automat s konecnym stavovym priestorom, vsetky neobsadene vetvy vypoctu potom vedu do stavu, ktory zamieta.
To, ze si nieco mozem nejak predstavit neznamena, ze to nepatri do slabsej triedy hierarchie. Vzdy plati, ze silnejsia trieda chomskeho hierarchie obsahuje lubovolny jazyk slabsej triedy chomskeho hierarchie.
Vstup (ako aj vystup) lubovolneho realneho programu bude bez ohladu na povod vstupu vzdy limitovany maximalnou velkostou adresoveho priestoru (pripadne velkostou realnej pamate).Tady mas chybu. Pokud muzu komunikovat se svetem tak nepotrebuju cely vstup nekam ukladat.
Dokaz, ze lubovolny konecny jazyk je akceptovatelny konecnym automatom je potom relativne jednoduchy.takovyhle elementarni veci me vysvetlovat nemusis
To, ze si nieco mozem nejak predstavit neznamena, ze to nepatri do slabsej triedy hierarchie.v tomhle pripade znamena. viz chyba nahore.
A, tak, obojsmerna komunikacia. Ak sa abstrahuje pamat na cely vesmir, co asi, teda, bolo myslene tou komunikaciou, tak sa otazka prevadza na to, ci je vesmir konecny alebo nie. Ty predpokladas, ze tak mozes dostat nekonecnu pasku. Ja sa priklanam skor k tomu, ze je to ohranicetelne konstantou, ktora je konecna.
Inak, z hladiska beznych (diskretnych) vypoctovych strojov predpoklad na spojitost vesmiru nehra dolezitu rolu a afaik sa v sucasnosti vesmir povazuje skor za konecny.
Mmap dovuluje virtualne alokovat pamat az do velkosti virtualneho adresneho priestoru, takze neostava ziadna volna pamat na dynamicku alokaciu. Pamat je potom realne alokovana jadrom az pri pristupe do nej. Viz princip vstupnej a pracovnej pasky popisany tu.
Nj, da sa na to da pozerat aj tymto sposobom. Z tohto hladiska by som sa drzal toho, ze pre premenlivu a dopredu neohranicitelnu velkost dat je dynamicka alokacia nutna.
Len tak pre zaujimavost: archaicke verzie fortranu fungovali len cisto so statickou pamatou a ono to nejak (aj ked prevazne na vypocty) slo.
Pamatova zlozitost by pri mmap nemusela byt az tak zla. Pri zavolani mmap sa alokuje len virtualny adresny priestor, nie realna pamat. Realna pamat sa alokuje az pri jej pristupe (zapis/citanie) priamo jadrom systemu. Tiez je, myslim, mozne dealokovat/uvolnit len podcast celej virtualnej alokovanej pamate cez munmap (a tym dealokovat aj jadrom alokovanu realnu pamat).
Viem, ze je to aj matematicky definovany pojem, ale v pripade mmapu sa ma podla mna pocitat pamatova zlozitost skor ako pocet pristupov do virtualne alokovaneho adresneho priestoru nez ako velkost virtualneho adresneho priestoru. Nejaky overhead tam asi bude, ale myslim, ze by sa dal ohranicit konstantou (aj ked isty si tym nie som, rad sa necham poucit ak ma niekto detailnejsiu predstavu o implementacii mmapu v jadre).
Viem, ze je to aj matematicky definovany pojem, ale v pripade mmapu sa ma podla mna pocitat pamatova zlozitost skor ako pocet pristupov do virtualne alokovaneho adresneho priestoruTo je implementační detail (taky bys to mohl alokovat po bajtech až v okamžiku přístupu - řekněme, že by to tvůj OS uměl). A paměť, do které nikdy nepřistoupíš, nemá cenu alokovat…
Ono je skor potrebne nejak korektne definovat velkost vstupu. Pri mmap by som za velkost vstupu povazoval data v obsadenej casti virtualneho adresneho priestoru potrebne pre vypocet. Pamatova zlozitost je potom pocet pristupov do casti virtualne alokovaneho adresoveho priestoru, ktora nie je obsadena.
Slo by potom o podobny princip ako sa pouziva pri turingovych strojoch so vstupnou a pracovnou paskou. Vstupna paska by obsahovala data pristupene z obsadenej casti virtualneho adresneho priestoru, pracovna zas data pristupene z neobsadenej casti virtualneho adresneho priestoru. Prakticka implementacia napr. cez 2 mmapy. Jeden na cele medium, kde su ulozene data -- obsadena cast. Druhy virtualny pre zvysnu volnu pamat.
V praxi by bol potom skor problem s tym, ze zapis do neobsadenej pamate by bol prilis pomaly (data by sa zapisovali aj na dane medium, slo by to asi obist cez mmap na ramdisk, samozrejmostou je potom overhead).
Tak som sa konecne dostal k opatovnemu precitaniu vetvy, ktora viedla k prispevku od JS1. Povodne som cital komentar vytrhnuty z kontextu a ocakaval som, ze ide o staznost na nadmernu pamatovu narocnost pri pouziti mmap. V danej formulacii by slo s prispevkom od JS1 celkom suhlasit.
Vysledok v podstate nahradza vynimky s miernym overheadom (z hladiska pisania kodu)Nejenom z hlediska psaní kódu.
malloc: ten je dnes potrebny jedine v pripade nutnosti realokovatelnej dynamickej velkosti dat, co nie je az tak caste. Nerealokovatelnu dynamicku pamat je mozne spravit pomocou indexacie velkosti pola premennou (aspon od c99).Varriable-length array v C99 má ještě jednu nevýhodu mnohem výraznější než to, že nejde realokovat: dá se pomocí něj alokovat pouze místo na stacku. A v C se na stack-based memory management moc nehraje.
v C se na stack-based memory management moc nehrajeJak by takova vec mela v praxi vypadat? (co by to melo delat?)
Nejenom z hlediska psaní kódu.
Vykonnostny overhead podla mna nebude nejak tragicky. V pripade uspechu funkcie indikovanou jej navratovou hodnotou sa vyhodnoti jedna podmienka a ak sa k tomu prida este nejaka optimalizacia cez unlikely/likely, tak ten vykonnostny overhead bude podla mna podobny ako pri vynimkach v C++ (ak nie este mensi).
Varriable-length array v C99 má ještě jednu nevýhodu mnohem výraznější než to, že nejde realokovat: dá se pomocí něj alokovat pouze místo na stacku. A v C se na stack-based memory management moc nehraje.
Je nutnost alokacie na stacku priamo v standarde C99? (neviem, skutocne sa len pytam). Kompilator to moze kludne previest na sekvenciu malloc/free pri ukonceni funkcie. Napisat podobnu optimalizaciu kompilatora by snad ani nemuselo byt moc obtiazne (ak uz nieco podobne neexistuje).
btw: +1 za scope pri zasobniku namiesto frame
Vykonnostny overhead podla mna nebude nejak tragicky.Máš pravdu, teď jsem nakoukl i do jednoho svýho starýho zápisku na tohle téma a ten overhead je naprosto minimální...
Je nutnost alokacie na stacku priamo v standarde C99? (neviem, skutocne sa len pytam).Špatně jsem se vyjádřil, měl jsem na mysli scope, jak poznamenal kolega extremni lama výše. Čili ten problém je, že doba života toho pole je vázána na nějaký scope, což je dáno standardem (v C11 §6.2.4.7):
For such an object that does have a variable length array type, its lifetime extends from the declaration of the object until execution of the program leaves the scope of the declaration. If the scope is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate.(Ono by to dost dobře ani jinak nešlo, že...) No takže tenhle způsob alokace bude asi docela super na nějaké dočasné buffery použité v rámci funkce a podobně. Naopak ale není moc použitelnej pro předávání dat mezi různými částmi programu, který nemají dostatečně společného scope nebo mezi knihovnou a programem, hlavně tedy případy kdy ta data jsou součástí nějaké struktury-kontextu, apod...
Špatně jsem se vyjádřil, měl jsem na mysli scope, jak poznamenal kolega extremni lama výše. Čili ten problém je, že doba života toho pole je vázána na nějaký scope, což je dáno standardem (v C11 §6.2.4.7):
Problem so scope, samozrejme, existuje. V teorii prekladacov sa nieco podobne riesi cez export a import staticky alokovanych premennych (ale C toto afaik neobsahuje a s istotou neviem povedat, ktory jazyk by to mal, mozno Ada?) -- tj. export oznaci premennu na nevymazanie pri ruseni funkcie, import premennu presunie/skopiruje do scope funkcie, kde bola importovana. Tolko k praxi.
V teorii programovania je potom mozne ist este dalej a vsetku alokaciu statickej pamate presunut priamo do main, pripadne do (viacerych urovni) podfunkcii, ktore by oznacovali scope/rozsah platnosti danych premennych (nech existuje aj nejaka dealokacia). V praxi je to, samozrejme, neprakticke. Aj ked skor mi islo o to ukazat, ze ak niekto fakt chce, tak sa moze dynamickej alokacii pamate vyhnut v podstate vsade, kde nepotrebuje pamat realokovat.
No takže tenhle způsob alokace bude asi docela super na nějaké dočasné buffery použité v rámci funkce a podobně. Naopak ale není moc použitelnej pro předávání dat mezi různými částmi programu, který nemají dostatečně společného scope nebo mezi knihovnou a programem, hlavně tedy případy kdy ta data jsou součástí nějaké struktury-kontextu, apod...
Z praktickeho hladiska samozrejme suhlasim a priklad mal prave aj naznacit to, ze ten malloc sa casto vola zbytocne a potom sa nadava na nutnost neustaleho volania malloc/free.
např. v C++11 nedodělek std::async, std::future bez callbacku, takže to do ničeho nejde integrovat, např. když potřebuješ pak něco plyvnout do jakýsi event loopy, aby se probrala a zpracovala výsledekA jak bys to chtěl udělat?
std
nemá žádnej svůj event loop ve kterým by mohl periodicky kontrolovat stav future
a na základě toho volat callbacky. To musíš vyřešit v rámci toho event loop systému, kterej používáš.
Pak tu není pořádná GUI knihovna, Qt je moloch, kde používají int na všechnoQt je ve verzi 5 dost de-molochované. S tím
int
em souhlasím, to je hrozná blbost. Je škoda, že to v Qt5 neopravili, což klidně mohli vzhledem k tomu, že kompatibilita byla porušena tak jako tak. Resp. možná, že to někde opravili, ale u QByteArray
ne.
No nicméně se s tímhle problémem dá vyrovnat v situacích, kde to je potřeba...
A jak bys to chtěl udělat? std nemá žádnej svůj event loop ve kterým by mohl periodicky kontrolovat stav future a na základě toho volat callbacky. To musíš vyřešit v rámci toho event loop systému, kterej používáš.Řešení je navrhované pro C++14, std::future by mělo dostat then() fcu pro nastavení callbacku, který je zavolán poté, co se mu nastaví hodnota. Tento callback je samozřejmě volán z vlákna, kde se nastavila hodnota příslušnému std::promise. S tím pak jednoduše můžete do roury/eventfd zapsat byte, aby to probudilo vlákno, co čeká na nějakým tom epollu, nebo mu poslat signál. Integraci se všemi 3rd party event loopy standard řešit nemůže, ale může to takto udělat integrovatelné pro uživatele. V současném stavu (C++11) jste odkázáni prakticky na blokující čekání.
Qt je ve verzi 5 dost de-molochované. S tím intem souhlasím, to je hrozná blbost.Jejich argument je 'můžeme používat -1 pro chybový stav' a to, že pak půlka fcí vypadá, jako že záporné hodnoty jsou ok, je nám jedno. Třeba fce read(qint64) mi jasně říká "je ok předat mi zápornou hodnotu, v tom případě budu číst pozpátku". Taky mi říká "je ok číst nějakých qint64_max bytů, i když na té platformě je max. velikost objektu SIZE_MAX a SIZE_MAX je miliónkrát menší než QINT64_MAX. Nebo je ok číst QINT64_MAX i když vrácený QByteArray může mít jen INT_MAX bytů. Nebo mi říká "na téhle platformě, kde je SIZE_MAX 2^128-1 a QINT64_MAX jen 2^64-1 ti dovolím číst jen QINT64_MAX bytů, protože musíme používat svoje datové typy, protože mají na začátku 'q', a proto ti nedovolím využít potenciál tvé platformy.
Řešení je navrhované pro C++14, std::future by mělo dostat then() fcu pro nastavení callbacku, který je zavolán poté, co se mu nastaví hodnota. Tento callback je samozřejmě volán z vlákna, kde se nastavila hodnota příslušnému std::promise.No tak fajn.
Jejich argument je 'můžeme používat -1 pro chybový stav' a to, že pak půlka fcí vypadá, jako že záporné hodnoty jsou ok, je nám jedno. Třeba fce read(qint64) mi jasně říká "je ok předat mi zápornou hodnotu, v tom případě budu číst pozpátku".Mně se ty jejich konvence taky nelíbí, nicméně na druhou stranu ty to bereš hrozně puristicky. To, že funkce bere jako platnou třeba jen nějakou podmnožinu hodnot předatelných datovým typem parametru, mi přijde zcela normální. Od toho je dokumentace. Souhlasím, že pokud neberu záporný hodnoty jako platný, je lepší zvolit
unsigned
typ, ale oni se rozhodli nepoužívat exceptions a toto je důsledek. Dá se to bez problému přežít.
Co se týče qint64
, rozhodně nevěřím, že bys jedním voláním funkce read()
četl víc než QINT64_MAX
dat. Jak dlouho by asi takový volání blokovalo vlákno? A kterej kontinen bys vyhradil pro skladování potřebné RAMky? QByteArray
, imho by nebylo vhodné tuhle třídu používat pro data větší jak INT_MAX
. Ta třída je určená pro nějaký menší buffery (typicky v řádu kilo nebo mega), pomocí kterejch ty data lifruješ někam jinam. Takže z hlediska účelu těchto funkcí/tříd si myslim, že ta volba datovejch typů je celkem v pořádku.
V každým případě ideální programovací platformu nenajdeš. Je potřeba použít nějakou sice nedokonalou, nicméně pro daný účel vhodnou ale oni se rozhodli nepoužívat exceptions a toto je důsledek. Dá se to bez problému přežítStejného cíle se dá dosáhnout použitím maximální unsigned hodnoty jako chybového stavu, jako je to v stl třeba u string::find string::npos apod. Ztratíte tím jednu hodnotu a né polovinu rozsahu, navíc bude hodnota vždy znamenat 'není to tam' i když předáte data o té velikosti. Pokud budete mít řetězec o 8 znacích, nějaký SIZE_MAX bude 8 a SIZE_MAX bude zároveň představovat chybovou hodnotu pro find(), tak můžete hledat v SIZE_MAX velkým bufferu, protože vrácení SIZE_MAX z find je jedna pozice za bufferem, tj. neplatný index. Problém by to představovalo u pcí plnící buffer, kdy prostě ztratím jednu max hodnotu, popř. by mohlo vrácení SIZE_MAX znamenat chybu jen v případě že velikost bufferu byla < SIZE_MAX, popř. velikost byla SIZE_MAX a zároveň je nastaven příznak chyby a tak mi zůstane plný rozsah. V případě zbytečného nevyhýbání se výjimkám to může prostě vracet přečtenou hodnotu, dneska moc programovat bez výjimek nemá smysl, nějaký overhead je minimální.
Zatímco tyto jazyky jsou schopny obstarat automatickou správu objektů na haldě, přístup U++ poskytuje zcela deterministickou, automatickou správu veškeré paměti.
Pojištěnec je plátcem pojistného, pokud a) je zaměstnancem; za zaměstnance se pro účely zdravotního pojištění považuje fyzická osoba, které plynou nebo by měly plynout příjmy ze závislé činnosti nebo funkčních požitků podle zvláštního právního předpisu 1a), s výjimkou 1. osoby, která má pouze příjmy ze závislé činnosti a funkčních požitků, které nejsou předmětem daně nebo jsou od daně osvobozeny, 2. žáka nebo studenta, který má pouze příjmy ze závislé činnosti a funkčních požitků za práci z praktického výcviku, 3. osoby činné na základě dohody o provedení práce, která v kalendářním měsíci nedosáhla příjmu ve výši částky, jež je podmínkou pro účast takové osoby na nemocenském pojištění podle zákona upravujícího nemocenské pojištění (dále jen „započitatelný příjem“), 4. člena družstva, který není v pracovněprávním vztahu k družstvu, ale vykonává pro družstvo práci, za kterou je jím odměňován, a který v kalendářním měsíci nedosáhl započitatelného příjmu, 5. osoby činné na základě dohody o pracovní činnosti, která v kalendářním měsíci nedosáhla započitatelného příjmu, 6. dobrovolného pracovníka pečovatelské služby, který v kalendářním měsíci nedosáhl započitatelného příjmu, 7. člena okrskové volební komise při volbách do Evropského parlamentu, Senátu a zastupitelstev územních samosprávných celků a člena okrskové volební komise a zvláštní okrskové volební komise při volbách do Poslanecké sněmovny a při volbě prezidenta republiky, b) je osobou samostatně výdělečně činnou. Za osoby samostatně výdělečně činné se pro účely zdravotního pojištění považují: 1. osoby podnikající v zemědělství; 1d) 2. osoby provozující živnost;2) 3. osoby provozující podnikání podle zvláštních předpisů;3) 4. osoby vykonávající uměleckou nebo jinou tvůrčí činnost na základě autorskoprávních vztahů,4) s výjimkou činnosti, z níž jsou příjmy podle zvláštního právního předpisu samostatným základem daně z příjmů fyzických osob pro zdanění zvláštní sazbou dan ě 4a); 5. společníci veřejných obchodních společností a komplementáři komanditních společností ;5) 6. osoby vykonávající nezávislé povolání, které není živností ani podnikáním podle zvláštních předpisů; 6) 7. osoby vykonávající činnost mandatáře na základě mandátní smlouvy uzavřené podle obchodního zákoníku,6 a ) pokud tato činnost není považována za zaměstnání podle písmene a) a mandátní smlouva nebyla uzavřena v rámci jiné samostatné výdělečné činnosti, 8. spolupracující osoby osob samostatně výdělečně činných, pokud podle zákona o daních z příjmů lze na ně rozdělovat příjmy dosažené výkonem spolupráce a výdaje vynaložené na jejich dosažení, zajištění a udržení, c) má na území České republiky trvalý pobyt, avšak není uveden pod předchozími písmeny a není za něj plátcem pojistného stát, pokud uvedené skutečnosti trvají po celý kalendářní měsíc.
Zdravotní pojištění zaniká dnem:
c) ukončení trvalého pobytu na území České republiky.
jako produkt pseudo oboru byl k neuživeníNo, mám pocit, že zrovna terapeut na protialkoholní léčbě si v těchto končinách najde uplatnění v jakékoliv době.