Organizace Apache Software Foundation (ASF) vydala verzi 20 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Desktopové prostředí Cinnamon, vyvíjené primárně pro distribuci Linux Mint, dospělo do verze 6.0. Seznam změn obsahuje především menší opravy a v říjnovém přehledu novinek v Mintu avizovanou experimentální podporu Waylandu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzích 2.2.2 a 2.1.14. Přináší důležitou opravu chyby vedoucí k možnému poškození dat.
V ownCloudu byly nalezeny tři kritické zranitelnosti: CVE-2023-49103, CVE-2023-49104 a CVE-2023-49105 s CVSS 10.0, 8.7 a 9.8. Zranitelnost CVE-2023-49103 je právě využívána útočníky. Nextcloudu se zranitelnosti netýkají.
I letos vychází řada ajťáckých adventních kalendářů. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2023. Pro programátory v Perlu je určen Perl Advent Calendar 2023. Zájemci o UX mohou sledovat Lean UXmas 2023. Pro zájemce o kybernetickou bezpečnost je určen Advent of Cyber 2023…
Byla vydána verze 2.12 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
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 23.11 Topi. Přehled novinek v Changelogu.
Po 4 měsících vývoje byla vydána nová verze 4.2 multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu a na YouTube.
Byla vydána nová stabilní verze 23.11 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Tapir. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) upozorňuje na hrozbu spojenou s používáním mobilní aplikace WeChat a její čínské verze Weixin (dále jen WeChat). Ta sbírá velký objem uživatelských dat, a právě to by – v kombinaci se způsobem jejich sběru – mohlo sloužit k přesnému zacílení kybernetických útoků.
Řešení dotazu:
Jaképak jediné distro?! Fedora i Arch samozřejmě už odpradávna mají kernel 3.17. Nemusí být každé distro fosilní.
Zkompilovat si vlastní kernel je celkem snadno proveditelný nápad. Není pak nutně potřeba hlídat žádné aktualizace — stačí si kernel překompilovat, když vyjde nová verze. Lidský čas je drahý, proto nemá smysl zabývat se pokaždé znova otázkou, jestli je aktualizace zrovna na danou verzi nezbytná, a místo toho prostě spustit „na pozadí“ svůj oblíbený skript na kompilaci kernelu.
Nejjednodušší cesta by mohla být dočasné použití vlastního zkompilovaného kernelu (ať už vlastnoručně z Gitu nebo pomocí nějakého nástroje v distru) do doby, než se dostatečně nový kernel dostane implicitně přímo do distribuce. To podle mě nemůže trvat déle než pár měsíců.
Vidím, že máš veľa ušetreného času. Prečo svoj ušetrený čas nevyužiješ vylepšovaním svojho Archu.
Si znalec distribúcii ? Nech každí používa čo chce. Každí má slobodné rozhodnutie čo si vyberie. Podľa mňa robíš veci tak aby boli hotové a nezaujíma ťa ani ako sa to dá urobiť inač. Najskôr volíš cestu najnižšieho odporu ? Neviem čo ťa motivuje stále aktualizovať arch. Keby má niečo stabilné čo sa nemení každú sekundu možno by si toho naprogramoval niečo viac. Možno keby to bolo aj 0.00000001% viac. Keby to bolo možne možno by si každí deň upgradoval firmvér riadiacého systému rozvodu elektrického prúdu,vody, plynu, elektrárni ? Síce je to extrém ale nič nie je nemožné. Mal by si odvahu zobrať zodpovednosť za takéto systémy pri dennom upgrade firmvéru. Ako by si sa dorozumieval pri páde týchto systémov ? Predstav si, že by nefungovala sieť Internetu. To znamená, že VOIP nefunguje. Mobil by mohol fungovať ale je to zastaraná technológia. Čo urobíš. Hlasová komunikácia nie je vždy dostatočne zretelná. Na toto exitstuje riešenie z vysielačiek. Foneticke hláskovanie. Aha znovu zastaraná technológia. Nakoniec pri kolapse je vždy najlepšia najjednoduchšia technológia.
Sorry za off-topic.
Si znalec distribúcii ?
Ano, jsem. Není mi jasné, kam směřuje tato otázka a čím přesně přispívá do konstruktivní debaty.
Tak celkově nechápu, na co se tu snažíš reagovat. Anglicky se tomuto jevu trefně říká over-reacting. Kdybys dočetl můj komentář do konce, věděl bys, že jsem zmiňoval několik možností. Vlastnoruční upgrady kernelu jsem uváděl pouze jako jednu z možností a doporučoval jsem je spíš jako dočasné řešení, což ale pochopili jen ti, kteří dokázali udržet pozornost a chápat psaný text až do posledního odstavce.
Tvůj příspěvek je opravdu těžce off-topic, když uvádíš příklady nějakých embedded systémů, u kterých se kernel a základní userspace označuje za „firmware“. Původní tazatel se jasně ptal na běžný desktopový systém a jasně uvedl, proč potřebuje upgrade kernelu. Řeči o vodě, plynu a elektrickém rozvodu jsou úplně mimo mísu. Úvaha o používání zastaralých technologií jako záložních prostředků komunikace na tom není o nic lépe. Můžeš nějak objasnit, jak ty zastaralé technologie zprovozní WiFi chipset BCM43228? 
Neviem čo ťa motivuje stále aktualizovať arch.
Mě nemusí k aktualizacím nic motivovat. Jsou totiž tak jednoduché, automatizované, nenáročné a snadno dostupné, že nemám absolutně žádný důvod je neprovádět.
Keby má niečo stabilné čo sa nemení každú sekundu možno by si toho naprogramoval niečo viac.
Zas a znova tahle nesmyslná pověra. Až je to někdy únavné. Záleží sice na konkrétní platformě, toolchainu a podobně, ale obecně platí, že na programování není nic lepšího než aktuální systém. Stačilo by například vzít nějakých 1000 projektů z GitHubu, které zaznamenaly v uplynulém týdnu nějaký push, a zkusit, na které distribuci se kolik z nich přeloží. Fosilní distribuce zoufale prohrají a nutí své uživatele bojovat o každý balíček, o každou knihovnu.
Už dávno jsem tu někde psal, jak se liší domovské adresáře uživatelů na rozumné distribuci a na Ubuntu. (To nelze přehlédnout, když člověk příslušné systémy zálohuje.) Na normální distribuci tam uživatelé mají pár svých souborů, nic víc. Na Ubuntu tam mají celý „stínový“ root filesystém s gigabyty knihoven a programů v aktuálních verzích, které si museli sami stáhnout (!) a sami zkompilovat (!), aby vůbec mohli dělat svou práci. Takhle tedy „naprogramují víc“? Věřit báchorkám se nevyplácí.
Co to zace placas, v Ubuntu v home neni zadnej stin rootfsMůžeš prosím zkusit rozepsat, jestli má tedy Andrej halucinace?
pokud chce nekdo neco novejsiho nez nabizeji oficialni repositare pouzije se ppa repository daneho programuPokud existuje.
v tech par promile ostatnich pripadu uz se bude jednat o takove speciality ze uzivatel nebude mit problem si zprovoznit Gentoo, Arch, nebo klidne LFSDotaz, pod kterým diskutujeme, vznikl takovou „specialitou“. Notebook s novým broadcomem totiž má jenom pár promile lidí?
Notebook s novým broadcomem totiž má jenom pár promile lidí?
Nepřekvapilo by mne to.
Na Ubuntu tam mají celý „stínový“ root filesystém s gigabyty knihoven a programů v aktuálních verzích, které si museli sami stáhnout (!) a sami zkompilovat (!), aby vůbec mohli dělat svou práci.A to je poslední Ubuntu, nebo pět let stará LTS verze?
Je to 12.04 LTS.
Takže není to zrovna pět let staré (to už by spadlo pod hranici elementární použitelnosti), ale určitě to bude mít dobré tři roky, když uvážím, že ta distribuce byla „předzastaralá z výroby“ už v tom dubnu 2012.
Kdybych měl v otázce těch konkrétních strojů nějaké rozhodovací pravomoci, samozřejmě bych takový přístup použil. (Hlavně by pak k žádnému takovému problému nedošlo, protože by se tam nikdy žádné Ubuntu nedostalo.)
Když si vzpomenu, jak jsem teď na nějakém 14.10 (ne-LTS) musel zase (neúspěšně) kompilovat polovinu Ruby ve snaze zprovoznit nějakou ptákovinu, která na Archu i na Fedoře prostě okamžitě běží, řekl bych, že ač mé srovnání výše není fér, moje původní pointa pořád platí.
Si znalec distribúcii ? Nech každí používa čo chce. Každí má slobodné rozhodnutie čo si vyberie.Vždyť v tom příspěvku nepsal nic jiného…
Neviem čo ťa motivuje stále aktualizovať arch.Nevím, co jeho, ale mě: v nových verzích jsou nové funkce a opravené bugy, případně jsou potřeba nové verze knihoven, abych mohl zkompilovat gitovou verzi různých jiných projektů, které jsou třeba experimentální nebo je chci ladit (gnuradio, osmo*).
Nevím, co jeho, ale mě: v nových verzích jsou nové funkce a opravené bugy
…a taky nové bugy. Na to se často a rádo zapomíná.
Co je lepší — zachování a hýčkání starých bugů nebo upgrade na nové bugy?
Podle mě to vyjde nastejno. Z pohledu bezpečnosti na tom můžou být nové bugy lépe, protože budou méně známé útočníkům všeho druhu.
Na nové bugy se tedy rozhodně nezapomíná, ale v celkovém součtu výhod a nevýhod nemají nikde ústavní většinu.
Co je lepší — zachování a hýčkání starých bugů nebo upgrade na nové bugy?
Falešné dilema. Pro funkčně dostačující existující systém je lepší opravit známé bugy, které někomu opravdu vadí, a (pokud možno) zbytečně nezanášet nové. Vážně si myslíte, že ty firmy, které dodnes platí nemalé peníze za support systémů z roku 2004, to dělají jen proto, že jsou banda idiotů, kteří tomu na rozdíl od vás vůbec nerozumějí?
Ano, to si skutečně myslím, bez legrace.
A když už je řeč o gitu a kompilaci, já občas uvádím třeba Diasporu jako dobrý důvod, proč mít Arch na některém serveru. Jeden z vývojářů Diaspory používá Arch a udržuje balíčky s Diasporou, díky kterým je dnes instalace a aktualizace Diaspory v Archu (přímo z gitu) jednoduchá. Nebýt Archu, asi bych svůj Diaspora pod už dávno zavřel.
Keby má niečo stabilné čo sa nemení každú sekundu možno by si toho naprogramoval niečo viac.Možná ano, ale pak by to lidem s novějším systémem nešlo zkompilovat. A nebo zase ne, protože bych třeba tři dny řešil bug, který už v poslední verzi někdo vyřešil (příklad z praxe, kdybych používal starší verzi, tak se z toho po***).
Fedoru s KDE jsem používal v práci cca rok a měl jsem s ní jen ty nejlepší zkušenosti. (Jako zásadní odpůrce Gnome bych nikdy nedoporučoval distro, ve kterém nefunguje dobře KDE.) Kdybych nezměnil zaměstnání a kdybych nemusel ten desktop s Fedorou vrátit, používal bych asi Fedoru v práci dodnes.
OpenSUSE jsem naposledy viděl v roce 2012, takže to nemůžu přesně srovnat, ale ve Fedoře s KDE taky existuje spousta nativních klikátek a udělátek pro správu systému. (Samozřejmě se musí nainstalovat — nejsou automaticky v dependencích KDE, což je asi jedině dobře.) Pro správu softwaru tam je velice pěkné GUI částečně napsané rovnou v Qt a částečně integrované do nějakého Plasma appletu atd. Celý rok, kdy jsem Fedoru používal, se aktualizace děly naprosto automaticky a bez mého přičinění. Jenom se mi třeba při uspávání desktopu objevila bublina "bacha, dnes se aktualizoval kernel, je doporučeno vypnutí místo uspání" a tak. Tahle doporučení byla dost precizně odstupňovaná, protože to třeba umělo říct „aktualizovaly se komponenty KDE, až budeš mít chvilku, odhlas se a znova se přihlas“, případně „byl aktualizovaný kus X-serveru, tak až budeš chtít, restartuju KDM“. Nikdy to nechtělo žádné bezdůvodné restarty kvůli nějakým banálním každodenním aktualizacím. Navíc se tam dalo velice přesně nastavit, co se má aktualizovat automaticky a co ne a jak často se má něco takového řešit. Taky s grafickými utilitami pro nastavení sítě (Plasma appletem pro ovládání NetworkManagera) jsem byl naprosto spokojen. Ten je tam v podstatě out-of-the-box. Asi bych taky vyzdvihl instalátor, který se nebojí konfigurace bootující z Btrfs a používající subvolumes. Binární ovladače od grafických karet překompiluje automaticky podle potřeby akmod s pluginem pro daný hardware (tj. například něco jako akmod-nvidia). Sečteno a podtrženo, umím si představit, že by to někdo mohl používat i jako klikací distro, ve kterém nesahá do terminálu. (Poté, co mu někdo pomůže se základní instalací a přidá všechna ta standardní distribuční klikátka.)
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
23.11.2014 18:19
grub2, na wifinu se musely ještě extra zavolat vlastní downaload driverů podle příkazu, který jádro napsalo do dmesg. (Počítám, že to je licenční záležitost oss/non-oss.) Virtual box se nainstaloval celý automaticky standardním způsobem, po zařazení přímého repozitáře z oraclu. Pohoda. Mimochodem openSUSE 13.2 také bootuje zvnitř btrfs sedícího na LVM, žádný separátní /boot oddíl, jen subvolume pro /boot, /var a pár dalších. Při nové instalaci dává na root btrfs jako implicitní filesystem. A opensuse také neotravuje zbytečně z rebootem, aktualizuji sice vetšinou sám, protože chci vědět co, ale nastavení aktualizuj automaticky (bud jen security nebo vše) má také. maximálně se občas mohu chtít zeptat, jak to z restartem služeb je, když si pustím zypper ps tak mi vypíše procesy, které mají naloudované soubory, které díky aktualizaci už nejsou (a je vhodné je někdy restartovat.)
Vrazit tam jádro z Factory, Pro bod 2 a 3 a nějak jádro zařadit do bootu, je jsem zatím nedělal.Na Debianu se jádra z balíčků generují do nabídky bootloaderů automaticky, na OpenSUSE snad taky…
Mně na Debianu VirtualBox s 3.17 normálně funguje, modul si to zkompilovalo samo (samozřejmě bylo potřeba nainstalovat s jádrem i hlavičky).
Zrovna mezi 3.16 a 3.17 došlo k nekompatibilním změnám API, takže některé third party moduly (VMware, VirtualBox) je potřeba opatchovat. Novější VirtualBox to AFAIK řeší, ale ten ve 13.2 pochopitelně není. Ale když už si bude z Factory brát jádro, může vzít i VirtualBox.
Na Debianu se jádra z balíčků generují do nabídky bootloaderů automaticky, na OpenSUSE snad taky…
Pokud ho instaluje z RPM balíčku tak ano.
To je sice hezké, ale v okamžiku, kdy máte nekompatibilní změnu API (jako právě mezi 3.16 a 3.17), tak vám žádný takový automatický nástroj prostě fungovat nebude; ty moduly se prostě musejí opatchovat.
Google tvrdí, že v OpenSuse to je také.
DKMS sice asi existuje, ale spíš jako doplňkový nástroj pro ty, kdo chtějí používat jiná jádra než ta z distribuce. Distribuční jádro zachovává kABI, aby šly tytéž moduly použít bez rekompilace. (Tuhle zásadu by ale při případném upgradu na 3.17 bylo nutné porušit.)
OpenSUSE slibuje, že cílové jádro pro 13.2 je 3.17
To byl sice původní plán, ale s ohledem na časový harmonogram vydání jádra 3.17 a OpenSuSE 13.2 to nakonec nebylo reálné a ve 13.2 zůstalo jádro 3.16.
a asi se ho do vánoc dočkáme
Tak to máte asi nějaké informace, které mne minuly. V příslušném diskusním listu proběhla sice debata na toto téma a upgrade na 3.17 v rámci updatů 13.2 byl sice jednou z probíraných možností, ale nezdálo se, že by vedla k jasnému výsledku, natož aby se dalo tvrdit "a asi se ho do vánoc dočkáme". Mimochodem, právě problémy s third party moduly jsou asi nejvýraznějším argumentem proti takovému kroku.
Factory uz neni .. Je Tumbleweed a je dost stabilni i pro bezne pouziti
Tiskni
Sdílej:
24.11.2014 02:30
