Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
ak by si svoj projekt nevydal ako open source len ťažko môžeš začleňovať open source projekty iných do toho svôjho
Tohle záleží na spíše licenci.
ad 1) Jasně, může si to opravit pro sebe (jak psal Leoš), ale vývojář ten zaslaný patch stejně tak jako tak musí zkontrolovat.
Staci, aby se ten projekt prestal rozvijet a pokud v nem nevidis budoucnost, musis investovat do migrace na jiny projektV mnoha pripadech to neni problem - pokud je jasne dany smysl programu (ktery se v case moc nemeni), program je uz v dostatecne finalni fazi, tak program neni treba dal rozvijet a staci pouze upravovat nalezene bugy, coz zvladne kdekdo. Naopak, pokud program dobre splnuje me pozadavky, tak jsem vetsinou radsi, kdyz uz se moc nerozviji, nebot casto takyvy rozvoj me uz nic neprinasi (program splnuje dalsi a dalsi pozadavky, ktere ale ja nekladu) a prinasi komplikace (rust nabubrenosti, zmeny, mensi stabilita).
Pokud něco uvolním jako OpenSource, kdokoliv to může z principu věci okopírovat a vydávat za své dílo.Pozor, to teda ne. Korektní přiznání autorství je nutnost a ani nejliberálnější opensource licence z tohoto požadavku neslevují.
Mnohdy je rychlejší napsat požadovanou funkcionalitu sám, než se prodírat cizím patchem (který se obvykle nedrží nastolené štábní kultury)V takovym pripade bych bez kompromisu zavrel editor a poslal autorovi, at si to hezky opravi... Takze prodirani kodem bez pozadovane stabni kultury by se nekonalo
Ja jsem v podstate jeste zadny kod jako F/OSS neuvolnil, i kdyz se mam na disku nekolik nastroju, o kterych si uz dlouho rikam, ze tohle urcite jednou udelam jako F/OSS
Ono to zni jednoduse, ale nejaky cas to chce... projet veskere zdrojaky a ujistit se, ze kazda trida a metoda je dobre anglicky okomentovana, udelat web/wiki, naplnit daty, napsat tutorialy a v neposledni rade se taky trochu starat o vyvoj a byt aktivni na mailing listech/forech. Moc nerad bych delal F/OSS tak, ze to nekde hodim na net a posluzte si... rad bych kdyz uz, tak si za tim trochu stal. A na to nemam zatim cas
A duvody? Kdyz uvolnim framework ci nejaky nastroj, muzu na tom jen vydelat -- peer review, nejaky dobry kod, sance ziskat spolupracovniky se znalosti mych nastroju (coz se jinak dela dost tezko...), publicita (kvalitne rozjetej F/OSS projekt je lepsi reklama nez tisic kecu...)
Priklanim se k tomu, co napsal pan Kvasnicka a rekl bych, ze to co on vyzdvihuje jako (+) neni v 99 % pripadu vyvazeno tim, co ztracite. Tedy jestli minite open source ve smyslu gpl apod.Jde o to dobre vychytat tu hranici co otevrit a co ne, aby ta ztrata nebyla. Udelat kompletni vlajkovy produkt jako open source je pro freelancera bez firmy a sirsiho portfolia v zadech ekonomicky relativne beze smyslu. Ale udelat jako open source treba jen par nastroju a frameworku, tam bych nemluvil o "ztrate". Sice obsahuji nejake moje know how, ale ne takove, ktere by tvorilo efektivni konkurenceschopnost. Napr. tvurci frameworku Djano by vam taky nedali komplet zdrojaky svych zpravodajskych portalu, ale kdyz otevreli Django, jen jim to prospelo (IMHO).
Ja prodavam vlastni software vzdy se source ale zakaznik s tim muze neco delat jen tehdy, kdyz bych odmitl dalsi spolupraci. Pak smi muj cod vzit a delat s tim co chce. To hodnoti zakaznici jako pozitivni a protoze to je dnes bezne, ani to nemohu delat jinak.Ja nedavam zdrojak rovnou, ale do smlouvy klauzuli, ze predam zdrojak a vse potrebne, pokud nebudu schopen zajistit kontinuitu dila (min. v ramci sjednane sluzby). Ale i na zdrojacich rovnou k dilu bych byl ochoten se za urcitych podminek domluvit.
Zaslaný patch musí někdo zkontrolovat. Mnohdy je rychlejší napsat požadovanou funkcionalitu sám, než se prodírat cizím patchem (který se obvykle nedrží nastolené štábní kultury). Tohle považuji za největší nevýhodu tohoto stylu vývoje softu.E? Jednak muzu vesele ignorovat patche od jinych ve svem stromu, jednak je programatorskou zhuverilosti neprovadet code review pred zaclenenim patche do stromu, at je vyvoje open source nebo closed source (pokud se nejedna o one-man-show, samozrejme).
Proto je obvykle lepší, když uživatel zašle požadavek na funkci a vývojový tým, který zná kód daleko lépe, než kdokoliv cizí, ji na přání uživatele napíše. Tohle je v podstatě opak předchozího. Buď se zvýší režie na kontrolu patchů, nebo se zvýší režie na komunikaci mezi vývojáři a komunitou.Napise nebo nenapise. A kdyz nenapise, pozadavek konci ve stoupe.
Dále je to omezená kontrola nad produktem. Pokud něco uvolním jako OpenSource, kdokoliv to může z principu věci okopírovat a vydávat za své dílo. Proti čemuž se jen těžko bojuje.Autorsky zakon plati pro open i closed source. Nezavisle na tom, zda je kod uzavreny ci neni, privlastnit se da oboji, jen v tom druhem pripade je to trosku narocnejsi. A na otazku, co pro me znamena Open Source, je tato odpoved: a) moznost spoluprace s jinymi, nemam prece patent na rozum (nejlepsi prispevatele jsou "cistici" kodu, kteri vezmou stavajici prasacky napsany kod a vypuliruji ho) b) zdroj vzdelani (ano, za zivot jsem nastudoval funkcnost mnoha ruznych kodu a naucil se mnoha vecim z nich) c) zvyseni vazby s hlavnimi uzivateli (uz se mi nekolikrat stalo, ze pri problemu v Solarisu velky zakaznik poukazal na moznosti implementaci zmen v OpenSolarisu a obcas jsme se dopracovali vzajemnou komunikaci k zajimavym vysledkum)
No dobře, ale k tomu nepotřebuješ zdrojáky, stačí dobře dokumentované API těch sdílených knihoven.
popř. si ji můžu upravit podle svých potřeb.Hmm... Jasně, no. Assemblerem to půjde i u closed-source, ale to myslím není ono.
A vzhledem k tomu, že nepíšu (doufejme) jako prase, tak výše popisované problémy (opatřit komentáři v angličtině, upravit "ke zveřejnění" atd.) u mne odpadají a zveřejnění SW je otázkou pár minut, popř. hodin.Napsal jsem projet veskere zdrojaky a ujistit se, ze kazda trida a metoda je dobre anglicky okomentovana. To neznamena, ze jsem prase, ale ze proste chci mit jistotu. Komentuju veskere sve kody, kazdou metodu a tridu, ale kdyz dopredu neplanuju, ze to jednou bude jako open source, nejsem si pak zpetne 100% jisty -- coz je myslim pochopitelne. Takze to je otazkou hodin a brzdil bych s temi silnymi vyrazy
@param a podobne.... Takze tak
Takže neptej se "Co mi přinese, když program uvolním jako open source?", ale spíše "Co se stane, když nikdo nebude dělat open source." Jinak ti to samozřejmě nepřinese žádné výhody.I uvolneni programu jako open source muze neprimo vest k materialnim vyhodam a neni na tom vubec nic spatneho. Nekdy muze byt dusledkem otevreni kodu i vetsi materialni zisk, nez jaky by teoreticky byl, kdyby SW zustal uzavrent. IMHO je dost projektu, ktere kdyby autori neotevreli, tak zdechnou, protoze by nebyli schopni se dostat pres relativne vysoky vstupni prah na ten dany segment trhu. Kdyz SW ale otevreli, znacne ten prah snizili (samotny SW byl bezplatny, takze se o to lide vice zajimali) a casem kolem toho SW vybudovali support masinerii, ktera jim prinasi nemale penize...
Tiskni
Sdílej: