Elindult bétában a Devuan új weboldala, lassan stable kiadássá érik a 3.0 "Beowulf"

Debian

Az új struktúrát felvonultató béta weboldal itt.

( dejo v | 2020. 05. 08., p – 09:15 )

Ugye jól emlékszem ez a systemd mentes Debian fork?
A designja tetszik, de én haladok a mainstream-mel. :)

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Azt jelenti, hogy míg Debianban ugyan lecserélheted az initrendszert SysVInitre, de a repositoryban boldog-boldgtalan dependel a systemd-re, így ha nem akarod felrakni, akkor előbb-utóbb a fél rendszeredet forrásból kell felraknod. A Devuannál a systemd egyáltalán nem is szerepel a repositoryban, tehát nem is dependel rá semmi. Fel sem tudod rakni. Tehát de, systemd-mentes.

Oldschool Computer - http://oscomp.hu

Ez egyébként miért jó? Tényleg komolyan kérdezem.

A systemd már okozott kellemetlenséget de megtaláltam, megoldottam és megtanultam. A hiba egyébként a mysql gyári repuban lévő csomag egyik default unit beállításának hiánya volt, így korlátozta a process egyidejűleg megnyitható fájlok számát ami eredményeként nem tudtam 214 fölötti mysql connection számot eléárni, ezt felcsavartam 4096-ra és máris tudtam 1000 kapcsolattal tevékenykedni.

Két ok miatt:

1. A szabad szoftver a választásról szól. Az alternatívák versenyt hoznak, szabadságot adnak a felhasználóknak.

2. A systemd egy sok szemptonzból meglehetősen vitatott megoldás, egy amúgy valós és fontos problémára, ami elsősorban a desktop felhasználás igényeiből ered. (A systemd nem init rendszer, hanem egy teljes kernel feletti réteg.) Szóval fontos, hogy ne ez legyen az egyeduralkodó, legyen vetélytársa.

Az már más kérdés, hogy a sysvinit nem helyettesíti a systemd-t, csak egy funkcionalitását. Vannak egyébként valódi systemd alternatívák, jó volna, ha kapnának egy kis mainstream támogatást.

Nem.

Tegyük fel, ott a hozzászólás, alatta 0 szavazat, és van egy +1 gomb. Vagyis adhatsz egy szavazatot. Rákattintasz a +1-re, a korábbi 0 szavazat megváltozik 1 szavazatra, vagyis rögzítette a szavazatodat. Ha mégsem akarsz szavazatot adni, a korábbi szavazatod visszavonhatoda -1-re kattintással, és akkor a korábbi 1 szavazat visszaáll 0 szavazatra.

Ha még ezután se érted, akkor a második mondatod lesz igaz.

ami elsősorban a desktop felhasználás igényeiből ered.

Erre egy citation azért needed :) Az erősségei leginkább pont, hogy szerver/multiuser környezetben jönnek ki, nem desktop felhasználásnál.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Nekem úgy tűniik, hogy a systemd egy csomó funkciója a desktop rendszerek dinamikus változásainak kezelésére irányul. 

"Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things."

- power management
- device management
- mount points
- network configuration
- locale management

...

Nem nagyon követem a témát, de milyen magyarázatot hoznak a systemd fejlesztői mindennek a sok dolognak az egyben kezelésére?

Pl. miért jó szerintük, hogy mondjuk a syslog-ot vagy a hálózat konfigurálását a systemd intézi? Vagy más oldalról: mi volt a gond azokkal a különálló rendszerekkel, amik eddig ezekért a területekért feleltek?

Illetve pl. az is érdekel, hogy a korábban különálló udev forrását miért volt jó beolvasztani a systemd-be? (Megelégedéssel használtam az udevet éveken át systemd nélkül)

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ha tőlem kérdezed, nem tudok rá válaszolni. Én nem ismerem a systemd-t ilyen mélységebn. Csak arra próbáltam válaszolni, hogy miért gondolom, hogy a systemd funkcionalitást elsősorban a desktop igéynek hívták életre.

Azt nem feltételezem, hogy ennyi mindent kellene egybe integrálni, sőt. Eben inkább politikát, mint műszaki tartalmat látok.

Nem konkrétan tőled várnám a választ, bárki válaszolhat, aki tudja vagy sejti, mit írnak jellemzően magyarázatként, amikor ez a kérdés felmerül (feltételezem, nem én vagyok az első, aki megkérdezi)

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nagyjából: ami kötelező egy systemd rendszerhez, az a systemd (+udev), a journald és logind. A többi systemd-* már a systemd ernyőprojekt része, és mind opcionális komponens (pl. hostnamed, homed, importd, machined, timedated, timesyncd,  ...). Az utóbbiaknál leginkább a "miért ne?" volt az, ami létre hívta őket (mivel a systemd-vel egy repóban vannak, a kód nagy részét adó "plumbing" már ott van, pl. a hostnamed per pill 837 sornyi C kód, kiegészítve a 454 sornyi hostnamectl-lel), az, hogy ott vannak erősíti a rendszer menedzsment rendszer képet a systemdről (és nem utolsó sorban: szvsz. marhára hiánypótló, hogy a széttöredezett Linux rendszerek közt valamifajta egységesítést végez, ha már az LSB-nek ez annó nem sikerült).

Ha maradunk tisztán a kötelező komponenseknél... a journal össze lett drózotva a systemd-vel, hogy értelmes naplózást tudjon biztosítani (adott unit bejegyzései függetlenül attól, hogy hogyan lettek naplózva, meglegyenek - kivéve persze, ha közvetlenül fájlba naplóz a cucc); a rendszer-szinten kötelezővé tételnél az volt a mondás, hogy így tudja a boot folyamat korai részének naplóit is elkapni. A udev és a systemd elkezdett egymással kommunikálni (egyrészt a systemd reagálhat új HW megjelenésére, másrészt a udev átadott systemd-specifikus dolgokat, pl. a seat-ekre vonatkozó információt). A logind pedig a seat és user slice managementhez kellett, és kiváltotta az addigra már többé-kevésbé nem fejlesztett ConsoleKit-et.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

OK,

Szóval pl. az udev-nek miért kellett beolvadnia a systemd-be? Korábban systemd nélkül udev-et használtam, jó volt.

Miért lenne gond, ha lenne egy külön udevd meg lenne egy systemd, és egyszerűen beszélgetnének egymással, ahogy a beolvasztás előtt?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Szóval pl. az udev-nek miért kellett beolvadnia a systemd-be? Korábban systemd nélkül udev-et használtam, jó volt.

Miért lenne jobb, ha külön repóban lenne? :)

Disclaimer: a lentebb említett egyik projekt nevében sem beszélek, mind a saját véleményem.

És akkor a válasz: hogy működőképes termék legyen belőle. Szépen és jól hangzik a "jól definiált, standardizált interfészeken keresztül beszélgető komponensek" móka, ha ráérsz standardizálni az interfészt (és akkor az indulásra van több, egymással elvileg interkompatibilis implementációd), de egy idege a legtöbb sikeres projekt inkább integrálja a komponenseit (akár kód, akár deployment szinten) és saját hatáskörbe veszi azokat.

Mindig ezzel példálózom, de ott van a Samba. Működik a cucc, és azóta működik (azután jöttek ki alfából!), hogy dobták a kezdeti lelkesedést, hogy majd csak össze kell drótozni egy OpenLDAP-ot, egy Kerberost, egy Bind-ot és egy ntpd, aztán lesz AD DC. Aztán amikor ott volt, hogy jó, akkor az upstream projektekben ezt és ezt kéne módosítani, szépen jött a saját LDAP szerver (ma már portolhatnák OpenLDAP-ra, meg van hozzá benne a tranzakció kezelés, de már nem foglalkoznak vele), jött a saját szerverből futó, a kódbázisba bevágott Heimdal KDC (a RedHat-osok évek óta tolják MIT KDC alá és még mindig van egy csomó funkció, ami nem működik vele, pedig a Samba vonatkozó részét már átírták, hogy egy absztrakciós rétegen keresztül dolgozzon), egy darabig szórakoztak a fájl alapú DNS-sel, utána próbálták upstreamelni a DLZ módosításaikat a Bind-ba, de nem sikerült, úgyhogy lett saját DNS szerverük (utána release-re a Bind-ba bekerültek a DLZ patcheik, úgyhogy az is működik, pár év után meg dobták a fájl backendet a Samba-ból). És ezek csak a "külső" komponensek, a kódon belül kismillió esetben volt, hogy egy feladatra kerestek valami lib-et, volt 1-2-3 lehetséges, aztán írtak inkább sajátot.

Udev gondolom ugyanez lehetett pepitában: az integráláshoz mindkét irányú kommunikációra szükség van, ráadásul az udev-et fel kellett készíteni arra, hogy kövesse azokat a tulajdonságokat, amikre a systemd-nek szüksége van (újfent: fejből a seat management-et tudnám mondani). Meg lehetett volna úgy oldani, hogy minden udev -> systemd irányú adatközlésre csinálnak egy futtatható fájlt, a vonatkozó udev rule-ok meg kapnak egy EXEC-et, visszirányban meg ad az udev valamilyen interfészt. Mit értek volna el vele? Ugyanúgy meg lenne a coupling a két komponens között, mindkét komponens pontosan egy implementációval rendelkezik (*: az integrálás után forkolták az eudev-et!), tehát lenne egy felesleges interfész (ill. kettő, mert mindkét irány játszik)...

És félre ne érts, én is szerencsésebbnek tartanám, ha szép, tiszta, egységes interfész lenne minden között is. Viszont lássuk be, minden interfész úgy működik, hogy vagy az egyik fél diktál (esetleg enged), vagy bikesheddingbe torkollik vagy ad absurdum a használhatatlanságig elabsztrahálják.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Miért lenne jobb, ha külön repóban lenne? :)

Nem tudom, mi a szituáció most. Van egy repó, és lehet belőle make udev-vel egy udev binárist készíteni ami systemd nélkül vidáman fut, mint korábban? Mert ha igen, akkor rendben, akkor systemd nélküli rendszeren is lehet használni továbbra is, ahogy korábban.

Abból, hogy beolvasztásra került én úgy értelmeztem, hogy udev külön bináris nincs már, hanem a systemd program egyszerűen elvégzi azt a funkcionalitást is, amit korábban az udev. Viszont ha valahol systemd nélküli rendszert használ valaki, akkor már nem tud udev-et használni, mert nincs külön. Ez nem lenne jó.

Szépen és jól hangzik a "jól definiált, standardizált interfészeken keresztül beszélgető komponensek" móka, ha ráérsz standardizálni az interfészt (és akkor az indulásra van több, egymással elvileg interkompatibilis implementációd), de egy idege a legtöbb sikeres projekt inkább integrálja a komponenseit (akár kód, akár deployment szinten) és saját hatáskörbe veszi azokat.

Azt megértem, hogy más valaki programjára építeni az rizikós vagy csak kompromisszumok árán lehet. Nincs azzal bajom, ha valaki forkol és megváltoztat valamit vagy újat ír, olyant, ami neki pont jó.

Inkább csak arra gondolok, hogy nem szeretem azt, hogy lesz egy baromi nagy, monolitikus, komplex program, ami mindent is tud. Ha a kiegészítő cucc egy shared libben van, amit más is használhat, az már jó irány. Még jobb, ha esetleg külön bináris. Két bináris sokféle módon beszélgethet egymással, évtizedek óta vannak erre kipróbált, jól működő megoldások. Olyan programok, amiket én írtam, pl. kommunikáltak IPC-vel egymással, vagy RPC-vel. Az RPC-t konkrétan nem nagyon szerettem, de az IPC-hez csak el kellett olvasni a man-t, és ment, mint a karikacsapás. Mások által írt programokat nem integráltam a magaméhoz, de látok egy csomó különféle megoldást erre is. Lehet pipe-on keresztül vagy socketen keresztül is kommunikálni. Nem kell újra feltalálni a spanyolviaszt, csak ki kell választani a célnak megfelelő eszközt.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Abból, hogy beolvasztásra került én úgy értelmeztem, hogy udev külön bináris nincs már, hanem a systemd program egyszerűen elvégzi azt a funkcionalitást is, amit korábban az udev. Viszont ha valahol systemd nélküli rendszert használ valaki, akkor már nem tud udev-et használni, mert nincs külön. Ez nem lenne jó.

A fordításhoz kell a systemd-t is fordítani, de használható nélküle is, csak ízlés szerint át kell nevezni az elkészült binárist (systemd-udev lesz).

Inkább csak arra gondolok, hogy nem szeretem azt, hogy lesz egy baromi nagy, monolitikus, komplex program, ami mindent is tud. Ha a kiegészítő cucc egy shared libben van, amit más is használhat, az már jó irány. Még jobb, ha esetleg külön bináris. Két bináris sokféle módon beszélgethet egymással, évtizedek óta vannak erre kipróbált, jól működő megoldások. Olyan programok, amiket én írtam, pl. kommunikáltak IPC-vel egymással, vagy RPC-vel. Az RPC-t konkrétan nem nagyon szerettem, de az IPC-hez csak el kellett olvasni a man-t, és ment, mint a karikacsapás. Mások által írt programokat nem integráltam a magaméhoz, de látok egy csomó különféle megoldást erre is. Lehet pipe-on keresztül vagy socketen keresztül is kommunikálni. Nem kell újra feltalálni a spanyolviaszt, csak ki kell választani a célnak megfelelő eszközt.

Akkor van egy jó hírem: a systemd pont ilyen, kisebb raklapnyi bináris, amik egy jól definiált, introspektálható, standard protokollon (D-Bus) beszélgetnek egymással (*), az admin felé pedig adnak parancssori eszközöket (amik belül ugyanígy D-Bus-t hívogatnak, így kiválthatóak lennének a változatos parancssori dbus hívogató eszközökkel, ha van kedved sokat gépelni :) ).

(*): Többnyire, a generátoroknak pl. az interfésze az, hogy elindulnak, kapnak három path-et parancssori argumentumként, aztán amit akarnak generálni, azt fájlként bevágják a három közül a szimpatikusnak tűnő útvonalra... (ilyen mondjuk az, ami az fstab-ból előállítja a mount unitokat)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( bennyh | 2020. 05. 08., p – 15:10 )

Egy alap desktop rendszernek mennyire használható? Mondjuk, LibreOffice/GIMP/VLC/Chromium?

Hardvertámogatásban gondot okozhat a SystemD hiánya? 

És fordítva is lehet: a kernel userspace hiányában nem ismeri fel a hardware-t, mert pl. kell neki egy usb_modeswitch... Persze, lehet kézzel indítani, persze, az udevre éppen van egy csomó systemd-mentes alternatíva, de nem biztos, hogy ugyanúgy fog működni egy-egy cucc systemd nélkül (egyébként meg néhány multi-seat device-hoz van néhány soros udev rule, ami a logind-vel azonnal megcsinálja neked a megfelelő seateket, az USB portokat adott seathez csatolja stb., ez speciel systemd nélkül sok-sok-sok-sok különböző szoftverben kézi konfigfájl taknyolás)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

De ez még mindig hardwaremanagement és nem pediglen támogatás, márpedig utóbbi volt a kérdés; a systemd meg nem hajt meg egyetlen eszközt sem, mert nem az a dolga, tehát a hardwaretámogatáshoz nincs köze.

> ez speciel systemd nélkül sok-sok-sok-sok különböző szoftverben kézi konfigfájl taknyolás

Az összes többi fullos SCS-ben (s6, nosh, stb.) is? Vagy megint csak a SysVInit-es felállásról van szó.

Oldschool Computer - http://oscomp.hu

Ha ennyire komolyan vesszük, hogy az a támogatott HW, aminek a kezeléséhez kernel space-ben fut valami kód, akkor pl. a Linux nem támogat kb. semmilyen soros porton kommunikáló eszközt (mert az eszközzel ténylegesen a user space beszélget, a kernel csak a soros porti kommunikációig felelős).

A többi fullos SCS-t passz, de abból ítélve, hogy túl sok találatot nem kapok rá, túl sok jót nem tippelek (mert sajnos itt tényleg kell hozzá az összes "plumbing", amit a systemd hoz, a user slice-októl [hozzáférés-vezérlés a device node-okhoz], a logind [seat - user megfeleltetés] stb.). Még systemd-s rendszeren is masszív konfig túrás az egész (Arch: https://wiki.archlinux.org/index.php/Xorg_multiseat, Debian: https://wiki.debian.org/Multi_Seat_Debian_HOWTO), ha nincs kifejezetten egy Plugable (márkanév) eszközöd, aminél a device id-k alapján a udev ezt elintézi neked.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Lehet csűrni csavarni, csak felesleges. A systemd nem foglalkozik a hardware-ek meghajtásával, tehát nincs köze a hardwaretámogatáshoz. A kérdés sem erre vonatkozott (legnagyobb valószínűséggel), hogy lehet-e valami olyan külső cuccot találni, aminek user space drivere van, vagy egyáltalán semmilyen drivere nincs, mert soros portra/GPIO-ra/parallel portra van aggatva és maga a szoftver kommunikál vele nyersen, hanem arra, hogy menni fog-e a videókártya, hangkártya, NIC chip, a soros port maga, nem ami rá van aggatva, az USB és még sorolhatnám. Ezekbe a systemd hiánya, vagy megléte semmi szinten nem avatkozik bele.

Az, hogy nem kapsz rá találatot, semmit nem jelent. Ezt az egyes SCS-ek manualjából lehet kipuskázni, van belőlük jópár darab. És akkor még az önálló konfig segédprogramokról még nem is beszéltünk. A többi UNIX-ok konfigurációs megoldásairól meg pláne. Azt elhiszem, hogy egy natúr SysVInites Linuxon sokat kell hozzá konfigot taknyolni. De ez megint csak a SysVInit ellen érv.

Oldschool Computer - http://oscomp.hu

marpedig a systemd-tol nem csak seggfajasa, de meg fej, ful, szaj es korom, stb. is van az embernek ugye, szoval kar lenne nem foglalkozni vele :D

 

A systemd a Linux szifiliszes kurvaja (gyonyorunek es kivanatosnak nez ki). Ugyanugy terjed, ugyanolyan "hasznos", ugyanugy rombol es csak nagyon nehezen lehet sajnos megszabadulni tole.

De akinek nincs baja a szifilisszel, annak erdemes raneznie. :D

Ez mind szubjektiv dolog. Amint mutat valaki egy mérést hogy ennyi százalékkal gyorsabb vagy bármilyen mérhető szempontból jobb systemd nélkül lenni addig szubjektív is marad. És akik reálisan élik meg ezt a szubjektiv problémát addig elmehetnek a Devuannal elméletileg sajtot reszelni, nem zavar.

Aki azt sem tudja hogy miért van Devuan és mi ez a (szerintem mű)balhé a systemd körül annak meg pláne elméleti.

> a nálam okosabbak (arch linux, és minden más mainstream distro gyártók)

A Slackware elutasította a systemd-t és az is mainstream gyártó, tehát nem indokolt a "minden" kitétel. És a nem mainstream distro-k, azoknak a gyártói nem okosabbak, mint te?

> Arról tudomásom van hogy a systemd szépen gyűjtögeti a bug reportokat és egyéb jelentéseket, de nyilván foglalkoznak velük, és ki van/lesz javítva.

Van olyan critical CVE, amit hat éve (!) jelentettek be, de nemhogy nem javították, de még reakció sem jött rá. (https://seclists.org/oss-sec/2014/q4/654)

Oldschool Computer - http://oscomp.hu

Van olyan critical CVE

Bár a linkelt szálban épp nem kaptak CVE számot, de mindegy :) [egyébként a jelölt RFC-t úgy jelölik, mint "Comprehensively Implemented, to the point appropriate for resolved", kódba lusta vagyok belenézni, hogy ez a valóságban mit jelent :) ]

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

        * systemd-resolved now implements RFC5452 to improve resilience against
          cache poisoning. Additionally, source port randomization is enabled
          by default to further protect against DNS spoofing attacks.

(v.223 2015 júniusból https://github.com/systemd/systemd/blob/master/NEWS, egyébként a v. 217 volt az aktuális, amikor a fenti levelezés lement)

BlackY

 

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Tehát csak válaszolni csesztek, a hibát stikában javították? Hát ez még mindig a jobbik eset, mert pl. a "0day" CVE-t NOTABUG-ként lezárták, azzal a felkiáltással, hogy a "0day" nem valid username, ami egyébként nem igaz, de még ha az is lenne, nem az a baj, hogy nem fogadja el (az nem lenne issue, maximum annoyance), hanem az, hogy a rootra revertel. (Egyébként vicces, hogy Pötyi bátyánk userneve meg "0pointer". :] )

Oldschool Computer - http://oscomp.hu

Nope, lennart: http://0pointer.de/public/pscgroups.png :)

A 0day-nek nekifuthatunk megint, de nem revertel rootra, hanem számként értelmezi a számmal kezdődő usert (1day-el uid=1 lenne), és ahogy ezt múltkor tisztáztuk, ez más daemonoknál is gondot okozhat, úgyhogy van jogalapja a sok rendszeren használt username regexnek.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

> Nope, lennart: http://0pointer.de/public/pscgroups.png :)

Van 0pointeres is.

> A 0day-nek nekifuthatunk megint, de nem revertel rootra, hanem számként értelmezi a számmal kezdődő usert (1day-el uid=1 lenne)

Tehát magyarán a "0day" user a rootra revertel. Felesleges csűrni-csavarni.

> és ahogy ezt múltkor tisztáztuk, ez más daemonoknál is gondot okozhat,

Az nem érv, hogy a másik is.

> úgyhogy van jogalapja a sok rendszeren használt username regexnek.

Szó szerint leírtam, hogy "nem az a baj, hogy nem fogadja el", tehát nem a regex-szel van baj. Az a baj, hogy "0day" => root.
Egyébként nem nekem kell megmagyarázni, én már csak a vállam tudom vonogatni; majd azoknak kell, akik így fognak megszívni egy hacket. A sérülékenység él és nincs javítva évek óta és a jelenlegi álláspontjuk szerint nem is lesz.

Oldschool Computer - http://oscomp.hu

Wut? User instance-ben (leszámítva a root user instance-ét) nem használhatsz User-t, ha meg eleve root vagy, akkor miért gond, hogy el tudsz valami indítani bármelyik userként?

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

> ha meg eleve root vagy, akkor miért gond, hogy el tudsz valami indítani bármelyik userként?

Ha a rendszer ezt amúgy is lehetővé teszi, akkor nyilván semmi, de ha pl. a runuser és a sudo ki vannak iktatva, akkor az biztos nem azért van úgy, hogy mégis lehessen.

Oldschool Computer - http://oscomp.hu

A root elől hogy tudsz bármit kiiktatni úgy, hogy azt úgy ne tudja visszaiktatni? És ha azokat kiiktattad visszaiktathatatlanul, mi akadályoz meg abban, hogy visszaiktathatatlanul elvedd a root írási jogát a /usr/lib/systemd/system-ről, az /etc/systemd/system-ről és a /root/config/.systemd-ről?

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Az is számít, hogy mennyi időbe, erőfeszítésbe és egyébbe tellik, hogy vissza tudja kapcsolni őket, aminél egyszerűbb, ha élhet egy ilyen exploittal. Nem tudok neked igazán adekvát választ adni, mert nem vagyok secu-expert. Józan paraszti ésszel csak annyit tudok mondani, hogy ez rendellenes működés, amit így-vagy-úgy ki lehet használni.

Oldschool Computer - http://oscomp.hu

Warning: include(/usr/share/mediawiki-extensions/base/ExtensionFunctions.php): failed to open stream: No such file or directory in /etc/mediawiki-extensions/extensions.php on line 4

Warning: include(): Failed opening '/usr/share/mediawiki-extensions/base/ExtensionFunctions.php' for inclusion (include_path='/var/lib/mediawiki:/var/lib/mediawiki/includes:/var/lib/mediawiki/languages:/usr/share/mediawiki/vendor/pear/pear_exception:/usr/share/mediawiki/vendor/pear/console_getopt:/usr/share/mediawiki/vendor/pear/pear-core-minimal/src:/usr/share/mediawiki/vendor/pear/mail_mime:/usr/share/mediawiki/vendor/pear/net_socket:/usr/share/mediawiki/vendor/pear/net_smtp:/usr/share/mediawiki/vendor/pear/mail:.:/usr/share/php:/usr/share/pear') in /etc/mediawiki-extensions/extensions.php on line 4

A database query error has occurred. This may indicate a bug in the software.

(without-systemd.org)

Mekkora jó lenne már, ha lenne egy rendszer, ami egy megborult mondjuk MySQL kiszolgálót megpróbál néhány alkalommal újraindítani, hogy ha lehet, ne álljon a rendszer, amíg az üzemeltető alszik ;)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

A tíz soros scriptből megoldható watchdogra gondolsz? :] Vagy esetleg valamelyik újrahúzóval felszerelt SCS-re, pl. s6? :P

Egyébként ezen nem segítene sem watchdog, sem az a bizonyos "rendszer", sem más "rendszerek" sem, mert ez már hónapok óta ilyen, szóval nem az üzemeltető alszik, hanem a projekt szenderült örök álomba. A webarchívból ugyan levakartam az utolsó elérhető állapotokat, de összereszelni és feltölteni még nem volt érkezésem.

Oldschool Computer - http://oscomp.hu

ez a speed fetis nem tudom honnan jon, de vegre van egy rendes cucc, amiben (nagyabol) jo a serivce dependency. vegre megvan hogy ki kielott induljon el, es nemcsak S87, aztan vagyjo vagynemjo. aztan ha valami lehal akkor nemkell kulso programokkal rugdosgatni.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Egy fél éve az ascii kiadást használom, meg vagyok vele elégedve. Ugyanolyan mint a debian és ugyanazok a csomagok elérhetőek nagyjából, csak nincs benne systemd.

Eddig egyedül a snap "csomagkezelőt" nem tudtam feltenni rá, de megvagyok nélküle.

"Everything fails, all the time."

( _ventura_ v | 2020. 05. 08., p – 15:53 )

Régóta nézegetem, viszont egy EOL nem találok róla, erről tud valaki valamit, vagy csak én nem kerestem jól.

Fedora 38, Thinkpad x280

( szilas | 2020. 05. 08., p – 23:54 )

Mivel az ubi 18.04-re upgrade elég szarul sikerült (már az 5. systemd szert kell(ene) hegesztenem). Azthiszem eljött az ideje a Devuan-nak.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

( blah-blah | 2020. 05. 09., szo – 17:40 )

Ez itt a francia ellenállás. Mindeki dobja el a kezében lévő systemd-t és installálja a Devuan-t!

( lacesz v | 2020. 05. 09., szo – 19:48 )

Mi a beta a weblapon? Az hogy beta.domain alatt van? Szín és font csere történt semmi más...

( hajbazer v | 2020. 05. 11., h – 17:28 )

Szerkesztve: 2020. 05. 11., h – 17:29

Érdekes, hogy amikor zárt forrású rendszerek folyamatos innovációja és továbbfejlesztése egységsugarú tapicskolók szintjére butítása közben vesznek ki feature-öket, beállítási lehetőségeket, kompatíbilitási rétegeket, drivereket, vagy hoznak be instabil elemeket, mindig jön egy FOSS-huszár, aki odacsap az asztalra: Nem megmondtam, hogy nyílt forrást kéne használni?! Mert azzal van választási lehetőséged, úgy írod át, ahogy akarod. Ami maximum akkor igaz, ha beéred fél óra alvással esténként és le tudod magad klónozni legalább háromfelé, ha rendszerszintű komponensek karbantartásáról van szó.

Viszont, amikor tényleg vannak, akik időt-energiát nem sajnálva, élnek a szabad szoftver adta lehetőségekkel és megszabadulnak egy profitorientált multi (Red Hat) Linux ökoszisztémába való belegányolásától, akkor meg ugyanazok a FOSS-huszárok és fősodratú mérnök urak akadnak ki rajta és nevezik az egészet az alulmaradottak™ hisztijének.

A Devuan egy ékes példája annak, hogy a nyílt forráskód adta lehetőségekkel élni lehet. Ahogy a gtk3-typeahead, az apulse és minden ezekhez hasonló, Poettering és a Red Hat invazív úthengerének lelassítására tett kísérlet.