OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
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.