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.
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 »
Tiskni
Sdílej:
28.4.2012 00:32
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
V zavislosti od velkosti banky zavisi, ako dlho bezi.Um, prečo to v dnešnej dobe (*) trvá dlhšie ako 5 minút? *) banka si určite dokáže zaplatiť N jadrový stroj s haldou pamäte, SSD diskom, optickou sieťou atď atď, skrátka delo. P.S.: to isté by ma zaujímalo v prípadoch ako sú valorizácie dôchodkov a podobné operácie.
28.4.2012 11:38
houska | skóre: 41
| blog: HW
V bance tohle dělá mainframe od IBMTo ja vlastne asi pravda. Nič to ale nemení na tom, že nechápem prečo by spracovanie dát malo trvať tak dlho, ako banka tvrdí, že trvá.
28.4.2012 13:50
xkucf03 | skóre: 49
| blog: xkucf03
V bance tohle dělá mainframe od IBMJak v které
29.4.2012 01:01
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
29.4.2012 09:36
xkucf03 | skóre: 49
| blog: xkucf03
Um, prečo to v dnešnej dobe (*) trvá dlhšie ako 5 minút?protože clearing ... bavíme se stále v kontextu posílání peněz do jiné banky, že?
*) banka si určite dokáže zaplatiť N jadrový stroj s haldou pamäte, SSD diskom, optickou sieťou atď atď, skrátka delo.LOL, představa nadupaného PCčka mě opravdu pobavila ...
LOL, představa nadupaného PCčka mě opravdu pobavila ...Chápem, že ti to môže pripadať vtipné. Ha ha.Takže bankový sektor je iná liga, že? Kam sa hrabe nadupané PCčko. A napriek tomu, spracovanie trvá deň?
protože clearingPojem "clearing" mi je viac-menej jasný. Vieš moje obzory rozšíriť a objasniť, čo na tom clearingu toľko trvá?
A napriek tomu, spracovanie trvá deň?S tímhle sentimentem souhlasím. Banky mají superhustý mainframy a fungují zoufale blbě, protože šetří na infrastruktuře a programátorech. Ne lidi, kteří by ty systémy provozovaly na obyčejném počítači, jsou k smíchu, ale banky jsou k smíchu. Těch dat skutečně není tolik, ty operace nejsou zas tak těžké a zajistit absolutní spolehlivost je věc programu, který si bude data průběžně odkládat někam co nejdál -- mainframe se při povodních chová podobně špatně, jako ten nejlevnější notebook.
Pojem "clearing" mi je viac-menej jasný. Vieš moje obzory rozšíriť a objasniť, čo na tom clearingu toľko trvá?Je to historická záležitost, tj. důvod je, aby banky nemusely urovnávat každou transakci, dělají to po várkách, které kdysi dávno bylo jednodušší zpracovávat. Takže čím déle se čeká na vyrovnání, tím víc je to jakoby výhodnější z pohledu nějakých těch pitomců, kteří si nevšimli, že existují počítače a internet. Další důvod může být regulatorní, tím si ale nejsem úplně jistý. ČNB chce vědět, kolik je kde peněz, aby věděla, jestli banky splňují podmínky, ale nevím, jestli k tomuhle sledování nějak využívá to clearingové centrum.
ale prdlačky, nějaký kydy o výpočetním výkonu jsou pikatchovina, tady se fakt nebavíme o burzách, kde sejde na každý nanosekundě kdybyste si pánové aspoň přečetli wiki ... "Hlavním rysem moderních mainframů není v první řadě výpočetní rychlost, ale spíše redundantní vnitřní návrh, který přináší vysokou spolehlivost, bezpečnost, široké možnosti připojení vstupně-výstupních zařízení, vysokou zpětnou kompatibilitu a schopnost práce s vysokou zátěží a masivní propustností."A napriek tomu, spracovanie trvá deň?S tímhle sentimentem souhlasím. Banky mají superhustý mainframy a fungují zoufale blbě,
protože šetří na infrastruktuře a programátorech.... jistě, a proto se práce pro banky v IT má za zlatej důl
Těch dat skutečně není tolik, ty operace nejsou zas tak těžké a zajistit absolutní spolehlivost je věc programu, který si bude data průběžně odkládat někam co nejdál -- mainframe se při povodních chová podobně špatně, jako ten nejlevnější notebook.dobře, jdeme kousek dál než na wiki takže ... mluvíš o povodni světa? - no, pochybuju, že Noemovi by ty virtuální peníze k něčemu byly, takže asi ne ... v tom případě umí tvůj nejlevnější notebook přemigrovat běžící úlohu do jinýho výpočetního centra, jakmile hrozí, že k němu dostoupá voda, a po opadnutí vody a výměně slabších kousků hw, co neuměly plavat, si tutéž úlohu zase vzít zpátky? "mainframe" totiž dneska není jenom jedna velká krabice s vlastní elektrárnou, to je i o rozházení týhle "krabice" různě po světě tak, aby se furt virtuálně tvářila jako jedna a ta samá krabice samozřejmě teda záleží, co si zákazník přeje a zaplatí ... jo ještě k tomu "absolutní spolehlivost je věc programu" - hm, a jak ten program sám o sobě pozná hardwarovou chybu, případně jak si poradí, když pod ním ten hardware umře úplně? - tady můžu opět odkázat na wiki, aspoň na anglické je o tom pár slov: Mainframes also have execution integrity characteristics for fault tolerant computing. For example, z900, z990, System z9, and System z10 servers effectively execute result-oriented instructions twice, compare results, arbitrate between any differences (through instruction retry and failure isolation), then shift workloads "in flight" to functioning processors, including spares, without any impact to operating systems, applications, or users.
ti pitomci si toho zajisté všimli, nicméně tak mě napadá ... neplatí se za tu službu náhodou něco? - není potom výhodnější zaplatit za jedno použití denně, nežli za několik tisíc každou sekundu?Pojem "clearing" mi je viac-menej jasný. Vieš moje obzory rozšíriť a objasniť, čo na tom clearingu toľko trvá?Je to historická záležitost, tj. důvod je, aby banky nemusely urovnávat každou transakci, dělají to po várkách, které kdysi dávno bylo jednodušší zpracovávat. Takže čím déle se čeká na vyrovnání, tím víc je to jakoby výhodnější z pohledu nějakých těch pitomců, kteří si nevšimli, že existují počítače a internet.
v tom případě umí tvůj nejlevnější notebook přemigrovat běžící úlohu do jinýho výpočetního centra, jakmile hrozí, že k němu dostoupá voda, a po opadnutí vody a výměně slabších kousků hw, co neuměly plavat, si tutéž úlohu zase vzít zpátky?A od kdy tohle IBM mainframe umí?
"mainframe" totiž dneska není jenom jedna velká krabice s vlastní elektrárnou, to je i o rozházení týhle "krabice" různě po světě tak, aby se furt virtuálně tvářila jako jedna a ta samá krabiceNo jasně, a ty data růzě po světě replikuješ synchronně prostřednictvím kvantového zavěšení, viď?
jo ještě k tomu "absolutní spolehlivost je věc programu" - hm, a jak ten program sám o sobě pozná hardwarovou chybu, případně jak si poradí, když pod ním ten hardware umře úplně?Například ve VMware prostředí pomocí FT.
hm, měl jsem zato, že od dob, kdy je začalo dělat modulárně, čili tak někdy od konce sedmdesátých let? - nevím, není to můj obor, použij Google ...v tom případě umí tvůj nejlevnější notebook přemigrovat běžící úlohu do jinýho výpočetního centra, jakmile hrozí, že k němu dostoupá voda, a po opadnutí vody a výměně slabších kousků hw, co neuměly plavat, si tutéž úlohu zase vzít zpátky?A od kdy tohle IBM mainframe umí?
kdo říká že synchronně? - například u IBM GDPS/active-active mluví o nějakých sekundách ..."mainframe" totiž dneska není jenom jedna velká krabice s vlastní elektrárnou, to je i o rozházení týhle "krabice" různě po světě tak, aby se furt virtuálně tvářila jako jedna a ta samá krabiceNo jasně, a ty data růzě po světě replikuješ synchronně prostřednictvím kvantového zavěšení, viď?
čti pořádně: "jak ten program sám o sobě pozná hardwarovou chybu, případně jak si poradí, když pod ním ten hardware umře úplně?" - s VMWare FT do toho už taháš další program a další hardware ...jo ještě k tomu "absolutní spolehlivost je věc programu" - hm, a jak ten program sám o sobě pozná hardwarovou chybu, případně jak si poradí, když pod ním ten hardware umře úplně?Například ve VMware prostředí pomocí FT.
zpracování čeho konkrétně podle tebe trvá den? - dojde mi telefonní kredit, někam nabuším pár čísel, přijdu o nějaký peníze z účtu, a obratem můžu volat dál (přičemž "obratem" je tak asi zhruba než se mi v browseru načte další stránka) ... napříkladLOL, představa nadupaného PCčka mě opravdu pobavila ...Chápem, že ti to môže pripadať vtipné. Ha ha.Takže bankový sektor je iná liga, že? Kam sa hrabe nadupané PCčko. A napriek tomu, spracovanie trvá deň?
nejsem zaměstnanec ČNB, případně banky, co s tím má co do činění, takže ti obzory příliš nerozšířím, notabene když je ti všechno jasné :-p každopádně řekl bych, že důvody jsou spíše "politické" než technické například to, že o víkendech/svátcích normální platby nechodí, zcela jistě nebude způsobeno pomalostí počítačů ...protože clearingPojem "clearing" mi je viac-menej jasný. Vieš moje obzory rozšíriť a objasniť, čo na tom clearingu toľko trvá?
29.4.2012 07:41
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
například to, že o víkendech/svátcích normální platby nechodí, zcela jistě nebude způsobeno pomalostí počítačů ...Přesně, nad tím jsem se už několikrát pozastavoval. Ještě podivnější bylo (když jsem byl ještě u raifky), že jsem třeba zadal platbu o víkendu, jako datum splatnosti jsem byl nucen zadat pondělí, ale světe div se, platba (na jiný účet v raifce) se provedla v neděli odpoledne. Přišel jsem na to náhodou, když jsem si zaplatil VIP u jabbimu a v neděli odpoledne jsem nečekaně obdržel zprávu, že VIP účet byl aktivován. Později jsem si to ještě několikrát ověřil. Buď to bylo klamání spotřebitele (datum splatnosti nelze zadat o víkendu) nebo dost nepříjemná chyba v jejich SW (zadám platbu na pondělí, v neděli večer ji chci zrušit a ono to už nejde).
nejsem zaměstnanec ČNB, případně banky, co s tím má co do činění, takže ti obzory příliš nerozšířím, notabene když je ti všechno jasné :-p každopádně řekl bych, že důvody jsou spíše "politické" než technickéO vnitrnim procesnim fungovani bank taky mnoho nevim, ale napada mne, zda to neni zpusobene proste tim, ze banka na realizaci tech prevodu musi sehnat rezervy a pripadne taky musi dojit k prevodu nejakych aktiv. Tipoval bych, ze obvykle to neni problem a ty prevody se vyridi v ramci 'polstare' z povinnych minimalnich rezerv, ale pokud by dany den bylo hodne neocekavanych odchozich plateb a malo prichozich, pak by rozdil mohl prekrocit drzene rezervy a pak nekdo musi rozhodnout, kde likviditu potrebnou na realizaci odchozich plateb sehnat - pujcit od centralni banky, pujcit na mezibank. trhu, prodat nejaka nelikvidni aktiva.
Což je samozřejmě věc, která se může stát. Absolutní spolehlivost je jen výmluva, kterou si špatně placení programátoři velkých bank omlouvají svoji lenost.
28.4.2012 19:17
xkucf03 | skóre: 49
| blog: xkucf03
Ale nakonec to nějak vymysleli a funguje jim to.To je ale trochu jiná liga – v případě Twitteru, Facebooku, Google Map, Google vyhledávání atd. nevadí, když se občas něco vysere – nějaká data se ztratí nebo zdvojí, nebo se něco zpozdí (třeba jeden uživatel vloží komentář a ostatní ho vidí až za chvíli), nehraje se tu na přesný výsledek.
Bohvie, či to bol pôvodný plán, ale mapové API od googlu bolo pred pár mesiacmi spoplatnené (cenník, príklad prebehlíkov)...
...
29.4.2012 07:45
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
V kazdej banke v noci bezi denna uzavierka. V zavislosti od velkosti banky zavisi, ako dlho bezi. Preto ked robite prikazy vecer vecer, spracuju sa az nasledujuci den.A co je mi do toho? Ať mi tam napíšou obě data, jak stržení z mého účtu, tak připsání na příjemcův (to musí být v ČR tentýž den, jako vlastní převedení peněz mezi bankami, tudíž se to zjednodušuje na datum stržení z účtu a datum odeslání do příjemcovy banky).
28.4.2012 12:30
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
28.4.2012 15:33
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Keď človek potrebuje rýchlo poslať niekam peniaze, tak ho môže hodiť o zem. Ale vidieť, na čom im záleží, keď potrebujem pôžičku, tak mi len na základe príjmov bez všetkého aktivujú povolené prečerpanie, ale keď niečo skutočne potrebujem, tak je to jak sto rokov za opicami.
A to po těch bankách ani nechci, aby využily možnosti počítačů třeba k "otagování" peněz stylem rezervuj tolik a tolik z výplaty na tato a tato inkasa apod...zrovna tohlento se dá ale docela jednoduše obejít - založím další účet, kam si příslušný díl výplaty nechám převést, a z toho pak inkasa platím
Zadruhé je to různý význam termínu "datum splatnosti" z pohledu banky a toho, komu platím. Proč to nemůže být sjednoceno, ať to znamená totéž, nebo rozděleno do dvou různých termínů?
Odesílající banka nemůže principiálně ovlivnit to, kdy se peníze objeví na účtu příjemce. Může ovlivnit pouze to, kdy je odepíše z vašeho účtu a předá do clearingu. Teoreticky by sice bylo možné udělat to, že když zadáte splatnost, peníze se odešlou v takovém termínu, aby i při maximální zákonem povolené délce převodu byly na účtu příjemce včas, ale to by se zase nehodilo v jiných situacích (např. pokud potřebujete platbu odeslat, jakmile vám přijde platba od někoho jiného).
Na druhé straně příjemce platby nemůže zjistit, kdy jste peníze z účtu odeslal, takže on může kontrolovat pouze to, kdy se platba objevila u něj. Je tedy logické, že z jeho pohledu je splatnost deadline pro přijetí platby na jeho účet.
Mezi námi, současné úrokové sazby na běžných účtech jsou tak nízké, že odesláním platby o pár dnů dřív o žádnou závratnou částku nepřijdete, takže nevidím důvod, proč se snažit splatnost faktur šponovat na doraz.
Zatřetí, když zadávám trvalý příkaz se splatností na začátku měsíce, vyloženě bych uvítal možnost zadat "datum připsání na účet příjemce" - tedy splatnost z pohledu příjemce. On je to celkem podstatný rozdíl, když člověk musí počítat s čtyřdenním rozptylem v datu odeslání.
Stejný problém jako výše. Dokud bude existovat systém clearingu v současné podobě, tak tohle prostě už z principu zařídit nejde.
28.4.2012 13:49
xkucf03 | skóre: 49
| blog: xkucf03
Dokud bude existovat systém clearingu v současné podobě, tak tohle prostě už z principu zařídit nejde.Už si to říkám delší dobu – nějaká strana by si mohla dát do programu, že vytvoří prostředí, ve kterém bude možné provádět mezibankovní převody v řádu minut. Dost by to pomohlo podnikání v ČR a posunulo nás to dál.
Mezi námi, současné úrokové sazby na běžných účtech jsou tak nízké, že odesláním platby o pár dnů dřív o žádnou závratnou částku nepřijdete, takže nevidím důvod, proč se snažit splatnost faktur šponovat na doraz.ten důvod je návaznost plateb - nelze odeslat peníze dříve než přijdou ... resp. tedy bylo by možno držet si preventivně zůstatek ve výši odpovídající odchozím platbám, ale pak se nebavíme o "pár dnů dřív", nýbrž o "furt", a tam ten rozdíl už může být docela zajímavý (peníze nejsou investovány jinde, nejde o úrok na běžném účtu, ale o to, co by mohly vydělat, kdyby byly někde jinde než na běžném účtu)
ten důvod je návaznost plateb - nelze odeslat peníze dříve než přijdou
To je ale právě důvod spíš pro to, abych zadával datum, kdy má platba odejít.
ehm, bavíme se o dopravním prostředku anebo o hospodářském zvířeti? pokud Dejva správně chápu, jeho při platbě zajímá především datum, kdy bude platba připsána příjemci Vy mu navrhujete workaround, aby to neřešil a zaplatil dříve, čímž zajistí, aby příjemci přišla platba včas jenomže aby pokryl různé krátké měsíce, svátky, výluky a jánevímco, musela by ten předstih být asi tak o týden ovšem co když mu peníze, ze kterých chce platit, chodí méně než týden před datem, kdy mají být zase někde jinde? - jak mu v tomto pomůže zadání data, kdy má platba odejít, jestliže to datum je příliš brzy? nebylo by v tom případě lepší právě aby zadával datum, kdy má platba příjemci přijít, a systém automaticky vyřešil nejpozdější možný termín, kdy platbu odeslat, což by v 99% případů splnilo návaznost, a v tom 1% by si to Dejv vyřešil jinak, buď včasným převedením peněz z jiného zdroje, nebo prostě zaplacením penále z prodlení, které nejspíše bude nižší, než nechat peníze ležet pořád na účtě neúročené, nevydělávající, jen jako rezervu pro včasný převod?ten důvod je návaznost plateb - nelze odeslat peníze dříve než přijdouTo je ale právě důvod spíš pro to, abych zadával datum, kdy má platba odejít.
Bavíme se o tom, že pokud potřebuju platbu odeslat až poté, co mi přijde jiná, pak řešením rozhodně není to, že místo data odeslání budu zadávat datum, kdy má být platba na účtu příjemce. Pokud ta příchozí platba přijde dostatečně včas na to, aby se stihla splatnost té druhé, pak nic nezkazím tím, že tu druhou odešlu, jakmile ta první přijde (nebo s rozumným předstihem, pokud je ten interval dlouhý). Pokud včas nepřijde, pak s tím stejně nic nenadělám a tím, že odešlu druhou platbu, jakmile přijde první, aspoň minimalizuji zpoždění.
Ano, bylo by skvělé, kdyby převod mezi bankami mohl trvat pár sekund nebo aspoň hodin. Stejně tak by bylo skvělé, kdyby litr benzínu nestál víc než 30 Kč. A oboje je asi tak stejně reálné v dohledné době očekávat.
Ano, bylo by skvělé, kdyby převod mezi bankami mohl trvat pár sekund nebo aspoň hodin.To mě netrápí. Točí mě nepružnost okolo pravidelných plateb - může mi vyhovovat zadání platby jak podle data odeslání, tak podle data clearingu.
Bavíme se o tom, že pokud potřebuju platbu odeslat až poté, co mi přijde jiná, pak řešením rozhodně není to, že místo data odeslání budu zadávat datum, kdy má být platba na účtu příjemce.Jo, správně by bylo zadat v bankovnicví událost "mzda", která by spustila trvalé příkazy (a v případě, že by nenastala do n-tého dne by se poslal varovný email/SMS). Nicméně to je mnohem více nové funkcionality než to, co jsem psal v blogu
Odesílající banka nemůže principiálně ovlivnit to, kdy se peníze objeví na účtu příjemce.Přijímající banka musí připsat peníze na účet příjemce neprodleně, prakticky v den clearingu.
ale to by se zase nehodilo v jiných situacích (např. pokud potřebujete platbu odeslat, jakmile vám přijde platba od někoho jiného).Co brání tomu, aby tam byla obě data a člověk nastavil to, které mu v daném případě více vyhovuje?
28.4.2012 13:46
xkucf03 | skóre: 49
| blog: xkucf03
Zatřetí, když zadávám trvalý příkaz se splatností na začátku měsíce, vyloženě bych uvítal možnost zadat "datum připsání na účet příjemce" - tedy splatnost z pohledu příjemce.A z čeho to ta banka má asi vyvěštit, když připsání na účet příjemce nezávisí jen na ní? (leda při převodu v rámci jedné banky, ale ten je většinou okamžitý)
28.4.2012 15:31
Nicky726 | skóre: 56
| blog: Nicky726
2.5.2012 16:26
Josef Kufner | skóre: 70
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
28.4.2012 12:44
4.5.2012 23:57