Lennart Poettering bemutatta a run0 nevű sudo alternatívát a systemd v256-ban

Linux
 
With systemd v256 we are going one step towards this. There's a new tool in systemd, called "run0". Or actually, it's not a new tool, it's actually the long existing tool "systemd-run", but when invoked under the "run0" name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it's *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under…

Folytatás itt.

( DirtY_iCE | 2024. 04. 30., k – 13:23 )

Nem tudtam mi hianyzik meg az eletembol...

I hate myself, because I'm not open-source.

Systemd rivákolás: na ez továbbra is világuralomra tör. Miért ne lehetne egy sudo kiváltó parancsot külön repoban, külön csomagolva fejleszteni?

Mastodon (meg Twitter) rivákolás: nagyszerű ez a jövő médiája, ha valakinek hosszabb mondanivalója van, azt szét kell vagdosni 15 darabra. Vagy inkább ne is legyen senkinek hosszabb mondanivalója, úgyis TLDR?

Mastodon (meg Twitter) rivákolás: nagyszerű ez a jövő médiája, ha valakinek hosszabb mondanivalója van, azt szét kell vagdosni 15 darabra. Vagy inkább ne is legyen senkinek hosszabb mondanivalója, úgyis TLDR?

 Szokj hozzá, mert egyeseknek kb. ez az elsődleges, másoknak meg a kizárólagos közlési felülete.

trey @ gépház

( soyer | 2024. 04. 30., k – 13:56 )

The tool is also a lot more fun to use than sudo. For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges.

Nem tudtam mi hiányzik... :D

( Z0l v | 2024. 04. 30., k – 14:34 )

Én azt várom hogy mikor fog a wayland és az X egyszerre bekerülni a systemd-be, mert legyünk őszinték, valami frankó GUI még hiányzik belőle…

( turul16 v | 2024. 04. 30., k – 14:42 )

date != apr.1

gyorsabb vagy lassabb ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( golgota | 2024. 04. 30., k – 15:22 )

Na ezen befostam: "I personally think that the biggest problem with sudo is the fact it's a SUID binary though – the big attack surface, the plugins, network access and so on that come after it it just make the key problem…"...hehehehe, pottering latott egy kibaszott lukat egy hatalmas betonfalban, erre elkezd sirni a luk miatt a szunyoghaloja mogul :D

komolyan mondom priceless :D

Azóta örülök a systemd-nek amikor Ubi 18.04LTS-en nem ment a névfeloldás.
Meg megtanultam a systemctl daemon-reloadot bármely FS/Disk/LUN törlés után, miután nálunk egyszer csak éjszaka megállt, egy szerver a miatt, mert elfeljtette a systemd, hogy milyen dolgok maradtak törlés után. A systemd eddig sok jót nem hozott szerintem.

Láttuk már ezt az érvelést a Wayland-nál is.

Az X11 azért szar™, mert minden alkalmazás látja a billentyűleütéseket, és így tud keyloggerként is viselkedni. Ezért a Wayland-ba szándékosan nem raktak ilyen lehetőséget. Aztán most mégis raknak, mert néhány alkalmazásnak kell a global hotkey support.

A legszánalmasasbb, hogy ezeket van, aki be is veszi.

Szerintem a Wayland egy ótvaros gány, amit nem most kéne korporatokrata erőszakkal és FUD-dal elterjeszteni, hanem 15 éve el se kellett volna kezdeni fejleszteni.

Az X11 egy ótvaros gány amit nem most kéne szép lassan kidobni, hanem 20 éve kellett volna megszabadulni tőle a francba. Olyan dolgokat nem tud alapból, hogy VSYNC.

Driver tudja. Igen, compositor nélkül is.

Monitor specifikus skálázás sem megy, ami így 2024-ben alap funkció kéne legyen. 

Szerintem nem alapfunkció, csak a 100 PPI-nél nagyobb pixelsűrűségű monitorokon, amiknek kevés létjogosultságuk van a grafikus/videós szakmán kívül, ami szakmának pedig még kevesebb létjogosultsága van Linuxon. A scaling egyébként is a grafikus toolkitek feladata egy olyan desktop környezetben, ahol 10 féle TK létezik és minden alkalmazást másikban írtak és a Linux egy ilyen desktop környezet.

"Driver tudja. Igen, compositor nélkül is." Próbáltam, nem működik. Valahogy windowson és macen nincsenek ilyen problémák.

"Szerintem nem alapfunkció, csak a 100 PPI-nél nagyobb pixelsűrűségű monitorokon" Az összes létező laptop, a felhasználók 99%-a laptopon dolgozik. Bedugom a laptopot a dokkolóba, máris két féle pixelsűrűség van.

nem működik

De igen, működik.

/etc/X11/xorg.conf:

Section "Device"
        Identifier  "Card0"
        Driver      "intel"
        BusID       "PCI:0:2:0"
        Option      "TearFree"           "True"
EndSection

Ha a full screen appok elrontják a TearFree-t, akkor még egy Option "DRI" "2" mehet bele.

Az összes létező laptop, a felhasználók 99%-a laptopon dolgozik. Bedugom a laptopot a dokkolóba, máris két féle pixelsűrűség van.

Ja, hogy a laptop gyártója azzal akart szemfényvesztő, illuzionális pluszértéket adni a gépnek, hogy Full HD kijelzőt rakott bele, amin már túl kicsik a betűk és a grafikus elemek? A hype-motivált konfigurációkért nehogy már az X11 legyen a hibás. Ezért jobb régi gépet használni, pl. 5. generáció alatt 14"-es laptopokban 1600x900 (PPI=131), 1366x768 (PPI=111) kijelzők vannak, amik nem térnek el annyit egy távolabbról nézett monitortól, hogy külön scaling kéne rájuk. Vagy pl. az én HP-Compaq 6715b-men 1280x800-as 15.4"-es (PPI=98) kijelző van, amin a 720p videók natívak és ha épp nincsenek fossá-húggyá tömörítve, akkor tűélesek. Ezt az irodában 22"-es régi 1680x1050-es (PPI=90) monitorokkal használom, amiket nyilván távolabbról nézek, mint a laptop kijelzőjét, így érzésre nincs különbség a megjelenített képi elemek mérete között.

A fullHD laptop már alap, lassan már QHD, meg 4K lesz inkább.

Pont ugyanolyan feleslegesen, ahogy a Full HD is felesleges 14"-re.

Nem 2000 van.

2000 egy évszám. 2024 is egy évszám. Egyik se mond el semmit arról, hogy milyen hozzáadott értéke van egy 14"-be zsugorított 4K kijelzőnek pl. egy fejlesztői vagy irodai célokra használt laptop esetén (semmilyen).

Korom, kémény, felír: valamiben egyetérünk :-) Amit eddig a wayland-ból láttam, azt köszönöm, de ha lehet, nem kérném... Az, hogy bizonyos driverek, illetve X-szerverek a szabványt rosszul/részlegesen implementálják, az nem a szabvány, hanem az implementáció hibája. Oké, amikor SGI-n futó GL-es, vagy Sun Solaris-on futó Motif-os alkalmazást próbáltam "átlőni" Linuxos felületre, akkor azért voltak problémák... De egyik sem az X11 szabvány hibája miatt volt...

Korom, kémény, felír: valamiben egyetérünk :-)

Ennek örülök.

Amit eddig a wayland-ból láttam, azt köszönöm, de ha lehet, nem kérném...

Erre most majdnem szarkasztikusan reagáltam, de inkább felteszek egy kérdést. Milyen érzés, amikor bebizonyosodik számodra, hogy az újabb nem jobb? Hogy valamit, amin 15 évet dolgozott egy milliárdos multi, még mindig agyonver kompatíbilitásban, kiszámíthatóságban, stabilitásban egy 30-40 éves másik valami? Lehet, hogy ebből a példából kéne kiindulnod és a többi vitánkban se a szélsőséges ellenpontod keresgélnéd.

Az, hogy bizonyos driverek, illetve X-szerverek a szabványt rosszul/részlegesen implementálják, az nem a szabvány, hanem az implementáció hibája.

Ezt már csak a 15 éve stabil release-t produkálni nem képes szutykát erőltető Red Hat-nak kéne belátnia.

( Raynes | 2024. 04. 30., k – 15:24 )

A mester alkot, a gép (és kód) forog, áldja meg őtet a jóisten. Az kell ide, újabb systemd-s sallang. Szépen hízik a cuccos, csak az utóbbi években, homed, bsodd, most a run0 jön. Meg még sok más a jövőben, mert kell, mint egy falat kenyér. Remélem el lehet kerülni majd a run0-t, mint a homed-t.

Ahogy nézem, ez egy eleve létező megoldás volt, csak symlinket kap egy külön néven, és megváltozik a működése, így legalább enni nem kér.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( hajbazer v | 2024. 04. 30., k – 15:40 )

Tévedett, aki azt hitte, hogy Pöttering abbahagyta a Linux-világ felforgatását, amikor felmondott a Red Hat-nál.

Az aknamunka folytatódik.

Persze, ezt anno a vonatkozó HUP-os hírek alatt kommentekben írogattam többször is, hogy nem kell örülni, nem szabadultunk meg tőle. Épp úgy a systemd-n dolgozik, csak a fizetését, irodáját már nem a Red Hat biztosítja, hanem a MS, de ezt a mezváltást leszámítva semmi nem változott, épp úgy ő a systemd fő fejlesztője, és a jövőben is épp úgy fogja az irányokat meghatározni, vinni az egész projektet.

Amit elengedett, az a Pulseaudio, mert mások már a Pipewire/Wireplumber-ren dolgoznak, így azt neki már nem kell csinálni, teljesen a systemd-re tud koncentrálni, hogy nagyobb ütemben züllessze tovább.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Hajjaj, de még mennyire, sőt, folytatódik a történet tovább is. Ez a cikk ír róla az első bekezdés közepén, hogy a MS vett még fel emberkéket, akik a systemd-n dolgoznak. Tehát a mesternek érkezik az erősítés is, hogy többedmagával törjön világuralomra. És erre nem csak a személye garancia, hanem az a tény is, hogy akármihez nyúlt a MS, az mind arannyá változott, áldásos keze munkájuk mindig gyümölcsözött.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az aknamunka folytatódik.

Ez erosen hibadzik. NEM mr. pottering rak systemd-t az osszes disztroba. Nem tartott pisztolyt sem senkinek a fejehez, hogy ezt kell hasznalni.

O csak csinalt egy rendszert, amivel a mai, erosen integralt es egeszen duurva funkcionalitasu hardverek, mint laptop es egyebek, is tudnak linux alatt az elvart UX-et nyujtani.

Az osszes disztro megnezte, es valszeg arra jutottak, hogy az osszes opcio kozul meg mindig ez a legjobb UX-et nyujto, legeletkepesebb.

 

Ez ugyanaz, mint a docker/k8s: persze, lehet fujtatni ra, es tenyleg sokminden gaz benne, de nem ok nelkul terjedt el.

Ebben tényleg van valami. Nem Poetteringgel és a systemd-vel van baj, hanem azzal, hogy minden soydev barom arra dependeli a szutykát, lásd Gnome-osok meg még sokan mások. Ha nem lenne függősége semminek, simán le lehetne cserélni másik initrendszerre. Le lehet most is, csak a függőségek miatt továbbra is ott fog futni a háttérben valami részimplementációja, pl. elogind. Így hiába is hiszi az ember, hogy systemd-mentes disztróval elkerülte, nem kerülte el igazából, csak áltatja magát.

Erről valóban nem Poetterint tehet, ő nem tart pisztolyt senki bordája közé, hogy kötelező mindent a systemd-re dependelni. A legtöbb disztró csak azért adoptálta, mert látták előre, hogy mindennek függősége lesz, és nem akartak széllel szemben hugyozni. Pl. a Devuan-nál látszik, hogy milyen lassan megy nekik, mire minden verziónál minden csomagnál kigyomlálják a systemds részeket, mekkora kuli munka. Na, ezt nem akarták a mainstream disztrók bevállalni.

Utálom, de van azért előnye is. Pl. az összes initrendszer közül a systemd bootol a leggyorsabban, annak megy legjobban a párhuzamosítás. Illetve a systemd-boot is nagyon jó, de annak az a trükkje, hogy semmi köze nincs a systemd-hez, anélkül is használható, a systemd előtt is létezett projekt, gummiboot néven. Csak a systemd is adoptálta, így átnevezték.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ezzel annyiban vitatkoznék, hogy

1) amikor a disztrók a systemd mellett döntöttek, akkor az még nem azt takarta, amit ma.

2) a RedHat tolta erősen a systemd-t, ami elég meghatározó volt rengeteg open-source projektre. Az pedig, hogy a freedesktop-os projektek (pl gnome) elég erősen elkezdtek függőségeket kiépíteni a systemd dbus-os interfészeire, egyre nehezebbé tette, hogy a többi disztró más mellett döntsön.

Ettől függetlenül abban egyetértek, hogy a systemd (szigorúan mint init és service manager rendszer!) megold sok problémát, amit SysV init scriptekkel iszonyúan szenvedős volt megoldani (csináltam anno) és más alternatív init rendszerek (pl upstart) szintén semmit nem segítettek ezen a téren. Csak éppenséggel itt meg kellett volna húzni a vonalat és megállni, illetve ennek az alapfunkcionalitásnak a hibáit kijavítani. Már a journald-t sem lett volna szabad megcsinálni, nemhogy kötelező függőségként összeépíteni a systemd-vel.

Régóta vágyok én, az androidok mezonkincsére már!

( XMI | 2024. 04. 30., k – 16:50 )

Ahh yes, nothingbutthebest!

Gondolom a kedvencemet már sikerült kijavítani: https://bugzilla.redhat.com/show_bug.cgi?id=820448, http://bugs.freedesktop.org/show_bug.cgi?id=75680, de asszem ez egészen 2008-2009 környékéig nyúlik vissza.

Ja, megvan, doksival javították: https://github.com/systemd/systemd/pull/5239 leírták, hogy az sd-notify elveszti notification-öket. Ennyi, deal with it. Lehet végre új feature-t implementálni!

Régóta vágyok én, az androidok mezonkincsére már!

( bazso | 2024. 04. 30., k – 21:05 )

Már csak párat kell aludni és a systemd önálló Linux disztribúcióvá válik, és akkor nincs egymásra mutogatás, nincs kivételezés, ha valamit telepíteni akarsz, akkor azt pull request-ben kell feladni és a következő frissítésben már minden systemd hívő élvezheti a kedvenc szoftvered.

( khiraly | 2024. 04. 30., k – 22:20 )

En azt varom mar, hogy mikor unja meg Linus, es ir egy uj init rendszert, mint ahogy tette ezt a cvs/svn/bitkeeperrel es lett a git.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Caro | 2024. 05. 01., sze – 08:14 )

Látom szegény policykit még említést sem érdemel ebben a hírben, pedig az is mennyire tökéletes.

( gazsiazasz | 2024. 05. 01., sze – 16:35 )

macOS-en továbbra is lesz sudo, gyertek-gyertek! :)

sőt még ifconfig is van :)

( janikutya | 2024. 05. 02., cs – 07:48 )

Úgy két éve próbáltam megszabadulni a systemd-től Artixszal, de nem sikerült. Most tettem egy próbát Void linuxszal, és megy minden. Még a gaming is. Igaz, hogy kicsit döcögősebb, nem olyan automatizált mint a debian, de megy. Elég gyorsan. Tetszik... Az egész szemlélet, ami körüllengi ezt a projektet.

Én embedded Linux-okat kalapálok hébe-hóba, ott elég gyakori a régi SysVinit. Sokkal kisebb, mint a Systemd, és erőforrásszegény környezetben nem is feltétlenül lassabb. A Systemd csak akkor jobb, ha van 4, 8, vagy mégtöbb mag, amelyek SysVInit alatt nem tudnának párhuzamosan működni.

Sajnos, embedded-ben is terjed a Systemd. Egyik, amitől idegállapotba szoktam kerülni, a systemd-journald. A másik, meg a párhuzamos service indítás. Az utóbbi miatt a service-ek indítási sorrendje gyakorlatilag kiszámíthatatlan. Aztán ha van vmi HW összeférhetetlenség, akkor az egész boot folyamat kiszámíthatatlan. A végén úgyis az lesz, hogy a service-eket szépen egyesével sorba kell tenni, és akkor már ugyanott vagyunk, mint a SysVinit-tel.

Oszt mi nem sikerült? :) (Mármint artixszal?) Én évek óta használom, faszás. Én runittal használom, afaik a Void is azzal megy. Ha valamihez nincs runit script, egy shell scriptet kell leraknod, ami annyit biztosít, hogy ne daemonizáljon a main process.

Legyen itten példa:

$ cat /etc/runit/sv/xinetd/run
#!/bin/sh
exec xinetd -dontfork -syslog daemon

And thats it. Ennél jobb nincs.

Sajnos Lennart habitusa olyan, hogy ezek mind lepattannak róla.

Ő az, aki soha el nem ismerné, hogy rossz irányba indult el. Ha kiderül, hogy balra indult, pedig jobbra kellett volna, akkor kezdődik az igazi ámokfutása. Addig fúrja át világot, addig torzítja a téridőt, amíg valahogy a balra indulásból nem érkezik meg jobbra. Csak közben iszonyatos mennyiségű járulékos kárt okoz.

És most is ez lesz. Nem fogja azt mondani, hogy bocs, ezt tényleg benéztem, hanem jönni fognak a pty-re a cgroup-ok, meg kernelből policykit-re callback-ek, meg hasonló agyhalálok, hogy a mostani ötletét valahogy utólag mégis "secure"-rá lehessen tenni. Lehet reménykedni, hogy Linus és pár fontosabb kernel fejlesztő talán időben leoltja őket. Mint anno a kdbus esetén, amit hála az égnek, sikerült megtorpedózni.

Régóta vágyok én, az androidok mezonkincsére már!

Szerintem az egy tök más szituáció volt. Akkor még a Linux egyemberes hobbiprojekt volt, 0-közeli felhasználói bázissal. Senki nem látta előre (se Linus, se Andy Tannenbaum), hogy mivé fogja kinőni magát. Ráadásul Linus szándékosan Unix-kompatibilis rendszert kezdett fejleszteni (egy meglévő ökoszisztémához igazodott) és azóta is borzasztó erősen tartja magát és projektjét a "don't break userspace" elvhez.

Lennart esetén már adott a hatalmas ökoszisztéma, minden szoftver ami linuxon fut, és ő ennek az egészét jön megreformálni a remek ötleteivel. Ráadásul teszi ezt hatalmas corporate hátszéllel, teljes tudatában annak, hogy akármit is csinál az ledugódik az egész community torkán, akár tetszik, akár nem.

Régóta vágyok én, az androidok mezonkincsére már!

Dehogy igaz! Hosszas szavazások mentén (2014-től 2019-ig) döntötte el a _közösség_, hogy mi legyen. Senki sem tartott fegyvert a fejükhöz.

trey @ gépház

na ne csinaljunk mar belole martirt...egy bekepzelt pocs. Ismertem. Es nem arrol akar meggyozni hogy a fold nem lapos hanem gombolyu es a csillagok nem lukak az egen, hanem hogy ha ket nigger allat szendvicsbe kap, az valami kurvajo...ertem en hogy valaki azt szereti, de had mondjam mar el, hogy nekem nem olyan kifinomult az izlesem, mint pocstering urnak :D

Ha ez teged zavar hat ...na bazdmeg majdnem azt irtam sajnalom, pedig igazabol leszarom :D

Valljuk be, van annak valami diszkrét bája, amikor egy támadáshoz nem kell kódot írni, hanem közönséges off-the-shelf command line toolokkal lehet kivitelezni. :) Ráadásul mindössze 2 parancs kiadásával. :D

(amúgy a reptyr-t eddig nem ismertem, de hasznos projekt, ha valamit nem screenben indítottam el, és később jövök rá, hogy abban kellett volna)

Régóta vágyok én, az androidok mezonkincsére már!

( zeller | 2024. 05. 04., szo – 16:17 )

Virágozzék száz virág, azt mondom... Kérdés, hogy a "run0" hogyan viszonyul a sudo minimálisan "ki, honnan, mit, kinek a nevében" jogosultságkezeléséhez? Mert ha csak egy sima "futtasd uid=xxx userrel...",  akkor azért még bőven van mit reszelni rajta...