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 »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.
Tiskni
Sdílej:
Subversion nee ? My to používáme na projekty v práci a doma sem si to nainstaloval taky. Spravuju tak veškerou rozdělanou práci od výkresů v qCADu a Eaglu po zdrojáky v Cčku.
Když jsem naposledy zkoušel SVN, tak si ukládalo všechny soubory z jedné revize do jednoho souboru a že pak byl obrovský... Nevím jestli na velké soubory nebo vůbec velký objem dat vhodné.
cron + rsync vole
Koukni na tohle - backup-manager, ma to i deb balicek. Osobne to pouzivam na geografickou zalohu serveru pres ftp, ale ma to moznosti i pro paleni a vetsi soubory by to melo umet rozdelovat. Pak uz jen do crontabu pridas kdy chces zalohovat a menis placky, nebo pustis rucne.
PS. bohuzel to nema gui, ale myslim, ze udelat ikonku pro BFU, ktera spusti program neni takovy problem...
Abych řekl pravdu, dodnes jsem nepochopil požadavky ve stylu (už v minulosti v podobném stylu vznesené):
Aplikace bude naprogramovaná v C++.
S použitím Qt4.
Využívat GNU nástroje (důvod?)
Takhle vymrčovat někoho jsem zažil někoho akorát jednou v životě. Upřímně pokud programování nerozumíte (protože danou aplikaci není složité naprogramovat), tak tyto požadavky pro Vás nemají jinou cenu, než jako fanda daných nástrojů. Pak ovšem tvrdě zvedněte nabídku ceny, pokud máte další speciální požadavky, než na funkčnost, spolehlivost, atd..
P.S.: Mimochodem, já bych u zálohování kladl důraz hlavně na spolehlivost. A Qt je knihovna, kterou v takových případech nepoužívám. Qt má pro řadu metod, které mohou selhat void návratovou hodnotu a vzhledem k tomu, že výjimky nepoužívá (alespoň v té době, co jsem se s Qt naposledy setkal), tak není jak by se programátor o chybě vůbec dozvěděl. Nicméně pokud Qt bude dělat jenom GUI a ne vlastní funkčnost, nemusí to samozřejmě vůbec vadit a pak je Qt klidně na místě.
A to, že by Qt nepoužívalo výjimky se mi fakt nějak nezdá.Nepoužívá. Tvůj program je používat může, ale Qt samo o sobě výjimky nevyhazuje. Abych pravdu řekl, nepřijde mi to jako problém.
„Abych pravdu řekl, nepřijde mi to jako problém.“
Abych řekl pravdu, ani mě ne. Nicméně programování s výjimkami:
1) Je efektivnější – což ale většině lidí nepřijde, protože obecně tak jako tak kašlou na dobré ošetřování chyb. Pokud budete skutečně důsledně ošetřovat všechny chyby, které mohou vzniknout po každém volání, či obecně akci, která může skončit chybou – tak velmi rychle se utopíte v hromě kódu, a velmi rychle začnete výjimky preferovat.
2) Nemůžete je ignorovat – zatímco na návratovou hodnotu se dá kašlat, výjimky donutí chybu ošetřit. Neošetřená výjimka ukončí program. Pokud tedy programátor není prase. Právě tento bod 2) je největším trnem v oku proti výjimkám – neumožňuje vykašlat se na ošetřování chyb – což je častá praktika řady lidí.
3) Ošetříte i věci, které rozumně bez výjimek ošetřit nejdou – chyba hw, segfault, konec místa na zásobníku – to se velmi těžko cpe do návratových hodnot. A „emulace“ zvaná signály je velmi dřevěná a neelegantní.
4) Kód je mnohonásobně čitelnější, protože zmizí les kódu, který obklopuje každou akci a ošetřuje vše, co se dá.
Pokud něco nevyhazuje výjimky, pak je třeba nabídnout jiný způsob ošetřování chyb – a zaintegrovat to do rozhraní. A nejsem si jistý, jestli to vůbec jde udělat důsledně, a u Qt mě překvapilo, že občas chybová informace není k dispozici ani tam, kde by chyba mohla nastat.
Je efektivnější – což ale většině lidí nepřijde, protože obecně tak jako tak kašlou na dobré ošetřování chyb.Na druhou stranu výjimky jako takové přidají spoustu kódu a samy moc efektivní nejsou, protože při překladu se do výsledné binárky stejně umístí spousta testů na chybu/výjimku a případných skoků (aspoň si to myslím, nenapadá mě jiný způsob, jak výjimky udělat)
Ošetříte i věci, které rozumně bez výjimek ošetřit nejdou – chyba hw, segfault, konec místa na zásobníkuAbych pravdu řekl, přijde mi, že kromě velmi výjimečných případů je vcelku zbytečné něco takového ošetřovat. Segfault je úplně mimo, když dojde k segfaultu, tak k chyba je jinde. Chyba HW stejně dřív či později způsobí, že program spadne atd.
Kód je mnohonásobně čitelnější, protože zmizí les kódu, který obklopuje každou akci a ošetřuje vše, co se dá.Neřekl bych. Jednak není moc akcí, které by mohly selhat více způsoby. Druhak mě občas ani nemusí zajímat, kvůli čemu akce selhala, prostě selhala a s tím je potřeba se nějak vyrovnat. (A důvod třeba poslat jako kód někam do logu) A navíc - když už výjimky, pak by se taky hodilo klíčové slovo
finally
, které označí kód, který se musí provést vždy i při vyhození výjimky a nestandardním opuštěním funkce. Bez finally je totiž nutné všechny možné výjimky ošetřit v každé funkci, kudy výjimka může projít a kde je v takovém případě potřeba udělat nějaký úklid.
V takovém případě se ovšem výjimky dostvájí na stejnou úroveň jako ruční ošetřování chyb.
u Qt mě překvapilo, že občas chybová informace není k dispozici ani tam, kde by chyba mohla nastat.Příklad?
P.S.: Mimochodem, já bych u zálohování kladl důraz hlavně na spolehlivost. A Qt je knihovna, kterou v takových případech nepoužívám. Qt má pro řadu metod, které mohou selhat void návratovou hodnotu a vzhledem k tomu, že výjimky nepoužívá (alespoň v té době, co jsem se s Qt naposledy setkal), tak není jak by se programátor o chybě vůbec dozvěděl. Nicméně pokud Qt bude dělat jenom GUI a ne vlastní funkčnost, nemusí to samozřejmě vůbec vadit a pak je Qt klidně na místě.klasicky zábavné. Tak se, doboha, na to zase jednou podívej. Výjimky použít můžeš, dokonce máš hromadu metod lastError, isValid atd.
mam otazku k tovu Vasemu toolu ohledne sqlite. Mam tu SQlite-DB , t.zn. ten soubor na linuxu a chtel jsem z windows pres sit trochu administrovat tu db. Ale dela to na me dojem, ze si mohu vybrat jen lokalni soubor. Je to tak? Je to mozno rozsirit i na sit?
to je samozrejme smutna zprava, jako admin (byvaly, aktualni ?) jiste vite, jake to je kvuli kdejakemu souboru uvolnovat dalsi slozky napr. pres sambu - navic pro vice uzivatelu - ale co se da delat.
Sem se ale podival na ten ODBC driver a ten je take takovy 'lokalni' - takze to byla spise moje chybna predstava, jak je ta sqlite koncipovana. Myslel jsem si (nebo mi dneska vlastne ani neprislo na mysl), ze by sqlite nemela nejaky demon, ktery by cekal na dotazy pres sit. Takze v tom pripade se ani nedivim, ze v tom nevidite prioritu.
Nebo jsem neco prehledl?
P.S.
Ze zoufalstvi instaluji FB 1.5 v embedded verzi na linuxu. Taky alchymie - nebejt toho Rusa, co aspon popsal jak na to , tak snad neni zadna embedded db.
http://sqlite.org/serverless.htmlSem se ale podival na ten ODBC driver a ten je take takovy 'lokalni' - takze to byla spise moje chybna predstava, jak je ta sqlite koncipovana. Myslel jsem si (nebo mi dneska vlastne ani neprislo na mysl), ze by sqlite nemela nejaky demon, ktery by cekal na dotazy pres sit. Takze v tom pripade se ani nedivim, ze v tom nevidite prioritu.
sqlite je embedded databáze, tedy databáze, která není určena k práci přes síť
při práci přes síť se pak dostáváte do souborových prací, a to není vždy dobře
pro sqlite existuje projekt, který umožňuje z sqlite udělat klasickou server/client dbms
a ohledně odbc – to bych u sqlite nezkoušel, neboť to je hodně nefunkční driver
Klasicky zábavné. Jsi si jist, že všechny akce, které mohou v Qt způsobit chybu lze tu chybu lokalizovat? To, že některé třídy mají metody lastError, nebo isValid nic nemění.
Navíc osobně bych raději viděl objekt vyhodit výjimku, než neustále předpokládat, že libovolný objekt může být nevalidní.
Každému programátorovi doporučuji jednou si zkusit napsat středně velký projekt, kde by opravdu důsledně ošetřovali a reagovali na všechny chyby, které v každé akci mohou nastat a nic nevynechali. Doporučuji to zkusit nejdřív bez výjimek a totéž pak s výjimkami. Rozdíl bude tak markantní, až to hezké nebude. Kód bez výjimek bude už téměř neudržovatelný a místy až nečitelný. Navíc kód s výijmkami bude výrazně rychlejší, protože běžný běh programu nebudou brzdit žádné testy typu „if return_value …“, „if object.isValid()“, „if object.lastError“ a řada dalších, nic z toho se s výjimkami vykonávat nebude. Pokud budete důsledně ošetřovat každu chybu.
rad bych na Vasem prispevku poukazal na jednu zasadni vec.
Soucasny vyvoj smeruje stale vice k 'monopolnimu' stavu ve spolecnosti. Je stale obtiznejsi obstat v konkurenci, protoze mala firma natoz freelancer nemuze nabidnout ten 'power' - uz i mensi zakaznici se ohlizi po tech velkych 'hracich' na trhu. A ti velci 'hraci' tomu pomahaji temi lite, small, express edicemi svych produktu.
Teto nadvlade byrokracie je mozno se oprit budto projevy z Hradu a nebo kooperaci tech mensich. Vidim napr. i zde na abc radu kolegu, kteri jsou na volne noze a maji sice dnes jeste zakazky ale zitra to bude mozna horsi. Pan Zima, Vy, mozna brzy s0 a dalsi by byli s to spolecne udelat treba ten 'stredni' projekt, o kterem pisete. Na cem by to zkrachovalo?
Uz na tom, ze Vy jako jediny vite, co je spravne. s0 to vi take, ale Vase nazory jsou rozdilne. A to nejde ani o ten ton v tech vypovedich. Uz v zasade vidim diametralni rozdily v nahledu na tvorbu software. A timhle si curame vsichni vzajemne na nohy a posilujeme m$, byrokracii nejen v EU a vznik zoufaleho software, s kterym nasi spoluobcane musi denne zapasit.
akce, které způsobí chybu snad působí kodér, takže je na něm, aby si to kontroloval, ne? Navíc si myslím, že uvedené metody (bnebo jiné testovací mechanismy) jsou dostupné u všech Qt objektů/tříd, kde jsou potřeba (jasně, třeba jsem něco vynechal, protože jsem to dlouho nepoužil). U ostatního už to ohlídá třeba Property System. Ale je opravdu možné, že si jen nerozumíme.Klasicky zábavné. Jsi si jist, že všechny akce, které mohou v Qt způsobit chybu lze tu chybu lokalizovat? To, že některé třídy mají metody lastError, nebo isValid nic nemění.
Každému programátorovi doporučuji jednou si zkusit napsat středně velký projekt, kde by opravdu důsledně ošetřovali a reagovali na všechny chyby, které v každé akci mohou nastat a nic nevynechali. Doporučuji to zkusit nejdřív bez výjimek a totéž pak s výjimkami. Rozdíl bude tak markantní, až to hezké nebude. Kód bez výjimek bude už téměř neudržovatelný a místy až nečitelný. Navíc kód s výijmkami bude výrazně rychlejší, protože běžný běh programu nebudou brzdit žádné testy typu „if return_value …“, „if object.isValid()“, „if object.lastError“ a řada dalších, nic z toho se s výjimkami vykonávat nebude. Pokud budete důsledně ošetřovat každu chybu.
Já naopak každému programátorovi doporučuji, ať se začne živit nečím "poctivým", protože taková práce přece nikoho nemůže bavit dlouhodobě ;) Konec OT.
Důkladně rozpracované výjimky mají jednu zásadní nevýhodu. Jestliže se bavíme o středně velkém projektu (to je definováno jak? Vezmu tedy to, co si myslím, že je "střední"), tak není v možnostech ohlídat všechny možné kombinace vnitřních stavů a podle toho vyhazovat jednu z 308 miliard výjimek. A ač to vypadá z hlediska školského programování nechutně, tak je v reálu nutná jistá zdrženlivost, protože se jinak vývojář zblázní. Navíc hrozí nebezpečí, že se stejně použije univerzální odchycení všech výjimek, které jsou pak ideálně zahozeny.
Prostě jako v životě - hlavně u toho myslet, a pak teprve odsuzovat.
Máš tomu především rozumět tak, že je mi už podezřelé, že už po x–té hledáš na abclinuxu další a další zálohovací tool.
Také je mi podezřelé, že si tam nasázíš dost tvrdé podmínky, kdo a co smí k čemu použít. Jaký jazyk, nástroje, …
Vlastně tak trochu přemýšlím, jestli by pro Tebe nebylo lepší nějak generalizovat a shrnout co vlastně potřebuješ. A podmínky nechat ve stylu „chci výsledný kód jako open source pod GPL, chci běh na této a této distribuci, chci takové a takové uživatelské ovládání“
Nechápu jak si mužeš klást podmínky kdžy ti za to nabízím prachy... to protě nepochopímAha, takže ty nabízíš prachy a já jsem kvůli tomu tvoje děvka která nemůže říct ani slovo?
rad vysvetlim, pan Vanek narazi na lidi jako pan Smolik, JiK, Strider a ostatni, kteri jenom zvani a za praci vzit neumi. Takovi lide samozrejme i v dobe krize nic neudelaji, jak take, kde nic ani cert nebere.