Firma X zaslala předžalobní výzvu vývojáři projektu Nitter (Wikipedia), open-source alternativního frontendu k sociální síti X (ex-Twitter), a provozovatelům instancí jako XCancel, které umožňovaly číst příspěvky bez přihlášení, reklam a javascriptu. Údajně se dopouštějí „sběru dat“. Zdrojový kód Nitteru vývojář archivoval. Vývoj již dříve přerušil v roce 2024 po tehdejším omezení API X. X je dceřiná společnost SpaceXAI Elona Muska, provozující mj. kontroverzního chatbota Grok.
Bylo vydáno Ubuntu 26.04.1 LTS, tj. první opravné vydání Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek a oprav na Discourse.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2025 (pdf). Incidentů ubylo, sofistikovanost útočníků roste.
Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
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:
30.10.2018 20:09
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
31.10.2018 03:05
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
30.10.2018 16:55
30.10.2018 17:22
$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.
1.11.2018 22:51
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
)
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.
31.10.2018 23:59
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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).
30.10.2018 23:04