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.
18.3.2009 12:59
Amarok | skóre: 33
| blog: blogoblog
18.3.2009 13:21
Jan Drábek | skóre: 41
| blog: Tartar
| Brno
To s tím pádem při savu to je známá a v svn opravená chyba...
I když zatím jsem v tom nic delšího, než sestříhání školní besídky nedělal, při psaní seriálu to padalo jen při ukládání (poté co to uložil) a při vložení efektu Částečné rozmazání.
Jak je už napsáno výše, zřejmě by to chtělo novější verzi. Takže bych namísto hořekování "kdy už to konečně začne pořádně fungovat" raději stáhnul poslední SVN a zkompiloval ji (nejlépe včetně mlt, mlt++ a ffmpeg 5.0). Každopádně i přes občasné výpadky stability je to snad první použitelný stříhací software.
18.3.2009 14:15
lmanik | skóre: 11
| Vracov
18.3.2009 14:50
Amarok | skóre: 33
| blog: blogoblog
18.3.2009 20:36
Kdakel | skóre: 24
| blog: kdakel
| Ostrava
Taky do něj vkladám velké naděje, už velmi dlouho se mi Kdenlive moc zamlouvá, ale pořád jsem měl na něj smůlu, většinou se mi jej nepodařilo ani spustit.. Ale konečně se mi Kdenlive podařilo rozběhat na archlinuxu a zatím jsem nezaznamenal problém...
Takže v tom super modernim prostředí používám MC, alsamixer a podobně 
akorát sem si kvůli tomu rozesral celý gentoo tim že jsem musel odmaskovat KDE 3.5.10 který je fajn a KDE 4,2 který je úplně vymaštěný
aaaale no tak - to je co za hovadina - tak napriklad ja som sa asi pred 2 tyzdnami konecne zbavil co i len naznaku kde3 a qt3 takze teraz som uz cisty kde4 a qt4 a kdenlive mi funguje bajecne.
v KDE 3 se aspon flashe nesekaj.. je to proste nahovno stejne nahovno jako Windows Vista
21.3.2009 15:39
Amarok | skóre: 33
| blog: blogoblog
a nevim kde4 naprazdno zere asi 5% cpu, a ma to nakej problem s grafikou asi nebo nevim proste v kde3 to jde plynule a v kde4 se to hryze at je to jakykoliv video ve flashi...
24.3.2009 10:01
Amarok | skóre: 33
| blog: blogoblog
Pozoruju to i na notebooku, driv pohodka v posteli procesor vecne na nule a ted se porad toci vetracek naplno a ten notebook pálí od toho jak je všechno super grafický flashový a procesor pak je furt aspoň na 50ti, spíš na stu... fakt nahovno kam to smeruje..
24.3.2009 16:16
Amarok | skóre: 33
| blog: blogoblog
25.3.2009 08:29
Amarok | skóre: 33
| blog: blogoblog
25.3.2009 12:08
Amarok | skóre: 33
| blog: blogoblog
22.3.2009 10:49
Jan Drábek | skóre: 41
| blog: Tartar
| Brno
No pokud není zaplý compositing s třeba intelovoskou kartou 
A zkompiloval jste si i vlastní ffmpeg a mlt? Jinak kompilace pouze samotného Kdenlive téměř nemá cenu. Silně doporučuji použít build wizzarda. Ověřte si, že kdenlive skutečně používá nově zkompilované knihovny a ne ty distribuční. Distribuční ffmpeg bývá často silně zastaralý, u ffmpegu půl roku je silná zastaralost, sice se vám to zkompiluje a možná i spustí, ale stabilita bude mizerná.
Mimochodem na Kdenlive + Mlt + Ffmpeg se hezky demonstruje jak NEvyhovuje koncept jediné /usr/lib, jediného úložiště všech knihoven a jejich co možná nejmasivnějšího sdílení. Téměř každá aplikace používající ffmpeg (a není jich málo) potřebuje "svoji" ověřenou verzi, jinak nemusí fungovat správně. Mplayer, Xine i VLC to "vyřešili" tak, že si ffmpeg raději linkují staticky (teda bylo to tak, už jsem dlouho neověřoval). Kdenlive stále linkuje dynamicky, ale je to spíš zdroj potíží než výhod.
Další potíž je v tom, že Kdenlive trpí klasickou "chorobou" aplikací "po přechodu", a myslím tím přechod z KDE3 na KDE4. Jen se věci hezky stabilizovaly v (nevydané) verzi 0.6, už se masivně přepisovalo na 0.7, rozkopalo se i co předtím chodilo. Kromě přechodu na nové UI přepsali i část vnitřností s UI nesouvisejících (když už je jeden v tom přepisování a má kód "otevřený" jak pacienta na operačním stole, láká to k dalším změnám, znám tenhle pocit z vlastní zkušenosti). Trpí tím řada jiných zdařilých aplikací jako Digikam.
Kdenlive vlastně bylo přepsané už dvakrát. Přechod z Pivate na MLT a teď KDE3/Qt3 na KDE4/Qt4
)))
Ani se nemusí linkovat staticky, může i dynamicky, stačí aby linker primárně sosnul knihovnu z privátního adresáře aplikace, ne hned z /usr/lib.
Jediná distribuce která podobný princip razí obecně pro všechny (většinu) aplikací je Gobo linux, měla tu recenzi a nesetkala se zrovna s pozitivním ohlesem.
P.S.: Dynamický loading je lepší, protože knihovnu můžu načíst až když je skutečně potřeba, typicky plugin, ale lze pojmout obecně. Programy pak budou startovat mnohem rychleji.
19.3.2009 21:12
Amarok | skóre: 33
| blog: blogoblog
Správně, ve správné linuxové distribuci si ani nemáte co kompilovat sám. Řada distribucí vás před tím krokem i výrazně varuje. Repozitáře vaší distribuce mají být téměř jediným zdrojem nových balíčků. Kdenlive je bohužel vyjímka, jeho kvalita i v jiných distribucích povážlivě kolísá :( Takže nejen Arch linux. Dost podezírám neodladěné a zastaralé verze distribučního ffmpegu. Kdenlive má docela příjemný GUI (!) builder, tak ho zkuste, zkompiluje vám ffmpeg i mlt. Já jsem autorem původního buidl scriptu, ale už ho podstatně zlepšili a posunuli úplně někam jinam. Mě nezbývá než propagovat jejich práci.
Správně, ve správné linuxové distribuci si ani nemáte co kompilovat sám. Řada distribucí vás před tím krokem i výrazně varuje.To je samozřejmě (minimálně v případě Arch Linuxu) nesmysl. V Archu máte přímo na toto AUR, kde jsou ke stažení PKGBUILDy (obdoba portů z FreeBSD nebo ebuildů z Gentoo) a vytváření balíčků kompilací ze zdrojových kódů je nesmírně jednoduché. I ostatní distribuce mají podobné systémy (jen ne tak jednoduché na používání a přívětivé pro koncové uživatele). To co je špatné (a nikdo soudný by to nedělal) je kompilace a následná manuální instalace pomocí make install (tedy pokud si člověk nechce úmyslně zas*at systém nebo neví co dělá).
Ano v případě "source" distribucí je zdroják a kompilace legální součástí instalace. Měl jsem na mysli binární distribuce. V případě "source"distribucí si neistalujete zdroják ručně, ale s pomocí nějakého instalačního systému, který si mimo jiné pamatuje jak se co instalovalo, umí to bezpečné odinstalovat, hlídá si závislosti a tak. V takovém případě ano.
Binární rpm distribuce mají src.rpm - balíček se zdrojáky včetně předpisu jak zbuildovat a nainstalovat. To je *hádám* obdoba PKGBUILDu. Jenže pokud existuje src.rpm pak je zpravidla i nabízeno i binární rpm. Tohle obstarávají automatické build systémy, hádám i na Archu (Arch je binární distribuce ne?). Já měl na mysli případ, kdy neexistuje src.rpm. Kdy neexistuje předpis jak zbuildovat (.spec soubor u rpm) jaké jsou závislosti, kdy se jedná o v distribuci neexistující aplikaci nebo verzi.
S touto situací jsem se bohužel setkal u všech distribucí kterými jsem prošel :( Uživatel má pak nutkání vrhnout se do ruční kompilace, jen málokdo se pustí do tvorby .spec souboru a jeho zařazení do contrib repozitáře pokud s buildem uspěje.
Díky tomu je téměř pravidlem, že kdykoliv kdokoliv napíše PKGBUILD k čemukoliv, dá ho do AURu k dispozici i pro ostatní.
Takže AUR je něco jako Suse Build Service, možná s tím rozdílem, že AUR je jen pro Arch (jen hádám). Zajímavé by mě srovnání obou systémů.
Má to někde online vyhledávač? Já že bych rovnou prubnul, co je tam za verze kdenlive a ffmpegu, případně dalších oblíbených programů. V nejhorším přímo link do repozitáře?
No napsat samotný rpm spec file technicky náročné není, metasekci zkopírujete, trojici buildovacích příkazů taky rovnou, případně tam jsou stejně znějící makra, potáže snad může dělat jen files sekce, ta trochu zavání magií, ale dá se. Tady obecně problém není. Problém je, že složitější programy zkompilovat zdaleka neobsahuje jen tři příkazy. Musíte dát dokupy requirements, to jak pro source tak pro binární balík, configure může mít hromadu parametrů, občas jsou potřeba patche atd. Aby jste DOBŘE zbuildovali například právě ffmpeg si o tom nejdříve musíte trochu přečíst, rozumět problematice, nejlépe se kolem projektu aktivně nějakou dobu pohybovat.
A to jsem myslel tím, aby si to lidi nebuildovali sami, že zdrojáky nejsou sami o sobě míněny jako "distribuční formát". Program má ve formě balíčku poskytovat distribuce, ta udržuje know how jak zbuildovat.
Co se týče jednoduchosti PKGBUILDů, tak to se opravdu nedá ani náhodou s RPM spec soubory srovnávat. RPM spec soubory odradí spoustu lidí už jen prostým pohledem na ně To je jak srovnávat jednoduchost a krásu BSD-like init skriptů (které mimochodem Arch také používá ) s odpornou hrůzou zvanou SysV init (ty ve skutečnosti také nejsou nijak složité, ale v porovnání s BDS-like init skripty je to prostě odpudivé). Zkrátka pravidlo KISS (Keep It Simple, Stupid), kterého se Arch pevně drží.
A jak je to s tím Suse Build Service? To moc neznám, Suse jsem nikdy nepoužíval. Opravdu funguje stejně jako AUR? Tedy že by to byl veřejný repozitář build skriptů, kam může přispívat naprosto kdokoliv (bez žádného schvalování či tak něco), se systémem hodnocení build skriptů, veřejnými komentáři/diskuzí ke každému build skript, atp.?
to ja bych byl radsi, kdyby lip fungoval sequence editor v Blenderu... na strih videa je taky fajn, ale jeste ma svoje mouchy :)
18.3.2009 14:59
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
Srovnávat Kdenlive a Kino je jako srovnávat betu dejmetomu takového vegasu nebo premiéry. Kino je ale zatí stále nejstabilnější střihačský program pod linuxem. Stříhat na kdenlive delší film než nějakých 20 minut je zatím přecejen riziko.
omlouvám se, vypalo my dokončení věty ...premiéry s windos movie makerem.
Tak jsem to taky myslel. Kino mi opravdu přišlo jako moviemaker pro linux. Kdenlive mi občas po pádu a obnově rozhodí umístění klipů na ose a tak s hodinou a půl záznamů, ze kterech chcete mít půl hodinové video, to udělá svoje. Proto jsem se zatím neodvážil stříhat delší film než 20 min výstupního videa. Jinak si konfortnost programu nemohu vynachválit, ale ta stabilita mi pořád nahání strach.
) - včetně mnoha prolínaček a efektů. A to přitom byla starší verze Kdenlive, tak 2 roky zpátky, ty nejnovější jsou na tom lépe. S Kdenlive se pracuje nesmírně pohodlně, dle mého názoru je na stejné úrovni jako třeba Sony Vegas (který je podle mě - pro mé potřeby - lepší než Adobe Premiere).
S Kinem se Kdenlive nedá srovnávat. Kino je na cokoliv složitějšího než uplně nejprimitivnější střih prakticky nepoužitelné, není to plnohodnotný NLE video editor.
http://www.abclinuxu.cz/blog/Espblog/2006/12/kdenlive-0.4-8211-minirecenze
..srovnával jsem tehdy sice starší verzi Kdenlive ale srovnání s Kinem platí stále (druhá půlka článku).
Stučně řečeno, Kino není pravá NLE střižna, neumí pracovat s několika A/V stopami najednou, umí jen jednu stopu a to ještě dost primitivně, práce s efekty má své zásadní technické limity, musí se aplikovat hned, Kino interně zvládá jediný formát a to DV.
Kino a Kdenlive jsou oba jiná liga. Kdenlive je mnohem starší projekt, dospělejší (maturity), stabilita je někde jinde, některé jednotlivé mini-featury jako stín pod titulky umí jen Kino, ale Kino vyčerpalo možnosti své koncepce.
Kdenlive je koncepčně podobné Cinelerre a Adobe Premierre a má takové ambice, ne tak docela ještě všechny featury a hlavně stabilitu
Pokud chcete něco jednoduše sestříhat, klidně i delšího, jednoduché titulky a vyhodit pár scén, a jeto ve formátu DV, pak je Kino stále tou nejlepší volbou.
Dobrá zpráva je, že autor Kina - Dan Dennedy - se nepřímo s podílí na vývoji Kdenlive! Je autorem páteřní knihovny - MLT a je aktivní na kdenlive-dev mail listu.
Nejstabilnější je asi Avidemux. Kdyby měl časovou osu a scénář, byl by to super program.
Takhle je práce s nim trochu komplikovanější. Alespoň že nepadá.
Avidemux je jiná liga, stejně jako Kino. Avidemux není a nebyl myšlen jako skutečná střižna i když primitivní střih v něm provést lze.
Avidemux je starší a nejdnodušší tool, není divu že je stabilnější. Taky asi nebyl jako Kdenlive dvakrát přepsán (Piave -> MLT a pak KDE3 -> KDE4)
Avidemux doporučuji používat v součinnosti s Kdenlive, jako takový pre a post produkční tool. Například pro A/V synchronizaci.
Nevím jak moc se tomu dá říkat "stříhat" ;) ale Avidemux umí jednoduché vystřižení scény, roztřižení, přilepení jiné a to je asi tak všechno. Má to jakousi jednoduchou časovou osu dole pod obrazovkou. Síla Avidemuxu je hlavně v převodu formátů a filtrech.
). Na něco takového je Kdenlive příslovečný kanón na vrabce.
Prostě najedeš na počáteční pozici, dáš označit začátek, pak na koncovou pozici, dáš označit konec a máš hotovo (ještě to vystřižené video tedy samozřejmě musíš uložit/exportovat, jo a je dobré stříhat ho na klíčových snímcích - na přechod na nejbližší předchozí nebo následující klíčový snímek jsou tam také ikonky).
ale kdeze, bud das save a ulozi ti len oznacenu cast, alebo das DEL a tu cast zmaze a mozes mazat dalej.
luxus diky nekdy to vyzkousim
Kdenlive jsem se pokoušel používat zhruba před rokem. Šlo o větší filmový projekt cca. 40minut. Byla to katastrofa. U linuxu jsem si vždy cenil stability jak systému tak i aplikací. Práce vývojářů zvláště těch dobrovolných si velmi cením, ale to co předvání vývojáři kdenlive je tragédie. Nevím jestli jsem se setkal s jiným sw pod linuxem, který by byl alespoň z poloviny tak nestabilní a nepředvídatelný. Pokud chce člověk nastříhat cokoliv v rozumném čase a kvalitně stále mu nezbývá nic jiného než si pořídit MAC a nebo XP s nějakou střižnou typu Sony Vegas, Premiera, FinalCut. Tipuji, že kdenlive se těmto programům přiblíží tak za 5 let a to jsem obávám se optimista ....
18.3.2009 22:36
lmanik | skóre: 11
| Vracov
19.3.2009 01:54
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
. No asi týden potom sem si reinstalil kompa a až tusím do minulého týdne se mi kdenlive nepovedlo ani spustit, natožpak v něm něco sestříhat. Už se těším až si vněm zase něco udělám.
19.3.2009 08:05
Amarok | skóre: 33
| blog: blogoblog
Obavam se, ze jedinej realne pouzitelnej editor byl Mainactor, ale ten uz bohuzel firma odpiskala...
lol a to sa ako da strihat video ked ho nevidis??? podla zvuku ? :D :D :D
tak u mne je tenhle program stabilnejsi nez cinelerra a i tim gui mi vyhovuje vic. do ted jsem videa strihal na mainactoru, ktery byl suprovy a profi nastroj, ale kdenlive je proste hezci a funkcne se blizi komercnim nastrojum a i na konverzi videa casteji sahnu po kdenlive pred avidemuxem, protoze pro mne ma vystupy s volbami tak nejak lepe udelany v dialogovym okne. musim ale zaklepat a priznam se, ze se mi nechce aktualizovat, aby mi zas nejakou dobu nesel :)
Nemate nekdo zkusenosti se strihem HD videa na tom? zvlaste jak se to chova k ruznym formatum - napr FULL HD v MOV containeru a pak pripadne export na DVD - ale predpokladam ze toto je zalezitost ffmpeg.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz