Americký výrobce čipů Intel propustí 15 procent zaměstnanců (en), do konce roku by jich v podniku mělo pracovat zhruba 75.000. Firma se potýká s výrobními problémy a opouští také miliardový plán na výstavbu továrny v Německu a Polsku.
MDN (Wikipedie), dnes MDN Web Docs, původně Mozilla Developer Network, slaví 20 let. V říjnu 2004 byl ukončen provoz serveru Netscape DevEdge, který byl hlavním zdrojem dokumentace k webovým prohlížečům Netscape a k webovým technologiím obecně. Mozille se po jednáních s AOL povedlo dokumenty z Netscape DevEdge zachránit a 23. července 2005 byl spuštěn MDC (Mozilla Developer Center). Ten byl v roce 2010 přejmenován na MDN.
Wayback byl vydán ve verzi 0.1. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána nová verze 6.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově se lze k síti Tor připojit pomocí mostu WebTunnel. Tor Browser byl povýšen na verzi 14.5.5. Thunderbird na verzi 128.12.0. Další změny v příslušném seznamu.
Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Na systemd nemám moc vyhraněný názor, ale tyhle argumenty vypadají celkem rozumně.
Co by mě ale zajímalo (a zatím jsem neměl čas to zjistit):
Odpověď na první otázku je hodně subjektivní. Podle mého názoru ano. ls -l /lib/systemd/**/*.service(.) |wc -l
mi ukazuje cca přes stovku služeb. Libovolnou z nich lze nahradit vlastní implementací. Většina z nich je binárka a nikoliv shell scripty, což u spousty lidí vyvolává zděšení, protože se nemůžou operativně vrtat v implementaci spouštění služby, pokud se objeví problém. Těmto lidem se pak jeví systemd jako všepožírající (a nemodulární) moloch.
Nikde není ale dáno, že služba musí být binárka, může to být i shell script. Požadavky na službu pro systemd jsou menší než v případě klasických unixových deamonů (detaily např zde: systemd-psani-unixovych-demonu
Odpověď na otázku číslo dvě snad ani objektivní být nemůže. Všechny služby poskytují (díky systemd) rozhraní pro spuštění/zastavení/restart/zjištění stavu služby. Hodně služeb poskytuje svoje rozhraní skrze sběrnici D-Bus, jiné mají jen socketové rozhraní. Rozhraní služeb nemá se samotným systemd nic moc společného. ( Pokud opominu to, že služby lze startovat na požádání pokud přijde požadavek na dbus rozhraní )
Pokud bych měl srovnat např. službu consolekit versus systemd-logind, tak je to nebetyčný kvalitativní posuv. Ale, že systemd-logind d-bus rozhraní zůstane tak jak je navrženo dalších 5 let? Tak za to bych ruku do ohně nedal.
Díky za odpověď.
Odpověď na první otázku je hodně subjektivní. Podle mého názoru ano. ls -l /lib/systemd/**/*.service(.) |wc -l mi ukazuje cca přes stovku služeb. Libovolnou z nich lze nahradit vlastní implementací. Většina z nich je binárka a nikoliv shell scripty, což u spousty lidí vyvolává zděšení, protože se nemůžou operativně vrtat v implementaci spouštění služby, pokud se objeví problém. Těmto lidem se pak jeví systemd jako všepožírající (a nemodulární) moloch.
S binárkami nemám až tak problém (pokud k nim mám zdrojáky :-). Spíš mi šlo o to, zda jde zkompilovat třeba jen některé služby – některé nekompilovat a nahradit si je v distribuci vlastní implementací.
Čekal bych, že výsledkem kompilace bude několik (možná desítek) balíčků, které budou mít mezi sebou různé závislosti. A já budu moci některé ty komponenty vyřadit nebo nahradit vlastní implementací dané služby.
Rozhraní služeb nemá se samotným systemd nic moc společného.
Se samotným systemd (ve smyslu init systém) asi ne, ale se systemd (které chápu spíš jako kolekci různých služeb/programů) ano. A ty aplikace (např. KDE) se stávají závislé na té kolekci služeb/programů, ne na samotném init systému.
Pokud bych měl srovnat např. službu consolekit versus systemd-logind, tak je to nebetyčný kvalitativní posuv.
Je klidně možné, že jednotlivé části systemd jsou hezky napsané a že přinášejí něco užitečného. Ale mám celkem obavy ohledně celkového návrhu, architektury a modularity.
Ale, že systemd-logind d-bus rozhraní zůstane tak jak je navrženo dalších 5 let? Tak za to bych ruku do ohně nedal.
Standard/specifikace není až tak o, že to bude pořád stejné, jako spíš o tom, že se věci budou měnit nějakým předvídatelným způsobem. GNU/Linux na desktopu, ale třeba i v mobilech, jde hodně rychle dopředu – a nemyslím si, že by bylo potřeba dělat nějaké rigidní standardy a fixovat něco na pět let dopředu. Klidně se může něco dohodnout/vymyslet a za půl roku nasadit do produkce. Ale měl by to být nějaký řízený proces. Ne že někdo namrská do gitu, co ho zrovna napadlo, a ostatní ať se z toho třeba poserou.
Ten protokol, kterým se komunikuje po soketu, nebo to D-Bus rozhraní, by mělo být někde zdokumentované – ovšem ne zpětně po implementaci, ale dopředu – měl by vyjít standard určité verze (mělo by se dodržovat sémantické verzování) a k tomu by měla vyjít referenční implementace opět pod nějakou verzí. Měl by existovat plán, jak často bude vycházet standard a jak dlouho bude referenční implementace podporovat kterou verzi standardu. Mělo by to být co nejvíc zpětně kompatibilní, starý klient by měl fungovat s novým serverem. Nekompatibilní změny můžou přijít, ale musí být oznámeny s dostatečným předstihem a musí být řádně označené (inkrementací major verze).
Jakkoli tohle může někomu připadat jako „korporátní“ a „byrokratické“ uvažování, je to IMHO správně a způsob, jak neskončit v úplném bordelu.
Jak moc je systemd modulární?Nijak a ani to nieje v pláne. Jako samotný init by to používalo dosť ľudí, ale odhodíš jednu komponentu a sype sa to jak domček s kariet. Mám vyladený desktop dosť vecí si riešim sám a so systemd to proste nechodí. Skúšal som to na Archu a stratil hocijakú nádej že by sa to dalo nejak obísť. Tak možno uselessd.
wc
, to je zarucene dobra volba.
Na to by úplně stačilo, kdyby se nepsalo proti implementaci systemd, ale proti nějakému otevřenému standardu.
systemd bude může být hlavní proud, ale vedle toho by mohly existovat jiné implementace standardu v „alternativních“ distribucích nebo třeba v tom BSD.
KDE je maly projektHoly shit!
Tiskni
Sdílej: