Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
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.
Aktuální vývojová verze jádra je 3.4-rc2 vydaná 7. dubna. Obsahuje spoustu oprav; Linus se také rozhodl přetáhnout přípravné patche pro přepracování mapování DMA. To by ale měl být konec významných změn v tomto vývojovém cyklu. Odteď budu co se přetažení týče přísnější, vyskytlo se spousta „šumu“, nikoliv jen čisté patche. Krátký přehled změn naleznete v oznámení.
Stabilní aktualizace: za poslední týden žádné nevyšly. Verze 3.0.28, 3.2.15 a 3.3.2 se aktuálně revidují. Všechny tři verze obsahují dlouhý seznam oprav; jejich vydání se dá očekávat 13. dubna nebo později.
Více než osm let po vydání verze 2.6.0 Willy Tarreau oznámil, že už nebude vydávat žádné aktualizace řady 2.4. Pro potřeby těch, co z nějakého důvodu nemohou upgradovat, udržuje strom v gitu s občasnými opravami, ale bez jakýchkoliv záruk.
Vývojáři zabývající se bezpečností v jádře už nechtěli dále čekat na návrat wiki systému kernel.org. Proto najdete všechny informace k vývoji zabezpečení v jádře na kernsec.org. Obnova obsahu wiki kernel.org ještě asi chvíli potrvá.
Plánovače na bázi deadline se tu už mnohokrát diskutovaly. Ve zkratce jde o to, že namísto priorit ohodnocuje deadline plánovač každý proces maximálním potřebným procesorovým časem a termínem („deadline“), do kterého musí daný čas obdržet. Správně napsaný deadline plánovač je schopen zajistit, že každý proces dodrží dané termíny a odmítne přitom jakoukoliv úlohu, která by způsobila nesplnění termínu. Patche doplňující deadline plánovač do Linuxu už existují několik let, ale jejich cesta do jádra byla poněkud pomalá, v poslední době dokonce velmi pomalá, protože hlavní vývojář se začal věnovat jiným projektům.
Juri Lelli se stal novým vývojářem těchto patchů; Juri zaslal novou verzi těchto patchů, aby nanovo rozjel diskuzi. Patch se od posledně moc nezměnil: reaguje na připomínky a má lepší mechanismus pro migraci. Plánem je opravovat nedostatky, aby se deadline stal vhodným pro produkční nasazení a aby se nakonec dostal do hlavní řady jádra. Proto vznikl nový Git repozitář, dále pak aplikace pro testování deadline plánování a mailing list. Dá se očekávat, že Juri bude vděčný za patche a testování.
"Kontejnery" se dají považovat za lehkotonážní podobu virtualizace. Virtualizovaní hosté vypadají, jako by běželi na svém vlastním dedikovaném hardwaru; kontejnery zato běží na jádře hostitele, jenže v prostředí, které dává iluzi, že mají celé jádro pro sebe. Výsledek je efektivnější; na jediném systému je obvykle možné provozovat více kontejnerů než virtualizovaných systémů. Nevýhodou z pohledu uživatele je flexibilita; virtualizovaní hosté mohou mít vlastní jádro a mohou tedy provozovat libovolný operační systém. Hosté v kontejneru musí používat to jádro, jaké používá hostitel.
S kontejnery se pojí další nevýhoda, kterou uživatelé nemusejí nezbytně zaznamenat: jejich jaderná implementace je v mnoha ohledech značně komplexnější. V systému, který podporuje kontejnery, musejí všechny globálně viditelné prostředky být zaobaleny ve vrstvě jmenného prostoru, který každému poskytuje vlastní pohled. Na linuxovém systému je spousta prostředků: například ID procesů, souborové systémy nebo síťová rozhraní. Dokonce i název systému a čas se mohou mezi kontejnery lišit. Následkem toho je to, že navzdory rokům snažení Linuxu stále chybí pořádná podpora kontejnerů, i když podpora virtualizace má už dlouhou dobu stabilní základy.
Práce na implementaci kontejnerů ale pokračuje; posledním dílkem je nová sada patchů pro uživatelské jmenné prostory od Erica Biedermana. „Uživatelský jmenný prostor“ lze vnímat jako zaobalení ID uživatele/skupiny a souvisejících práv; umožňuje vlastníkovi kontejneru být uživatelem root v rámci daného kontejneru a přitom izolovat zbytek systému od uživatelů v kontejneru. Náležitá implementace uživatelských jmenných prostorů byla z řady různých důvodů vždy problémem. Jaderný kód byl napsán s předpokladem, že každý proces má jedno, globálně uznávané UID; co se stane, když bude proces mít vícero UID v různých kontextech? Není obtížné si představit, jaké chyby by mohli vývojáři s UID udělat – šlo by o chyby, které by mohly vést k bezpečnostním chybám v hostitelském systému. Obavy z takových chyb a samozřejmě i obecná složitost problému způsobují, že se do jádra plná podpora uživatelských jmenných prostorů ještě nedostala.
Ericův patch na to jde trochu jinak, ve snaze zneviditelnit uživatelské jmenné prostory a současně odhalit chyby v kódu, hned jakmile jsou napsány. Proto patch zavádí nový typ, který má vyjadřovat „jaderná UID“ – kuid_t; pak je tam i typ kgid_t. Jaderné UID má popsat identitu procesu na základním systému bez ohledu na jakákoliv UID, která se vyskytují v kontejnerech; je to hodnota, která se používá hlavně při ověřování práv. Jaderná ID procesu se mohou (nebo nemusí) lišit od ID viditelných v uživatelském prostoru; proces to nemá jak poznat. Jaderná ID existují pouze za účelem ověření identity procesu v jádře samotném.
Ve zmiňovaném patchi je kuid_t typedef na strukturu s jediným polem; hlavním důvodem jeho existence je nebýt typově kompatibilní s obyčejným integerem [celočíselným typem], který se v jádře používá pro UID a GID. ID specifická pro kontejner mají původní integerové typy (uid_t a gid_t). Následkem toho je to, že jakákoliv snaha míchat jaderná ID s ID specifickými pro kontejner skončí chybou při kompilaci. To by mělo zneškodnit celou skupinu potenciálních chyb.
Typ uid_t, který je při používání v jádře neprůhledným typem, potřebuje sadu pomocných funkcí. Porovnání lze například dělat pomocí funkcí jako uid_eq(); podobné funkce existují pro většinu aritmetických porovnání. Pro většinu užití to postačuje. Bez ohledu na jmenný prostor jsou údaje o procesu uloženy v globálním prostoru kuid_t, takže většina porovnání ID funguje správně.
Občas je nutné udělat konverzi mezi jaderným ID a UID nebo GID v konkrétním jmenném prostoru. Nejsnazším příkladem je systémové volání jako getuid(); mělo by vrátit ID specifické pro daný kontejner, nikoliv pro jaderné ID. Pro tyto konverze existuje sada funkcí:
kuid_t make_kuid(struct user_namespace *from, uid_t uid); uid_t from_kuid(struct user_namespace *to, kuid_t kuid); uid_t from_kuid_munged(struct user_namespace *to, kuid_t kuid); bool kuid_has_mapping(struct user_namespace *ns, kuid_t uid);
(Obdobná sada existuje samozřejmě i pro GID.) Konverze mezi jaderným ID a ID v rámci uživatelského prostoru vyžaduje používání mapování uloženého v jmenném prostoru, takže při používání je třeba dodat informaci o tom, o který jmenný prostor se má jednat. V případě kódu, který se spouští v kontextu procesu, stačí pro získání ukazatele na jmenný prostor zavolat current_user_ns(). make_kuid() převede UID z jmenného prostoru na jaderné ID a from_kuid() udělá zase opak. Pokud mezi ID není žádné mapování, funkce vrátí -1; v případech, kdy je nutné vrátit platné ID, volání from_kuid_munged)) vrátí speciální hodnotu „neznámého uživatele“. Jestli je mapování dostupné, se dá zjistit pomocí funkce kuid_has_mapping.
Nastavení samotného mapování musí udělat administrátor, který pravděpodobně vymezí rozsah ID pro kontejner. Patch kvůli tomu přidává do /proc/pid/ několik souborů; nastavení mapování je jen otázkou zapsání jedné nebo více množin tří čísel do /proc/pid/uid_map:
first-ns-id first-target-id count
first-ns-id je první platné UID v daném jmenném prostoru. Pravděpodobně to bude nula – ID roota je ve jmenném prostoru platné a neškodné. Toto první ID bude mapováno na first-target-id definované v nadřazeném jmenném prostoru a count je počet následujících ID, která v budou součástí mapování. Pokud se použije struktura několika úrovní jmenných prostorů, může vzniknout několik vrstev mapování, ale ty budou zploštěny mapovacím kódem, který si pamatuje jen přímé mapování z a na jaderné ID.
Vytváření mapování rozhodně musí být privilegovanou operací, takže proces, který je chce vytvořit, musí mít nastavenou capability CAP_SETUID. Proces běžící jako root v rámci svého jmenného prostoru může tuto capability mít, i když nemá k okolním prostorům přístup. Takže procesy v uživatelském jmenném prostoru si mohou sestavit vlastní podprostory s libovolnými mapováními – ale tato mapování mohou přistupovat jen k UID a GID v rodičovském prostoru. Dalším omezením je to, že mapování ID může být nastaveno jen jednou; poté už je neměnné.
Tyto mapovací funkce najdou využití na řadě míst v jádře. Jakékoliv systémové volání, které pracuje s UID a GID, musí obsahovat konverze z a do prostoru jaderných ID. Systémy souborů ext* umožňují určení UID, která mohou používat vyhrazené bloky, takže kód souborového systému musí pracovat s jadernými ID při porovnávání. Patch je tedy trochu intruzivní, ale Eric se jednoznačně snažil jeho dopad minimalizovat. Zejména se snažil o to, aby režie spojená s mapováním ID byla nejlépe nulová, pokud není v jádře podpora jmenných prostorů aktivní.
Jak říká, funkce uživatelských jmenných prostorů má řadu zajímavých vlastností:
S mou verzí jmenných prostorů se už nemusíte bát toho, že root v kontejneru zapíše do souborů v /proc nebo /sys a změní tak chování systému. Ani se nemusíte bát zpráv předávaných přes unixové sokety d-busu.
Aplikacím bez capabilities umožňuje používat vícero UID a implementovat oddělení oprávnění. Dovedu si představit, že takovéto jmenné prostory mají potenciál učinit linuxové systémy bezpečnějšími.
V době psaní tohoto textu bylo k patchi jen pár připomínek, takže nebylo jisté, jestli ostatní vývojáři s tímto zhodnocením souhlasí, nebo ne. Povaha práce na jmenných prostorech způsobuje, že dostat implementaci do jádra bude obtížné, protože vývojáři mohou mít obavy z režie a nemusí je přínosy až tak moc zajímat. Ale díky rokům úsilí se většina práce do jádra dostala tak jako tak, takže je tu šance, že se to nakonec povede i jmenným prostorům.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Opet tentyz stejny problem, jako s pameti. Vpsfree prideluje neco, co proste nema.Já už nevím - ty snad buď schválně lžeš, nebo ze sebe děláš blba. Už ti tady bylo několikrát vysvětleno, že OpenVZ se s VMware nedá takhle srovnávat, protože to v podstatě není virtualizace. A taky už ti bylo několikrát vysvětleno, že ten limit velikosti paměti je limit na celkový součet virtuální paměti procesů v kontejneru, který je vždy větší - a zpravidla o dost - než kolik ty procesy nakonec reálně využijí. Že to vychází naprosto v pohodě, se může každý snadno přesvědčit sám - https://prasiatko.vpsfree.cz/munin/ - doporučuju prohlídnout si zejména položku cache - stroj, který trpí nedostatkem paměti, takhle rozhodně vypadat nebude.
Já už nevím - ty snad buď schválně lžeš, nebo ze sebe děláš blba.
No pravda se ukáže snadno. Na stránkách VPS free je napsáno: "RAM: 4096 MB virtuální paměti". Odpověz mi po pravdě na otázku, jestli si každý z provozovaných virtuálů může alokovat a reálně použít 4GB paměti. Děkuji za odpověď. Ano vím, co to je virtuální pamět, ano vím, co to to je overcommit.
Ostatně, to co píšu nakonec potvrzuje i Snajpa v rozhovoru na rootu, kde píše, že plánují _snížit_ limit na 2GB, protože openvz už bude umět počítat obsazené stránky.
Ale já jsem se o tomto tématu opravdu hádat nechtěl. Jestli vám to funguje, je to k vašemu dobru. Jen jsem chtěl upozornit na problémy v ostrém produkčním nasazení, kdy často jedou všechny VS na max (co se paměti týče, cpu moc problém není, mě spíše zajímali problémy s cpu a schedulerem, co Snajpa naznačoval) ve stejnou dobu (špičce) a proto je nutné držet přidělenou pamět pod fyzickou. Takovýto typ záteže by vpsfree neustál.
Grafy z produkčního prostředí bohužel doložit nemůžu, ale je tam krásně vidět, že všechny VS vykazují v podstatě stejnou křivku zátěže a spotřebovávají zdroje ve stejnou dobu. Proto nelze použít ani memory baloon (kvm, vmware).
Odpověz mi po pravdě na otázku, jestli si každý z provozovaných virtuálů může alokovat a reálně použít 4GB paměti.Odpovím protiotázkou: řídíš se tím, co se v reálném provozu může stát, nebo tím, se děje? V tom prvním případě bys měl na vmware přidělovat více paměti, než máš, protože to vyřeší balloon. V tom druhém není na tvoji otázku potřeba odpovídat.
Ostatně, to co píšu nakonec potvrzuje i Snajpa v rozhovoru na rootu, kde píše, že plánují _snížit_ limit na 2GB, protože openvz už bude umět počítat obsazené stránky.Je otázka, jak moc je to opravdu snížení, když se jedná o jiný limit - tzn. spousty uživatelů se to nemusí vůbec dotknout, protože při nějakém konkrétním způsobu využívání VPS programy nevyužívaly tolik paměti, o kolik si řekly.
Jen jsem chtěl upozornit na problémy v ostrém produkčním nasazení, kdy často jedou všechny VS na maxTo ale přece závisí na způsobu nasazení. Jestli máš každý VS = webserver s DB (např.), tak je vcelku očekávatelné, že budou mít podobné špičky. Kdežto když se každý VS využívá jinak (což je AFAIK situace vpsfree), špičky se rozprostřou.
Odpovím protiotázkou: řídíš se tím, co se v reálném provozu může stát, nebo tím, se děje?
Obojím. Jak reálným stavem, tak i tím, co se může stát (a taky se dřív nebo později stane, pak je z toho reálný stav). Proto má každá virtuálka o dost víc prostředků, než běžně (protože špičky jsou často i stonásobek běžného provozu, takže místo 40MB náhle může být potřeba 4GB) potřebuje a proto je také součet prostředků přiděleným virtuálkám menší než je hw (to platí pro paměť a pro storage kapacity, s cpu problém není -- a ještě jsem se stále nedozvěděl to, čím začal tento thread, proč by s tím měl být problém v kvm). Takto se pokryjí špičky jednotlivých VS i stav, kdy všechny VS začnou běžet na 100% ve stejnou chvíli.
To ale přece závisí na způsobu nasazení. Jestli máš každý VS = webserver s DB (např.), tak je vcelku očekávatelné, že budou mít podobné špičky. Kdežto když se každý VS využívá jinak (což je AFAIK situace vpsfree), špičky se rozprostřou.
Jasně, psal jsem, že máte jinou pracovní zátež. Proto to může fungovat.
Ale zpět k nějaké plodnější diskusi. V RAM a CPU nějak není problém (já ho tam z praxe nevidím). Osadit server 64GB RAM a 24 (ht)cores CPU jde snadno. Co bych spíše uvítal a má to pořádně až vsphere5 je lepší řízení storage. Limitace IOPS, ioscheduler s ohledem na latence apod.
a taky se dřív nebo později stane, pak je z toho reálný stavPřiznám se, že u vpsfree nevím o případu, kdy by se tohle stalo, přičemž když dojde na nějaký výpadek, chodí maily
a ještě jsem se stále nedozvěděl to, čím začal tento thread, proč by s tím měl být problém v kvmJo, tak o tom nevíc víc, než co jsem nalinkoval
Co bych spíše uvítal a má to pořádně až vsphere5 je lepší řízení storage. Limitace IOPS, ioscheduler s ohledem na latence apod.Možná to ve vSphere dlouho neměli, protože se tohle má řešit na úrovni toho pole a ne na úrovni virtualizačního hypervisora. :(
Grafy z produkčního prostředí bohužel doložit nemůžu, ale je tam krásně vidět, že všechny VS vykazují v podstatě stejnou křivku zátěže a spotřebovávají zdroje ve stejnou dobu. Proto nelze použít ani memory baloon (kvm, vmware).Pokud je dost podobných virtuálek běžících na jednom hypervisoru, může se minimálně u KVM dobře uplatnit linuxí KSM (jestli to pomůže i u OpenVZ, to netuším).
U KVM tohle udělá proces kvm, v OpenVZ provozuješ programy přímo na hostiteli a běžné programy ten syscall nedělají, protože pro ně nemá smysl.Čekal bych, že programy typu Google Chrome nebo Apache v prefork módu, které spouští mnoho stejných procesů, tyto funkce využívat budou. Nicméně je to opravdu na libovůli aplikací, zatímco KVM to třeba u několika VM ze stejné šablony udělá pro celý virtualizovaný OS samo.
Já už nevím - ty snad buď schválně lžeš, nebo ze sebe děláš blba.Zas ty tomešoviny :).
Opet tentyz stejny problem, jako s pameti. Vpsfree prideluje neco, co proste nema.WTF? To přece dělají operační systémy už drahně let. Nebo si snad zakazuješ overcommit?
duvodu se najde hodne, ale vetsina se jich vaze ke context switchingu, multitaskingu a co tyhle procesy s virtualnimi CPU delaji na hostiteliO autonuma víš? Viz pidiprezentaci s benchmarkem, zbytek vygůglíš.