Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Phoronix hlásí dostupnost X.Org Server 1.8.0. Mezi nové vlastnosti patří např. podpora udev jako náhrada HAL na Linuxu nebo podpora xorg.conf.d. Oficiální oznámení ještě nevyšlo, ale v gitu už je nová verze označena.
Tiskni Sdílej:
V gentoo při včerejší aktalizaci xorg-server 1.7.6. Flag -hal používam někdy od verze 1.7.
Jen jsem nastavil flag, překompiloval x11-drivers, xdm a bylo to. Je to cca 3 měsíce, přesně si nevzpomínam.
ENV{ID_INPUT_KEYBOARD}=="?*", ENV{x11_driver}="evdev", ENV{xkblayout}="us,cz",
ENV{xkbvariant}=",qwerty",
ENV{xkboptions}="grp:alt_shift_toggle,terminate:ctrl_alt_bksp"
ENV{ID_INPUT_MOUSE}=="?*", ENV{x11_driver}="evdev"
nie je az taky problem spravit mapovanie 1:1 medzi hal a udev pravidlami.. aspon medzi tymi jednoduchymi
U nejjednodušších ano, ale obecně je syntaxe HALu podstatně silnější a umožňuje pravidla lépe a přehledněji strukturovat.
Zatim mi stačilo "X -configure" a s tim jsem jel.
když X server spadne, jsou všechny okenní programy v háji,To neni uplne pravda. Bez problemu jde napsat X program, ktery by prezil pad X serveru a po opetovnem prihlaseni znova vytvoril sve Xove objekty, ale nikdo to tak nedela. Co se tyce bezpecnostnich problemu X, tak jediny vyznamny dysledek je v tom, ze by se clovek nemel prihlasovat s povolenym X forwardingem na mene duveryhodne stroje. Ale co se tyce procesu jednoho uzivatele na jednom stroji, tam je to uplne jedno - procesy jednoho uzivatele od sebe stejne nejsou dost izolovane na urovni jadra a existuje spoustu moznosti, jak jeden proces muze ovlivnovat ostatni procesy stejneho uzivatele (treba moznosti pres soubory v /proc), ze jedna moznost navic uz nehraje roli. Bezpecne oddeleni aplikaci na urovni X serveru by se hodilo, kdyby bylo zvykem nektere procesy (treba webovy prohlizec) spoustet s nizsimi pravy nez jsou bezna uzivatelska prava.
Navíc se tam píše, že EWS překvapivě vyšel výrazně menší a jednodušší než Xka i s tím zabezpečením.
Pak se ovšem nabízí otázka, jestli opravdu umí všechno co X nebo jen to, co autoři považovali za důležité.
Pokud by tu paměť potřeboval jiný program (rozuměj začala by docházet), prohlížeč ji okamžitě uvolní.Tohle není pravda. Když začne docházet paměť, začne se swapovat a/nebo nastoupí OOM killer. Prohlížeč nemá žádnou možnost zjistit, že paměť dochází (rozhodně ne nijak moc přesně); navíc silně pochybuju, že by to nějaký dělal. A když si Opera nakašuje giga a půl stránek na systému s 2GB paměti celkem, tak to neustálé swapování je na výkonu poznat opravdu dobře, to mi věř.
Koneckonců v aktuálních verzích distribuce HAL stále je (a to i třeba ve vývojových jako OpenSuSE 11.3 M4), ono by totiž bylo dost nezodpovědné ho jen tak vyhodit bez adekvátní náhrady.Ono se intenzivně pracuje na jeho vyhození - třeba bug#590709. Problémem je, že přechod HAL -> něco jiného není na stránkách freedesktop.org dokumentován. Tak například z hlavní stránky projektu hal se člověk na UPower a UDisks nedostane. DeviceKit neobsahuje ani zmínku o tom, že je to deprecated.
append
, prepend
), rejstřík porovnávání nebo již zmíněné cílení pomocí @property:property
(oproti ATTRS{idVendor}
matchujícímu jak USB vendor id, tak PCI vendor id), vychází mi porovnání jazyků - kromě nejjednodušších případů - jednoznačně ve prospěch HALu. Možná mi ale jen chybí potřebná míra alergie na XML. :-)
…které jsou mizerně navržené jeden jako druhý.
Tak na tom asi nebude problém se shodnout.
třeba docela pomohlo, kdyby měl udev něco na způsob continuation lines z Bourne shellu.Niečo takéto?
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", \ ENV{ID_MODEL}=="IOMEGA_ZIP*", OPTIONS+="all_partitions", GROUP="floppy"(lebo takých pravidiel mám v udev/rules.d dosť veľa)
/* continue reading if backslash+newline is found */ while (line[len-2] == '\\') { if (fgets(&line[len-2], (sizeof(line)-len)+2, f) == NULL) break; if (strlen(&line[len-2]) < 2) break; line_nr++; len = strlen(line); }
Treba proto, ze spousta uzivatelu HAL nepouziva a nechce?Najde se zase spousta lidí (včetně mě), kteří jsou rádi, že něco jako HAL vůbec existuje. Mohu Vám důvěrně říci, že je celkem papačka rejpat se v konfiguraci udev, když chcete zprovoznit nějaké zařízení. Já si to docela užil s mob. telefony (NOKIA, SAMSUNG). A i když se Vám podařilo zařízení rozjet, nemusel jste mít pořád vyhráno, protože se docela často stalo, že od té chvíle zase nejelo něco jiného... ;)
HAL nedelal prakticky nic, co by Xka potrebovala. Natazeni spravneho kerneliho ovladace delal udev, natazeni spravneho Xkoveho ovladace si delaji Xka sama. Takze cele to je jenom otazka toho, prez jake rozhrani se budou Xka dozvidat o novych zarizenich zda pres kerneli, udevove nebo HALi rozhrani.Mám takový dojem, že se mýlíte. Minimálně zavádění kernelových ovladačů hlídá HAL. Udev pokud vím nedělá nic jiného, než že podle informací od jádra a pravidel ve své konfiguraci aktualizuje obsah v /dev a informuje přes D-BUS zbytek systému o tom, že něco provedl. Proto většinou mělo stačit nakonfigurovat HAL a ten se měl sám postarat o zbytek, včetně přidání odpovídajících pravidel do udev, a zjištění všech potřebných informací o nově přidaném/změněném stavu zařízení.
Osobne bych preferoval, kdyby Xka pouzivala rovnou kernelove rozhrani, ale to je tak pitome navrzene rozhrani, ze aplikace radsi komunikuji s udevem.Já osobně ne. Jak jsem psal výše jsem rád, že existuje alespoň nějaký projekt, který se stará o správu hardware v Linuxu. Možná není zn. ideál ale pořád lepší, než přímo ručně domlouvat udev a pak se ještě starat o správné a včasné načtení/odstranění ovladačů a potřebných modulů v jádře... A navíc, aby si to obstarávala každá aplikace sama - to by byl děs už vůbec.
Udev pokud vím nedělá nic jiného, než že podle informací od jádra a pravidel ve své konfiguraci aktualizuje obsah v /dev a informuje přes D-BUS zbytek systému o tom, že něco provedl.
To druhé dělá spíš HAL než udev. Na druhou stranu se dá udev přimět, aby na události reagoval v podstatě čímkoli - i když se k tomu účelu jeho rozhraní moc nehodí a sami autoři (nebo přinejmenším autoři dokumentace) to příliš nedoporučují.
V každém případě ale tvrdím, že pokud by měl udev převzít část práce HALu, bylo by nutné nejprve nahradit jazyk jeho konfiguračních souborů něčím přehlednějším a pokud možno i silnějším - přinejmenším nějaká forma cílení atributů (obdoba @property:property
) by byla nutností.
Udev takto komunikuje s HALem.
To se mi moc nezdá, kdyby nic jiného, tak udevd
není linkovaný proti libdbus
. Možná se v některé distribuci jako reakce na událost spouští něco, co dává HALu vědět přes D-BUS, ale ani tak bych to neformuloval, že udev posílá notifikace přes D-BUS.
Mám takový dojem, že se mýlíte. Minimálně zavádění kernelových ovladačů hlídá HAL.V davnych dobach automaticke zavadeni kernelovych modulu fungovalo tak, ze kernel primo spustil program modprobe (nebo skript hotplug) na fiktivni jmeno (bud odvozene od device node, na ktere se pristupovalo, nebo odvozene od vendor/device ID zarizeni, ktere se objevilo pri enumeraci) a zbytek zaridil program modprobe sam (prevedl fiktivni jmeno na skutecne jmeno modulu a to zavedl). Protoze caste spousteni tech hotplug skriptu dost zpomalovalo, zavedl se udev, ktery ceka na netlink socketu, po kterem se dozvida o udalostech (objevilo/zmizelo zarizeni, objevilo/zmizel device node) a podle konfigurace dela ruzne cinnosti. Mimochodem, protokol, pomoci ktereho je udev informovan, vznikl nejspis tak, ze se vzaly promenne prostredi, se kterym se drive spoustel hotplug skript, a to se zabalilo do netlink socketu. Takze striktne vzato se udev o zavadeni modulu nestara. Aby udev zajistil zavedeni modulu, staci mit v konfiguraci jedine pravidlo: ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}" To zajisti pusteni modprobe, ktery zaridi uz vse ostatni.
Najde se zase spousta lidí (včetně mě), kteří jsou rádi, že něco jako HAL vůbec existuje. Mohu Vám důvěrně říci, že je celkem papačka rejpat se v konfiguraci udev, když chcete zprovoznit nějaké zařízení. Já si to docela užil s mob. telefony (NOKIA, SAMSUNG). A i když se Vám podařilo zařízení rozjet, nemusel jste mít pořád vyhráno, protože se docela často stalo, že od té chvíle zase nejelo něco jiného... ;)Keď bola tá konfigurácia udev tak zložitá, prečo si nekonfiguroval HAL?