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.
24.4.2007 16:31
cezz | skóre: 24
| blog: dm6
Protože však kompilátor Intel není svobodný software, nelze balíčky jím kompilované volně zveřejnit.Myslím, že s takovými licenčními podmínkami by Intel nevydělal ani na suchý chleba
.
Možná, ale neplacená verze kompilátoru je výhradně pro nekomerční použití. Proto si myslím, že není možné, aby například Novell bez následků vydal své SUSE s X-serverem zkompilovaným kompilátorem Intel. Musel by nejspíš zaplatit nemalé licenční poplatky.
Pokud by nebyly podmínky tak přísné, proč už např. pro ArchLinux nikdo nevytvořil alternativní repository s balíčky kompilovanými kompilátorem Intel nebo Sun? Kromě toho se bohužel pořád ještě nedá zkompilovat samotný Linux ničím jiným než GCC, takže možnost alternativních kompilátorů je zatím ve hvězdách.
Navíc, těch pár set dolarů za linuxovou verzi překladače by takový Novell asi nezabilo. Spíš by mě zajímalo, jak takový Intel-optimized kód běží na procesorech AMD?
24.4.2007 18:15
Max | skóre: 72
| blog: Max_Devaine
Firma AMD má samozřejmě možnost vytvořit a vydat svůj překladač, stejně jako to dělá Intel. Nevidím důvod, proč by měl kód z překladače Intel běžet dobře na AMD. Protože můj počítač má procesor Intel, zajímám se pochopitelně o Intel víc než o AMD a jejich kompilátor byl první z alternativ, která mě napadla.
No jo, já se asi jednou naštvu a přejdu na OpenSolaris...
Výjimkou potvrzující pravidlo mohou být dpkg/APT z Debianu
Btw. dělá Pacman pořád tu prasárnu, že přepisuje po upgradu balíčků jejich konfigurační soubory, přestože jsou v nich provedené změny ? Musí se stále explicitně uvádět v pacman.conf aby se nepřepsaly ?
Administrativní nástroje by IMHO neměly být v nativním kódu. Přímá závislost na nainstalovaných systémových knihovnách a kontrola/udržba kódu v něčem jako je C je daleko náchylnější k problémům než když to poběží v shellu nebo třeba interpretru Pythonu.Zavislost takoveho programu napsaneho v C je minimalni - typicky libc a a par dalsich knihoven. Program v perlu nebo pythonu zavisi na interpretu, (ktery sam je typicky napsany v C a ma tedy podobne zavislosti na systemovych knihovnach), na pouzivanych knihovnach a na bindings tech knihoven do interpretovaneho jazyka. Tedy zavislost v pripade interpretovaneho jazyka bude typicky vetsi.
Btw. dělá Pacman pořád tu prasárnu, že přepisuje po upgradu balíčků jejich konfigurační soubory, přestože jsou v nich provedené změny ? Musí se stále explicitně uvádět v pacman.conf aby se nepřepsaly ?
Pokud je balíček správně nastaven, nemělo by se to stát a konfigurační soubory by se měly uložit s příponou .pacnew při aktualizace a .pacsave při odstranění. Jestliže však balíček tuto informaci v sobě nenese, ani nejlepší pacman to nezachrání.
25.4.2007 09:38
vogo | skóre: 34
| blog: "Skládat papír"
To by bylo abych se nevyjádřil :), zdrojový kód pacmana myslím znám velmi dobře, jak verzí 2.9.x tak verzí 3.0.x. Vezmu to popořadě :)
úplně první verze pacmana vyšla v roce 2002, a už tehdy byl pacman napsán v C (jinak když se lepil arch, tak to dělaly skripty v úplných začátcích). Přehlednost a jednoduchost, ovšem tehdy to byl jeden jediný céčkový zdroják + sada skriptů (makepkg a spol). Kvalita kódu není kdo ví jaká, ale trojka je o dost stravitelnější, ale hodně by se dalo zlepšit, velkoě prospělo oddělení backendu (libpacman), což umožňuje napsat alternativní frontendy. Co se týče komentářů v kódu, je to opravdu bída. Osobně nemám rád pluginovací systém, pokud něco chybí, měl by to nabízet nějaký skript, nebo by se to mělo doimplementovat do programu (viz pacman-color, jistě by to všechno šlo dělat důmyslným skriptem, nebo modulem, ale o dost jednodušší to bylo dodrátovat).
Efektivita se s přepsanou verzí zlepšila, ale vždy je co zlepšovat, hlavním cílem je jednoduchost, porovnejte si pacmanovský systém třeba s RPM (BTW podobné problémy s výkonem má třeba i portagetree). Jiank při přechodu na dvojkovou verzi se databáze konvertovala, a řekněme si na rovinu, kdyby byl velký tlak změnit systém ukládání informací, tak to byl ten pravý čas, nyní si musíme počkat, třeba na 4.0.0 :).
Uložení dat má své pro i proti. Pokud se něco nepovede, mohu to vždycky dát dohromady ručně. Pokud by se tato struktura ukládala do databáze (opravdové), bylo by to o dost složitější (BTW podobně to má i gentoo - z toho vyplývá neefektivita). Tento problém s výkonem tohoto řešení má i gentoo, je to tam na jedno brdo.
Portovatelnost: tým archlinuxu není kdo ví jak veliký, ale jistě Vás uvítají, pokud se nabídnete jako správce nové platformy, či kompilovaných updatů, BTW srovnávat Gentoo s binárními distry není na místě.
Vlastní nastavení kompilátoru: dost to souvisí s předchozím, jinak optimalizace jde nastavit v makepkg.conf. Nezapomínejte, že arch je binární, pokud chcete systém na míru je tu gentoo. BTW jak by jste chtěl tohle udělat třeba na manrdivě ;) nějak nechápu.
Použití alternativního kompilátoru: sám jste si odpověděl:) ale nic nikomu nebrání, aby vše upravil pro použití jiného, než svobodného kompilátoru. Pokud něco chcete, tak to udělejte, ostatní taky dělají vše za darmo (nebo za mrzký peníz), takhle prostě funguje komunita, já něco napíšu, ty něco napíšeš. remcaly nikdo nemá rád.
ABS je něco navíc oproti binárním distribucím, rozhodně to není věc určená pro kompletní překompilování systému, to dělá leda masochista. Podívejte se na archovskou wiki, ABS je určen hlavně pro kompilaci jednotlivých balíčků, u kterých vám chybí nějaká funkcionalita, ať už chcete přidat nějaký patch atd., prostě je to strom PKGBUILDů z oficiálních repositářů, nic víc nic míň. Pokud chcete překompilovat celý systém, je to váš rybíz, a opět řeknu, tak použijte gentoo, arch je binární distribuce.
Viz výše, jinak si myslím že grafický frontend je pro archlinux zbytečný, tahle distribuce se snaží být bez balastu, odpovědí je libpacman. Úplně stranou zůstává to, že banda vývojářů je trochu zabedněná :) (trochu víc).
Navenek je pacman jednoduše ovladatelný a přehledný, k tomu jak vypadá kód jsem se vyjádřil.
Ten kdo kritizuje? No dobrá, ale nebylo by od věci ze zapojit do mailinglistu. A jen tak stranou, pacmana nedělá jeden člověk, už dávno ne. Pokud vás něco štve, tak to zkuste napravit, a patch poslat vývojářům, asi se hned nepostaví kladně, ale pokud splníte jejich připomínky, je tu šance na změnu, viz můj patch ;).
Tak to je pozitivní zpráva, že dojde ke změnám. Kdysi jsem měl (nějakým zázrakem) trochu času a říkal jsem si, že bych třeba doplnil něco zajímavého do Pacmana. Nepočítal jsem s tím, že by to vývojáři ArchLinuxu přijali, ale prostě jsem si ho chtěl trochu vylepšit a dát to ostatním k posouzení. Bohužel k tomu nedošlo, protože pohled na zdroják mě vyděsil natolik, že jsem od svého záměru ustoupil. Možná se někdy vzchopím a pokusím se ho celý přečíst, ale nevím, kdy to bude.
Tlak na změnu databáze jistě není, protože se dělají rychlejší procesory a rychlejší disky a nikoho to nezajímá. Ale elegance se vytrácí. Pokud jde o tu databázi, jistě by byla zranitelnější než ta současná, ale uživatel by třeba mohl mít možnost volby, kterou chce použít. Proto jsem tolik mlel o těch backendech a modulech.
Kdysi dávno jsem Mandrivu měl a i tam byla možnost stáhnout balíček se zdrojovým kódem a nechat ho zkompilovat. Ne že by to vždy fungovalo a ne že by to bylo snadné, ale šlo to, dokonce přímo přes ty jejich příkazy urpmX. Pokud jde o portovatelnost, to byla spíš moje snaha zdůvodnit, k čemu je dobrý kompilovaný update i pro binární distribuce. Pro Mandrivu by to jistě k ničemu nebylo, ale tohle je jiný případ - ArchLinux je přece jen nízkoúrovňová distribuce. S tou správou platformy je to těžké, protože vlastním dva Intely a jinak nic. Spíš jsem se snažil zdůvodnit, k čemu by případně mohl být dobrý kompilovaný update.
Je mi jasné, že remcaly nikdo nemá rád, ale mým cílem nebylo remcat. Spíš jsem chtěl nenápadně pošťouchnout případné zájemce o tuhle problematiku a zjistit, zda by náhodou někdo neměl zájem spolupracovat na vytvoření nějakého balíčkového systému.
ABS je skvělý systém, který v podstatě každý týden používám na update systému pomocí skriptu, který jsem do blogpostu napsal. Pak mám ještě jiný, který do ABS nenápadně podstrčí moji vlastní konfiguraci kernelu, ale to už je zas jiná pohádka. Pro mě (a nejsem jistě sám) je ABS středobodem zájmu v této distribuci a rozhodně ho nepovažuji za okrajovou záležitost. Balíčky z AUR stahuji výhradně jako PKGBUILD, je-li dostupný.
Samozřejmě nepochybuji o tom, že ArchLinux se profiluje jako binární distribuce a že tato filosofie má spoustu výhod. Jenže mnou navrhovaný balíčkový manažer by se nejspíš zdaleka neomezoval jen na ArchLinux a jen na binární distribuce. Zatím je to samozřejmě jen pohádka, ale taková byla idea. Proto považuji za zcela přirozené, že by se měl umět správně vypořádat i s kompilací, včetně kompilovaného updatu.
Abych řekl pravdu, názor, že ten nebo tamten frontend je zbytečný, mi připadá poněkud příliš ortodoxní. Neříkám, že by měli vývojáři ArchLinuxu něco takového vytvořit, ale mám za to, že by časem takový frontend vznikl a rozhodně by nebyl ke škodě. Dokonce nevylučuju, že i já bych ho používal, pokud by byl dobrý.
Donedávna jsem byl odpůrcem grafických udělátek na instalaci software, ale vyzkoušení systému PC-BSD, který má krásného softwarového manažera integrovaného přímo do Ovládacího centra KDE mě přesvědčilo, že to může mít smysl a nemusí vždy jít o nefunkční klikátko pro lamy.
Jistě, ovládání pacmanu je jednoduché, ale pořád se mi zdá, že dělá příliš mnoho věcí naráz. Chápu, že na to máte jiný názor, ale pořád jsem přesvědčen, že by se mělo důsledně oddělit jádro se základní logikou od síťové komunikace, práce se soubory, ukládání metadat a frontendu. Protože jsem tento návrh neomezoval jen na ArchLinux, samozřejmě jsem počítal i se zakomponováním ABS do základní příkazové sady.
Pevně věřím, že se mi podaří najít čas na nějaké úpravy. Přesto si ale myslím, že nemá smysl se vrtat v kódu, s jehož návrhem od základu příliš nesouhlasím. Proto jsem spíš chtěl vyvolat debatu o návrhu možného univerzálního balíčkového systému, který by se podobal pacmanovi ve všem kromě návrhu.
Pokud jde o posílání patchů vývojářům, kdysi dávno jsem poupravil spouštěcí skripty tak, aby přímo podporovaly WPA. Tenkrát šlo WPA v ArchLinuxu zprovoznit jen při současném použití síťových profilů, což mi nepřipadá rozumné, zejména vezmete-li v úvahu, koli věcí zvládá wpa_supplicant zcela automaticky. Proto jsem doplnil skript network tak, aby k podopoře WPA nebyly nutné síťové profily. Poslal jsem svůj návrh do některé z těch diskusí - už si nepamatuju, kam vlastně. Nesetkal jsem se s žádnou odezvou, takže jsem tu věc nechal plavat, zejména kvůli nedostatku času. Je taky dost dobře možné, že tohle už dávno bylo vyřešeno jinak.
25.4.2007 18:11
vogo | skóre: 34
| blog: "Skládat papír"
.
Párkrát se to tam (v diskuzi na arch) řešilo, stanovisko bylo, že databáze by byla příliš složitá, zaváděla by závislosti a (prý) by to bylo pomalejší . Což je blbost (obzvláště u sqlite), na kterou si vzpomenu, kdykoliv čekám až pacman "dochroustá" a začne něco dělat. Vůči tomuhle zpomalení tam doporučovali jakousi jednoduchou "defragmentaci" (snad něco smazat nebo kýho hroma co), ale já jsem tím dost otráven na to, abych to řešil.
Ty problémy s kódem, frontendy by snad měl pořešit 3.0 a libpacman. Arch je zamýšlen primárně jako binární, zkoušeli jste yaourt s možností "--aur"?
.
Já mám ReiserFS na rychlém stroji a ext3 na pomalém. Nerad to říkám, ale na tom ext3 to funguje stejně rychle... Takže je otázka, jestli zrovna pro tenhle druh nasazení je ReiserFS opravdu tak ideální.
Ale je to samozřejmě individuální. Každý má jiný hardware a podobně. Nebo že by tomu ReiserFS nesvědčil anticipatory scheduler? No to je možné, ale CFQ scheduler zase nesvědčí mým empétrojkám, a to ani trochu, takže teď aby si člověk vybral, že ano...
(To ovšem platí bohužel jen pro dotazy, nikoliv pro zápis metadat při aktualizaci balíčků. Tam už je to zas tradičně bídné.)
Vůči tomuhle zpomalení tam doporučovali jakousi jednoduchou "defragmentaci" (snad něco smazat nebo kýho hroma co), ale já jsem tím dost otráven na to, abych to řešil.
pacman-optimize
Ale že by to nějak fungovalo, to se říct nedá. Zrychlilo mi to pacmana možná o třetinu a jen do doby, než jsem zase udělal pořádný update systému. Nejspíš to tu databázi jen zkomprimuje, smaže a znova zapíše, aby se případné fragmentované malé soubory zapsaly spojitě. Nebo to špatně chápu, to je taky možnost...
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz