Odborníci z Penn State University zkoumají způsob ukládání informací na lepicí pásku. Principiálně by podle nich bylo možné kombinací odlepení a zpětného přilepení dosáhnout uložení informace, kterou opětovným odlepením dokážou přečíst. Výhodou je, že způsob uložení i přečtení je čistě mechanický. Zde o tom referují ve volně dostupném článku. Zajímavé bude sledovat zda se jim v rámci výzkumu podaří prokázat použitelnost i v jiné než
… více »Na GitHubu byl publikován reprodukovatelný návod, jak rozchodit Adobe Lightroom CC na Linuxu a Wine. Návod byl vytvořený pomocí AI Claude Code.
Pokud by někdo potřeboval Wayland kompozitor uvnitř počítačové hry Minecraft, aby mohl zobrazovat okna desktopových aplikací přímo v herním prostředí, může sáhnout po Waylandcraftu. Ukázka na YouTube.
Uroš Popović v krátkém článku vysvětluje, co jsou emulátor terminálu, TTY a shell a jaké jsou mezi nimi rozdíly. Jde o první díl seriálu na jeho novém webu Linux Field Guide věnovaném nízkoúrovňové práci s linuxovými systémy.
Byl vydán Debian 13.5, tj. pátá opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.14, tj. čtrnáctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
CiviCRM (Wikipedie) bylo vydáno v nové verzi 6.14.0. Podrobnosti o nových funkcích a opravách najdete na release stránce. CiviCRM je robustní open-source CRM systém navržený speciálně pro neziskové organizace, spolky a občanské iniciativy. Projekt je napsán v jazyce PHP a licencován pod GNU Affero General Public License (AGPLv3). Český překlad má nyní 45 % přeložených řetězců a přibližuje se milníku 50 %. Potřebujeme vaši pomoc, abychom se dostali dál. Pokud máte chuť přispět překladem nebo korekturou, přidejte se na platformu Transifex.
Další lokální zranitelností Linuxu je ssh-keysign-pwn. Uživatel si může přečíst obsah souborů, ke kterým má právo ke čtení pouze root, například soubory s SSH klíči nebo /etc/shadow. V upstreamu již opraveno [oss-security mailing list].
Singularity (YouTube) je nejnovější otevřený film od Blender Studia. Jedná se o jejich první 4K HDR film.
Vyšla hra Život Není Krásný: Poslední Exekuce (Steam, ProtonDB). Kreslená point & click adventura ze staré školy plná černého humoru a nekorektního násilí. Vžijte se do role zpustlého exekutora Vladimíra Brehowského a projděte s ním jeho poslední pracovní den. Hra volně navazuje na sérii Život Není Krásný.
Společnost Red Hat představila Fedora Hummingbird, tj. linuxovou distribuci s nativním kontejnerovým designem určenou pro vývojáře využívající AI agenty.
MojeFedora.cz informuje, že bylo oficiálně oznámeno vydání Fedory 29. Ve finální verzi vycházejí tři edice: Workstation pro desktopové, Server pro serverové a Atomic pro cloudové nasazení. Vedle nich jsou k dispozici také alternativní desktopy, např. KDE Plasma (spiny Xfce a LXDE byly kvůli chybám odloženy) a k tomu laby – upravené vydání Fedory například pro designery, robotiku, vědecké použití atd. Stahovat lze z Get Fedora.
Tiskni
Sdílej:
No, spíš je to takové objevení Ameriky: aplikace, které potřebují pracovat s vašimi daty, nejsou 100% sandboxované a světe div se mají k těm datům přístup.Pokud máš sandbox s přístupem do
$HOME a ne nějaké omezené podsložky, tak nemáš sandbox.
Pozor, aplikace třetí strany může mít nezáplatovanou díru.Ne jen ta aplikace, ale celý stack, který se ti normálně na linuxu updatuje. Flatpak by měl mít podtitul „to nejhorší z uživatelského zážitku distribuce windows aplikací nyní i ve vašem linuxu“. Myslel jsem, že ta doba kdy jak idiot musím googlit abych si stáhl nějaký program a pak lézt na nějaký obskurní web a stahovat tam pofidérní binárky je dávno pryč. Ale ne, teď se to zase vydává za krok vpřed.
A "Flatpak, který instalujete s právy roota, může získat práva roota" (což je mimochodem naprosto integrální vlastnost drtivé většiny balíčkovacích systémů) si dovolili opravit jenom jako minor security issue :)Tady jde o princip - flatpak je prezentovaný jako nejlepší vynález, jako nějaký způsob záchrany distribuce aplikací v linuxovém světě. Přitom je to sračka, jak z uživatelského hlediska*, tak z hlediska správce systému. Jediný kdo z toho má nějaké výhody je tvůrce aplikace, který se tak nenadře při balení, což je ovšem dneska podle mého názoru relativně automatizovatelný problém.
Jediný kdo z toho má nějaké výhody je tvůrce aplikace, který se tak nenadře při balení, což je ovšem dneska podle mého názoru relativně automatizovatelný problém.Tak automatizovaný systém, který by mi umožnil produkovat s dostatečnou zárukou balíčky pro většinu mainstreamových distribucí, aniž bych to musel na každé distribuci ručně testovat a pravidelně sledovat, zda se něco kvůli aktualizovaným zavistlostem nerebuildnulo bych chtěl vidět. Klidně bych to používal místo Flatpaku, kdyby něco podobného existovalo.
)
macOS includes a low-level command-line interface to the OpenSSL open-source cryptography toolkit; this interface is not available in iOS.
Although OpenSSL is commonly used in the open source community, it doesn’t provide a stable API from version to version. For this reason, the programmatic interface to OpenSSL is deprecated in macOS and is not provided in iOS. Use of the Apple-provided OpenSSL libraries by apps is strongly discouraged.
Pokud tedy chci jako vývojář napsat něco, co může fungovat stylem "fire and forget", mám tu možnost a mít ji pravděpodobně dost dlouho budu.Protoze Windows nerozbiji ABI. Ale nejsem si teda jisty jestli bys na Windows 10 pustil aplikaci treba pro Windows 95 (to je tech 25 let). Ze stejneho duvodu se mohl stal linux standardem pro kontejnery, we do not break userspace.
Flatpak je pragmatické řešení problému, který "opravdové" řešení prostě nemá.ABI backwards compatibility. Nedavno jsem tady posilal odkaz na mnoho let stary rozhovor se zakladatelem Gnome, ktery presel na OS X, a presne toto citoval jako duvod proc Linux prohral bitvu o desktop. Flatpak je jen dalsi z polofunkcnich workaround staleho rozbijeni ABI* zakladnich gui/desktop knihoven, je opravdu tak těžké ho takto vnímat a podle toho jej v praxi (ne)nasazovat?
To má Miguel DeIcaza (předpokládám, že je řeč o něm) z velké části pravdu. Vtipné je, že kdykoliv s tím v Linuxovém ekosystému začne někdo něco dělat, snese se na něj vlna hejtů o tom, jak je to špatné a že "teď" je to vyřešené vlastně správně. Udržet dlouhodobě stabilní nějaké netriviální API je jakž takž možné jen v značně homogenním prostření, které spravuje a ovládá jedna entita. Na druhou stranu tady máme svět FOSSu, kde si může z definice každý dělat co chce a jak chce. Skloubit dohromady striktně plánovaný vývoj a hejhurá bastlení garážových hackerů prostě nejde...Flatpak je pragmatické řešení problému, který "opravdové" řešení prostě nemá.ABI backwards compatibility. Nedavno jsem tady posilal odkaz na mnoho let stary rozhovor se zakladatelem Gnome, ktery presel na OS X, a presne toto citoval jako duvod proc Linux prohral bitvu o desktop.
Flatpak je jen dalsi z polofunkcnich workaround staleho rozbijeni ABI* zakladnich gui/desktop knihoven, je opravdu tak těžké ho takto vnímat a podle toho jej v praxi (ne)nasazovat?Kvalifikátor stupně funkčnosti nechť si dosadí každý jaký chce. Je-li k dispozici objektivně lepší řešení, sem s ním. V opačném případě zůstanu u Flatpaku, který se aktivně vyvíjí, má backing velké firmy a v principu rozumný návrh.
Vtipné je, že kdykoliv s tím v Linuxovém ekosystému začne někdo něco dělat, snese se na něj vlna hejtů o tom, jak je to špatné a že "teď" je to vyřešené vlastně správněNevsiml jsem si, ze by se s tim snazil nekdo neco delat. Cely desktop stack kompletne od gtk (vcetne) ma pod kontrolou Red Hat (brzy IBM) a za rozbijeni ABI schytava pouze kritiku uz radu let, je o tom cela sekce na wikipedii.
Kvalifikátor stupně funkčnosti nechť si dosadí každý jaký chce. Je-li k dispozici objektivně lepší řešení, sem s ním. V opačném případě zůstanu u Flatpaku, který se aktivně vyvíjí, má backing velké firmy a v principu rozumný návrh.Pouzivas QT5 a qt ABI kompatibilitu jen tak nerozbiji, takze i kdybys to releasnul jako "blby" tarball s dynamickou zavislosti na QT knihovnach (prekompilovat proti nejstarsimu QT5, ktere chces podporovat) a ty special knihovny zabundloval (jak je to s icu nevim), tak to bude mit narozdil od flatpaku nasledujici vyhody - bezpecnostni updaty zavislosti, lepsi integrace (fonty, temata,..), bude fungovat na vice distribucich (qt5.2 je uz v ubuntu 14.04 LTS) a uzivatel nebude mit falesny pocit bezpecnosti.
Pouzivas QT5 a qt ABI kompatibilitu jen tak nerozbiji, takze i kdybys to releasnul jako "blby" tarball s dynamickou zavislosti na QT knihovnach (prekompilovat proti nejstarsimu QT5, ktere chces podporovat) a ty special knihovny zabundloval (jak je to s icu nevim), tak to bude mit narozdil od flatpaku nasledujici vyhody - bezpecnostni updaty zavislosti, lepsi integrace (fonty, temata,..), bude fungovat na vice distribucich (qt5.2 je uz v ubuntu 14.04 LTS) a uzivatel nebude mit falesny pocit bezpecnosti.Úplně stejně jsem dřív uvažoval taky a nějaký SW jsem jako všechnotarbally distribuoval. Měl jsem kvůli tomu virtualizované Ubuntu 12.04 v 32 a 64 bit vezích, Qtčka jsem bundloval, protože mám hard dep na verzi 5.6 a vyrobit ten tarball s každým novým releasem byl komparativně větší voser, než pustit skriptík na sestavení flatpaků. Jednou jsem cca rok starý tarball vzal a zkusil pustit na v té době aktuálním Archu. Nespustilo se samozřejmě nic, protože se někde změnilo ABI libgfortran, na které jsem nepřímo závisel. Od té doby jsem začal balit Flatpakem. Moc zkušeností s dlouhodobou funkčností ještě nemám ale zatím se nic přímo nerozbilo. Napadá mě akorát, že na Fedoře otevíral Flatpak ještě okolo verze 1.0.0 Gtkčkové load/save dialogy, což mělo v případě interakce s Qt appkou dost bizarní vliv na funčnost (kromě toho, že to vypadalo fakt dementně). Od nějaké aktualizace už je to okay. Zvláštní je, že na Archu to chodilo správně vždycky...
Úplně stejně jsem dřív uvažoval taky a nějaký SW jsem jako všechnotarbally distribuoval. Qtčka jsem bundloval, protože mám hard dep na verzi 5.6. Nespustilo se samozřejmě nic, protože se někde změnilo ABI libgfortran, na které jsem nepřímo záviselMuzu ti poslat build vimu s dynamickymi zavislostmi (ale bundlovanym pythonem2.7 kvuli rhel5), ktery funguje spravne (a to diky dynamickym zavislotem!) na vsem od rhel5 po nejnovejsi debian. Dynamicke zavislosti musi byt pouze na knihovny se stabilnim ABI, vse ostatni je bohuzel nutne bundlovat. S flatpakem bundlujes vse a tim si vytvaris nove slozite problemy. Ale ze zrovna libgfortran nebude mit stabilni ABI ... to bych asi rozmlatil klavesnici :). Z toho co pises chapu ze si frustrovany z neustaleho rozbijeni ABI kompatibility na linuxu a si pak rad za cokoliv co bude aspon nejak fungovat a tolerujes pak klidne i rozhozene file dialogy. V te frustraci z rozbiteho ABI v userlandu na linuxu se shodneme, v narocich na kvalitu pripadneho reseni ne. Staci si z flathubu nainstalovat treba Octave (nebo jinou QT aplikaci) a najednou pouziva jine fonty nez zbytek systemu (zkouseno v gnome, bez flatpaku se integruje spravne) - pro me je tohle neprijatelne, nemluve o bezpecnosti a hlavne - jaktoze vsechny tyto "known limitations" nejsou nikde zdokumentovane a pokud se o nich clovek zmini, tak zacnou flatpak vyvojari akorat rvat ze si "hater"? Toto receno, chapu tvoji frustaci a to ze se pak spokojis s jakymkoliv resenim. Shodneme se na tom, ze opravdove reseni by bylo stabilni ABI desktop stacku?
Shodneme se na tom, ze opravdove reseni by bylo stabilni ABI desktop stacku?Ano stabilni ABI na linux desktopu jen tak nebude, ale to nam prece poskytuji stable/LTS distribuce. Proc teda v tom chrootu nepoustet misto zcela novych runtimes + bundle jiz existujici stable/LTS ditribuci? Tak by taky fungoval jeden balicek "vsude" (diky tomu ze ma kernel dekady stabilni ABI a zbytek bude v chrootu uplne stejne jako s flatpakem); nebude potreba spravovat nove balicky (flatpak runtimes) a backporty uz pro nas nekdo dela, navic budou fungovat automaticke updaty zavislosti a bude jednodusi integrace, napr. ten fontconfig by stacilo nastavit dvakrat (jednou v host systemu, jedno v chroot distru) misto N ruznych runtimes. Taky bych se nebal pouzit knihovny mimo chrootu v pripadech kdy to dava smysl (napr. libGL.so).