Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250812 mikrokódů pro své procesory řešící 6 bezpečnostních chyb.
Byla vydána nová verze 1.25 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
Byla vydána beta verze Linux Mintu 22.2 s kódovým jménem Zara. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze novou XApp aplikaci Fingwit pro autentizaci pomocí otisků prstů nebo vlastní fork knihovny libAdwaita s názvem libAdapta podporující grafická témata. Linux Mint 22.2 bude podporován do roku 2029.
Provozovatel internetové encyklopedie Wikipedie prohrál v Británii soudní spor týkající se některých částí nového zákona o on-line bezpečnosti. Soud ale varoval britského regulátora Ofcom i odpovědné ministerstvo před zaváděním přílišných omezení. Legislativa zpřísňuje požadavky na on-line platformy, ale zároveň čelí kritice za možné omezování svobody slova. Společnost Wikimedia Foundation, která je zodpovědná za fungování
… více »Byla vydána verze 2.0.0 nástroje pro synchronizaci dat mezi vícero počítači bez centrálního serveru Syncthing (Wikipedie). Přehled novinek na GitHubu.
Americký prezident Donald Trump se v pondělí osobně setkal s generálním ředitelem firmy na výrobu čipů Intel Lip-Bu Tanem. Šéfa podniku označil za úspěšného, informují agentury. Ještě před týdnem ho přitom ostře kritizoval a požadoval jeho okamžitý odchod. Akcie Intelu v reakci na schůzku po oficiálním uzavření trhu zpevnily asi o tři procenta.
Byl vydán Debian GNU/Hurd 2025. Jedná se o port Debianu s jádrem Hurd místo obvyklého Linuxu.
V sobotu 9. srpna uplynulo přesně 20 let od oznámení projektu openSUSE na konferenci LinuxWorld v San Franciscu. Pokuď máte archivní nebo nějakým způsobem zajímavé fotky s openSUSE, můžete se o ně s námi podělit.
Byl vydán Debian 13 s kódovým názvem Trixie. Přehled novinek v poznámkách k vydání.
WLED je open-source firmware pro ESP8266/ESP32, který umožňuje Wi-Fi ovládání adresovatelných LED pásků se stovkami efektů, synchronizací, audioreaktivním módem a Home-Assistant integrací. Je založen na Arduino frameworku.
Portál mojefedora.cz informuje o tom, že Wayland ve Fedoře 24 nebude výchozí.
Za poslední půlrok se udělalo velké množství práce a podařilo přidat velké množství funkcionality. Nicméně pracovní skupina kolem Workstation se shodla, že podpora Waylandu ještě není tak daleko, aby dokázal plně nahradit Xorg
Tiskni
Sdílej:
To mě spíš děsí zkazky o tom, jak to běhá přes Spice a VNC.Přesně. Veškeré virtuály implementují pouze nějaké primitivní framebuffery. V lepším případě jako bonus přídavky pro hosta (které jsou stejně zbytečné když jdou Xka vytunelovat ven na nativ) ve formě driveru pro Xorg. Nevím o jediném který by implmentoval GLES2 a pak to překládal pro grafickou kartu hosta nebo to SW kreslil. Jak soudruzi ze Sovětské svazu počítají že to bude fungovat ve virtuálních mašinách, to opravdu netuším.
Linux nebyl consumer desktop, byl stabilní, předvídatelný, uchopitelný a nesnažil se řešit nesmyslné consumer needs, ideální pracovní nástrojNemůžu souhlasit. Mnohé z těch consumer needs se shodují s tím, co bych od systému očekával. Navíc není pravda, že se je nesnažil řešit, jen se to prostě moc nedařilo.
Linux se se dere do pozice consumer desktop a snaží dodat funkce o které nikdo nestojí protože kdo používá linux na desktopu ví co dělá a proč to dělá a omalovánky, dotyk, mobile device hype ho nezajímajíNemyslím si, že je existence consumer desktopu problém. Já třeba momentálně na svém hlavním systému žádný z consumer desktopů nepoužívám. Sice občas cítím absenci consumer funkcí, ale je to něco za něco.
Nekonzistence napříč systémem pro dosažení consumer funkcí, vzhledu, dotyků, a jiných cool-ismůJakoby ten systém by předtím konzistentní.
no celkem to už už bylo konzistentní, gnome2 bylo naprosto vyhovující jak pro grafické stránce tak po stránce použitelnosti, stačilo rozvíjet a vylepšovat.Taky mi Gnome 2 přišel jako dobrá volba pro standard user experience (tzn. desktop pro ty, co si moc nevymýšlí) a kdyby se udělal několikaletý run na chyby a chybějící vlastnostni napříč celým desktopově používaným systémem, tak jsme dneska mohli být úplně jinde. Ale nebyli jsme a nejsme.
Vidím, kam se snaží linux na desktopu směřovatJá to popravdě nevidím. Naopak mám pocit, že je příliš mnoho vizí a příliš málo lidí, kteří by ty vize přenášeli do kódu a testovali. Podle mě nemá cenu se pouštět do hromady nového kódu pro koncové uživatele, pokud není možná kód stabilizovat a koncovým uživatelům doručit v použitelné podobě.
A naopak u OSX nemám pocit že je to něco za něco, prostě idealní pracovní nástroj....Neberu nikomu OS X ani Windows, ale moje preference jsou jinde.
crosscompile jsem nikdy nepovažoval za výhru, target platforma má své výhody.Jasne, takze krome ciloveho HW si jeste postavime vyvojarskou masinu na ktere budeme prekladat. A to samozrejme pro kazdou podporovanou platformu. Pokud vam todle prijde jako normalni reseni, nedivim se, ze se vam libi Apple ;)
no dyť já už po tvůrcíh nic nechci, já chci jen klid a funkční kladivo a tím už prostě Linux není, no ?Osobně si myslím, že ani nikdy nebyl. Naopak si myslím, že jestli se téměř univerzálně prosadí několik málo projektů s jasnou vizí (například Linux/Systemd/Wayland/Gnome a další) bude taková standardní distribuce mít k tomu OS X kladivu nejblíž. Já osobně k takovému kladivu netíhnu, jen se snažím shrnout fakta a něco z nich vyvodit.
Tak proč trávit další dekády laděním, když je možné už teď používat to co se snaží z linuxu udělat?Pro mě není OS X alternativou, takže asi tak.
Ano Linux je kernel a to je tak jediné co zůstalo v rozumném stavu. ale kdo ví, Redhat tlačí na pilu dost silně a je to znát v negativním slova smyslu ...imho.
Co konkrétního bych si pod tím "tlačením na pilu" měl představit?
Co třeba Debian, tam se taky tak dlouho tlačilo až se odhlasovalo, že se hlasovat nebude a šup systemd :)
Huh? To má být příklad, jak "Red Hat tlačí na pilu" ve vývoji jádra?
Na Linuse už se taky tlačilo, ale žadné obezličky pro systemd to kernelu neprošly..
To je dost svérázná interpretace. Nějaké věci, které se pro systemd hodily, byly přijaty, nějaké ne. A některé z těch druhých odmítli vývojáři a maintaineři, kteří jsou sami zaměstnanci RH. Vývoj jádra už dávno nefunguje tak, že Velký Linus osobně rozhoduje o každé featuře. A to, že se Lennart a jeho sekta snaží dostat do jádra věci, které by se jim hodily, ještě neznamená, že "Red Hat tlačí na pilu".
A pak jeho zaměstanci v delíriu absolutního narcismu povídají něco zahození posixu atd
Uvědomujete si, jak velká firma to je? Nemůžete každou vizi, kterou Lennart nebo Kay někde vyhlásí nebou napíšou, hned automaticky považovat za oficiální stanovisko jejich zaměstnavatele - a už vůbec ne za něco, co se Red Hat snaží násilím protlačit.
snaha je zcela jasná, bude ohýbat userspace a init a v poslední řadě kernel tak jak to RH potřebuje
Uvedete také nějaký konkrétní příklad, jak RH podle vás ohýbá jádro na úkor ostatních uživatelů pro své potřeby nebo budete dál jen mlžit a mávat katastrofickými scénáři a konspiračními teoriemi? Nemám rád, když lidé používají zkratku FUD k označení jakékoli demagogie, ale na to, co to předvádíte, sedí naprosto dokonale.
zejména pro své aktivity v oblasti kontejnerové virtualizace
Na jiném místě zase tvrdíte, že jejich cílem má být z Linuxu udělat "consumer desktop". Kromě toho, že mi přijde jako nesmysl cpát se mermomocí do oblasti, která by vyžadovala značné investice, má jednoho dominantního hráče a i ten začíná zjišťovat, že už v ní nedokáže vydělávat zdaleka tak snadno jako dřív, mi to přijde poněkud nekonzistentní. Zkuste si nejdřív sám ujasnit, co že to ten zlý Red Hat vlastně chce.
# service spamassassin status [ ok ] spamd is running. # service spamassassin stop Stopping SpamAssassin Mail Filter Daemon: spamd. # service spamassassin status [FAIL] spamd is not running ... failed! # service spamassassin start Starting SpamAssassin Mail Filter Daemon: spamd. # service spamassassin status [ ok ] spamd is running. # cat /etc/debian_version 8.3 # dpkg -l | grep sysvinit ii sysvinit 2.88dsf-59 amd64 System-V-like init utilities - transitional package ii sysvinit-core 2.88dsf-59 amd64 System-V-like init utilities ii sysvinit-utils 2.88dsf-59 amd64 System-V-like utilities
xsel
nebo vytvořili nějaký nový příkaz?
xsel
?
Nečetl jsem celé řešení v GNOME, nemám na to teď čas, ale původní návrh byl ten, že přístup ke schránce dostane aplikace nad kterou byl proveden middle click, jiné ne.To je pro mě zbytečně omezující.
ale ty jinak někde jinde čteš obsah této schránky bez paste middle clickem?Samozřejmě. Vždyť o tom píšu v komentáři, na který reaguješ.
sh -c 'xsel | xvkbd -no-jump-pointer -delay 10 -file - 2>/dev/null'
přístup ke schránce dostane aplikace nad kterou byl proveden middle clickA ty teď přicházíš s konfliktním:
přístup dostane aplikace, která má focusOčividně byste se měli nejdřív mezi sebou domluvit, jak to teda vlastně bude, a až teprve potom to prezentovat lidem, kteří nejsou nadšeni z každé novinky a chtějí na svých strojích normálně pracovat.
Tedy Klipper a xsel budou na whitelistu a ostatní si musí počkat na focus a nebudou čmuchat, co nemají.Jakože kterákoli aplikace pustí
xsel
a dostane data? Tak proč jí ta data nedáme rovnou?
Schránku/primary selection má smysl zabezpečit,Nemá cenu vynucovat zabezpečení schránky, pokud nemáš izolované aplikace. Omezuje to funkcionalitu bez jakékoli protihodnoty.
Pokud však nějaká aplikcae pobězí v kontejneru, tak její xsel (pokud ho vůbec bude mít), nebude na whitelistu a bude mít smůlu.1) Pak je nesmysl se zaměřovat speciálně na xsel a bohatě stačí aplikovat restrikce pouze na izolované aplikace. Je přece jedno, jestli aplikace získá data přímo nebo přes jinou binárku. 2) Takové řešení vyžaduje duplikaci xsel v systému, kdy různé binárky téhož programu budou mít přiřazena různá práva. To je z pohledu architektury zcela zbytečné omezení. 3) Nevidím důvod, proč při tak základním rozhodnutí předpokládat, že se izolace bude realizovat kontejnerem.
Abys mohl mít (v budoucnu) restrikce na schránku, je potřeba mít mechanismus, který je umožní.Předmětem sporu není existence mechanismu, ale umělá restrikce používané funkcionality pod záminkou hypotetické budoucí bezpečnosti.
Teď se to implementuje a je snadné tam ten mechanismus zavést, ale až to bude hotové a používané, budou zásadní změny obtížné.To si nemyslím, ale tak jako tak to není předmětem sporu.
Jak přesně ta pravidla budou vypadat a jak bude aplikace izolována je už jen detail.Tebou navrhovaný mechanismus bude s velkou pravděpodobností zcela nevhodný a pokud se ukáže, že mám pravdu, bude muset být od základu změněn nebo dokonce nahrazen. Detail by to byl pouze v případě univerzálního mechanismu, který by nestavěl na zcela nadbytečných předpokladech.
Client side alokácia je reálny problém. Mir mieri na mobilné telefóny a tam je tých pár desiatok MB pre každé otvorené okno navyše dosť cítiť.
Ok, tak sa nebavme o tom, čo je tenchnicky lepšie, ale čo tu bolo skôr. Žeby X?
K tomu som sa už vyjadril. Mir je technicky lepší a nepresadí sa čo je škoda. Na zariadenaich s obmedzenou pamäťou má zmysel použitie server side bufferov. Celé to podľa mňa zabije canonical svojim spôsobom "otvoreného" vývoja.
Mir je technicky lepšíV cem?
To sme videli asi úplne iný sailfish. To, čo som videl ja malo horšiu správu pamäte než najlacnejší čínsky android na trhu.