Podvodné reklamy na sociálních internetových platformách, jako je Facebook, Instagram nebo X, vytvořily loni v Česku jejich provozovatelům příjmy 139 milionů eur, tedy zhruba 3,4 miliardy korun. Proti roku 2022 je to nárůst o 51 procent. Vyplývá to z analýzy Juniper Research pro společnost Revolut. Podle výzkumu je v Česku zhruba jedna ze sedmi zobrazených reklam podvodná. Je to o 14,5 procenta více, než je evropský průměr, kde je podvodná každá desátá reklama.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.6 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
Czkawka a Krokiet, grafické aplikace pro hledání duplicitních a zbytečných souborů, byly vydány ve verzi 11.0. Podrobný přehled novinek v příspěvku na Medium. Od verze 7.0 je vedle frontendu Czkawka postaveného nad frameworkem GTK 4 vyvíjen nový frontend Krokiet postavený nad frameworkem Slint. Frontend Czkawka je už pouze v udržovacím módu. Novinky jsou implementovány ve frontendu Krokiet.
Jiří Eischmann na svém blogu publikoval článek Úvod do MeshCore: "Doteď mě radioamatérské vysílání úplně míjelo. Když jsem se ale dozvěděl, že existují komunity, které svépomocí budují bezdrátové sítě, které jsou nezávislé na Internetu a do značné míry taky elektrické síti a přes které můžete komunikovat s lidmi i na druhé straně republiky, zaujalo mě to. Když o tom přede mnou pořád básnili kolegové v práci, rozhodl jsem se, že to zkusím taky.
… více »Byla vydána verze 0.5.20 open source správce počítačových her na Linuxu Lutris (Wikipedie). Přehled novinek v oznámení na GitHubu. Instalovat lze také z Flathubu.
Peter Steinberger, autor open source AI asistenta OpenClaw, nastupuje do OpenAI. OpenClaw bude převeden pod nadaci a zůstane otevřený a nezávislý.
Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2025. Ke konci roku 2025 vlastnila 349 462 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,36 %. V roce 2024 to bylo 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
Nástroj sql-tap je proxy mezi aplikací a databází, které zachytává všechny SQL dotazy a zobrazuje je v terminálovém rozhraní. Zde lze téměř v reálném čase zkoumat dotazy, sledovat transakce a spouštět SQL příkaz EXPLAIN. Podporované databázové systémy jsou pouze PostgreSQL a MySQL. Zdrojový kód je dostupný na GitHubu, pod licencí MIT.
Byla vydána nová verze 9.2 textového editoru Vim (Vi IMproved). Přináší vylepšené doplňování, podporu schránky ve Waylandu, podporu XDG Base Directory (konfigurace v $HOME/.config/vim), vylepšené Vim9 skriptování nebo lepší zvýrazňování změn. Vim zůstává charityware. Nadále vybízí k podpoře dětí v Ugandě. Z důvodu úmrtí autora Vimu Brama Moolenaara a ukončení činnosti jím založené charitativní organizace ICCF Holland projekt Vim navázal spolupráci s charitativní organizaci Kuwasha.
Byl představen editor MonoSketch, webová aplikace pro tvorbu diagramů, technických nákresů, flowchartů a různých dalších vizualizací, to vše jenom z ASCII znaků. Všechny operace běží pouze v prohlížeči uživatele a neprobíhá tedy žádné nahrávání dat na server. Zdrojový kód aplikace (drtivá většina Kotlin, žádné C#) je dostupný na GitHubu pod licencí Apache 2.0.
Ř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.)
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: