-
IT café
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
samujózsi
tag
Troll on:
Hány linux disztro van? Egy blackpanther mindenre elég.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Vladi
nagyúr
Ki dühöngtétek magatokat?
Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!
-
Frawly
veterán
válasz bambano #28727 üzenetére
Engem desktopon érdekel, hogy mennyire gyorsan bootol a Linux. Megszoktam, hogy a kis lapitopim SSD-vel ultragyorsan bootol, olyan, mint egy táblagép lényegében, bekapcsolom, és szinte azonnal az arcomba vágódik a használatra kész rendszer. Vagyis vágódna, ha nem lenne a systemd egyre bloatabb, és nem szivatna mostanában extrán a random seed miatti bootlelassulással.
Nyilván a szerverek világa más.
A systemd-vel meg mi a baj, azt legékesebben az fejezi ki, hogy egy systemd-s disztró a legminimálisabb telepítésben sem áll meg ~130 MB alatti memófogyasztással, ez systemd nélkül 30 MB körülre küzdhető le. Minimalista rendszereknél, meg nagyon régi gépeknél ez elcseszettül sokat számít!!! Egy modern i5-i7, Ryzen, Xeon, Threadripper, stb. gépen lehet nem számít sokat, de ilyen P3, P4, lóhúgy Celeron, nevetséges Atom, egyéb ultramobil gépeken, embedded rendszereken (néha még gyengébb C2D, i3-as rendszereken) baromi sokat nyom a latba, ég és föld, sebességben is, hogy nem fut a háttérben mindenféle systemd-service sallang!
A systemd-vel az a baj, hogy már rég nem egy initrendszer, hanem egy komplett mini OS az userspace és a kernel közé beépülve. A másik gond vele nem Poettering, mert ő akármilyen fost írhat magának hobbiból, hanem azok az elmebetegek, akik minden disztrót és alkalmazást a systemd-re dependeltetnek, és erről nem Poettering tehet. Ő csak egy szerencsétlen, vézna, idióta, kocka csávó, nem akar apokalipszist, hanem a sok hülye megy ész nélkül utána. Ez olyan, mint a lőfegyver, nem az öl, hanem az emberek mögötte, akik meghúzzák a ravaszt, és egymás ellen használják.
-
Frawly
veterán
válasz inf3rno #28728 üzenetére
Offtopik itt a FreeBSD, de ha már felhoztad, egye fene, ejtsünk róla szót. Alapjában véve nem rossz rendszer, nem érték még utol a linuxos baromságok, pl. nuku systemd. Sokkal minimalistább rendszer a linuxnál is. De! Desktopra nem olyan jó, sokkal szűkebb a drivertámogatása, Wine van ugyan rá, de ilyen Proton, DXVK, Wayland és egyéb nyalánkságokat el kell rajta felejteni. Viszont cserébe azon a hardveren, amin nem okoznak gondot a driverek, azon viszont nagyon f4×ányos minimalista, ultrasovány rendszer dobható össze belőle, úgyhogy kipróbálásra mindenképp ajánlott azoknak, akik minimalista rendszert keresnek.
-
Lenry
félisten
válasz Frawly #28754 üzenetére
Mi speciel a zfs miatt használjuk, az tényleg fasza.
Attól viszont sírni tudok, hogy 3 külön program kell egy rendszerfrissítéshez és simán benne van a pakliban hogy upgrade után nem bootol.
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
inf3rno
nagyúr
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód, ami fent van a githubon." - Hát 4 éve még nem volt túl erős a lefedettsége, reméljük azóta javult. [link] Ha már szóba került, akkor inkább OpenRC-hez lenne értelme hasonlítani, az állítólag hasonló tudású rendszer: [link].
Mindkettő fent van githubon. Beszéljenek a számok.
OpenRC: [link]
- 13k sor kód C-ben (összesen 21k sor adatfájlokkal)
- 41 nyitott issue, 114 zárt, 6 alap issue label
- 103 contributor, 52 watcher
- 3k commit, az utolsó 2 hónapja
- benchmark a cikkből 46.5 secSystemD: [link]
- 355k sor kód C-ben (összesen 650k sor adatfájlokkal)
- 1143 nyitott issue, 4226 zárt, 165 issue label
- 1185 contributor, 332 watcher
- 42k commit, az utolsó 3 napja
- benchmark a cikkből 43.5 sec355/13 = 27, tehát 27x annyi sor kód van a systemd-ben
13k/(41+114) = 84, 355k/(1143+4226) = 66, durván 20%-al kevesebb sor kódra jut egy issue a systemd-nél, igazából engem meglepett, hogy csak ennyivel rosszabb
13k/103 = 126, 355k/1185 = 300 sor kódra jut egy contributor
13k/52 = 250, 355k/332 = 1069 sor kódra jut egy watcher
300/126 = 2.4, 1069/250 = 4.3
tehát 2.4x több munkát végez egy contributor, és arányaiban 4.3x annyi kód jut egy watcher-re a systemd-nél, bár az utóbbi csalóka, mert(46.5-43.5)/46.5 = 6.5%-al több idő a bootolás OpenRC-vel
Nagyjából annyi a véleményem, mint eddig is, most vagy nagyon balfaszok a systemd fejlesztői és overengineered az egész, vagy a kód nagyrésze egyáltalán nem is az inittel foglalkozik, ha elfogadjuk, hogy az ő megközelítésükkel ugyanannyi kódból ki lehet hozni egy init rendszert, mint az openrc megközelítésével. Igazából meg lehet nézni még más init rendszereket is. SysVinit 8k sor, upstart 71k sor, mindkettő jóval elmarad a systemd-től, az upstart, ami legalább kicsit megközelíti kód mennyiségben.
Az a fogalom, hogy "standard-nek mondható" nem létezik. Vagy szabványosítva van valami, vagy nincs. A szabvány készítés általában több éves folyamat, nem csak ilyen összeszórunk valamit, aztán jó lesz alapon megy.
"Ez kb. minden fejlesztő több havi munkáját igényli, költsége millió $-ban mérhető. De valószínűleg a Debiannál sem két perc volt a váltás." - Pont ezért kellett volna valami normális init rendszerre áttérni, nem erre a szemétre. Mindenkinek kevesebb munkájába került volna egy moduláris init rendszerre való áttérés, mint egy ilyen monolitot beletákolni a disztrójukba, ahol minden mindennel összefügg. Sokan hoztak már ostoba döntéseket ilyen vagy olyan okból, elég csak megnézni a főpolgármester választás eredményeit pártpreferenciától függetlenül.
Buliban hasznos! =]
-
haddent
addikt
válasz bambano #28750 üzenetére
Ez már kezd áthajlani szubjektivitásba kicsit, bevallom, de szerintem nem logikus az épp előbb említett változtatásokkal fejenként 5 distro. De igaz, kicsit drasztikus vagyok, pl. nem értem a Debian/Ubuntun kívül minek bármi más deb alapú? Archon kívül minek bármilyen Arch alapú..? stb.. Meg tudnám indokolni és logikus lenne (max nem értenél egyet vele), de igazából felesleges, ez van, így van aztán kész
-
bambano
titán
válasz haddent #28759 üzenetére
de nem csak egy szempont szerint kell ezt a dolgot értékelni.
ha a te szempontodat, a szoftverfejlesztés hatékonyságát nézzük elaprózott platformon, akkor igazad van, hogy nem logikus.Itt az a lényeg, legalábbis az én véleményemnek ez az alapja, hogy az is számít, hogy a szabad szoftver megad egy csomó szabadságot, és ebbe az is beletartozik, hogy forkolod a cuccot. Az egész miskulancia arra épül, hogy nem pofázunk, hogy rossz, hanem írunk jobbat. Tehát ha felmerülne, hogy a disztró készítés jogát korlátozzuk, azzal kompletten kiherélnénk az egész szabad szoftveres eszmét. Ilyet, hogy nem nyúlhatsz bele valamibe, csak a nagy ellenség, az m$ csinál, debianék meg archék nem.
Nem tudok ennél fontosabb elvet szabad szoftver kérdésben.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
-
ivana
Ármester
-
ivana
Ármester
-
ivana
Ármester
válasz bambano #28765 üzenetére
15 éves lappal? Cseréljék le. Ha valamiért nem lehet cserélni, akkor jó drágán támogassák a régi szoftvert. Nagyon hülye ötlet ilyenekre teljesen új szoftver rakni, főleg beágyazott környezetben (Ok mondjuk alapból maximum ott jöhet szóba ilyen, az ilyen szintűnél ezerszer jobb vasakat is rég cseréltek szerverben. LGA1366-ot megy manapság fillérekért, a nagy cégek már nem használnak annyira régi hardvert.)
Aki meg ilyet új custemernek elad annak salesesnek kötelet adnék
[ Szerkesztve ]
-
Frawly
veterán
A P3-ast extrém példának írtam. Nyilván értelmes ember nem használ ilyen gépet, csak hobbisták, retrózók. Ők viszont szórakozásból meghúzzák, hogy modernebb OS-t tesznek rá. Ilyen körülmények között de, felmerül, hogy mi milyen gépen hogy fut, meg az is, hogy a systemd valójában bloat.
C2D, C2Q, régi genes Core i gépek, laptopok használtan, meg refurbolva elég olcsón mennek. Ezért is nem értem, hogy miért veszi még mindig sok ember ezeket az Atom-os, Celeronos szutyok gépeket, de még olyan ember is betér néha linuxos topikokba, aki Pentium 4-re meg Athlon XP-re keres sovány disztrót. Meglepődünk rajta.
Pont itt a PH-n is az egyik retrós topikban most volt egy csóka, aki kései, 14 éves Pentium M-es gépre tett fel Win10-et. Nyilván nem ezt használja fő gépnek, van vagy másik 100 gépe otthon, közöttük gondolom modernebb is, inkább csak a kihívás meg érdekesség kedvéért kísérletezik ilyennel.
[ Szerkesztve ]
-
inf3rno
nagyúr
Bár nem akartam újra írni a systemd témában, de találtam közben ezt a videot: [link], ami egy kicsit árnyalja a képet (bár az előadó nekem nem szimpatikus, de ez most lényegtelen). Ez alapján tényleg van értelme az alap ötletnek, mert jobb, ha egy külön service manager felel a szolgáltatások futtatásáért, rendszer vagy egyéb események küldéséért feléjük, stb., mintha ők maguk felelnek érte. Egy csomó kód így újrahasznosíthatóvá válik. Mondjuk, mint már előzőleg írtam, azért ráférne a szabványosítás mielőtt ténylegesen kódot írunk rá, mert szinte minden alkalmazás használni fogja. Ez sajnos elmaradt. A tényleges probléma mégsem igazán ezzel van, hanem a megvalósítással. Azzal, hogy még a cron-t is benyeli a rendszerük, ahelyett, hogy a már meglévő könyvtárakat, szolgáltatásokat próbálná meg használni. A "don't reinvent the wheel" [link] gondolom semmit nem mondott a systemd fejlesztőinek, amikor nekiálltak. Gondolom aki a videot csinálta, az is náluk dolgozik, és az az érdekes, hogy ez így utólag lejött neki is, de már késő, nem fognak változtatni. Poettering azt mondja, hogy az IOS-ből a launchd, ami megihlette ezzel kapcsolatban, de igazából a Windows-ban is van hasonló service manager már a kezdetektől, részben mindenkinek igaza volt ezzel kapcsolatban, viszont volt egy komoly félreértés. Nem azért írtuk, hogy nem akarunk Windows-t csinálni a Linux-ból, mert hogy abban van service manager, hanem azért, mert monolit az egész, mindenbe belenőtt, mint a rák, ahelyett, hogy a már meglévő megoldásokat próbálná meg felhasználni, és nagyon úgy tűnik, hogy a folyamat egyáltalán nem állt meg, szóval végső soron kb. olyan lesz majd, mint a Windows. Lehetne ezt sokkal jobban is csinálni, nem szembemenve a Linux/UNIX alapelvekkel. Nem lennék meglepve, ha egy idő után jönne valami jobb helyette.
Buliban hasznos! =]
-
bambano
titán
válasz inf3rno #28768 üzenetére
de mennyi felesleges munkát és kárt fog okozni pöcstering, mire végre felfogja a többség, hogy el kell zavarni, és mennyi meló lesz majd egy elcseszett systemd-ből migrálni egy másik rendszerbe megint?
Ráadásul ha mindent magába olvaszt, akkor az nem egy linux kerneles unix lesz, hanem egy linux kerneles windows.
"mert jobb, ha egy külön service manager felel a szolgáltatások futtatásáért": volt service manager, úgy hívták: init.
"Mondjuk, mint már előzőleg írtam, azért ráférne a szabványosítás mielőtt ténylegesen kódot írunk rá": tényleg mondtad, pedig nem kellene, mert téves. az init eléggé szabványos volt. szabványosítás igényével lecserélni egy egységes, szabványosnak tekinthető rendszert egy egyedire, tévedés.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
ivana
Ármester
válasz bambano #28769 üzenetére
úgy hívták: init Az init az simán csak az elsőként indított program a kernel bootolása után (vagy switchroot után, amikor initramfsből átvált a rendes root fájlrendszerre). Az init az a program, aminek a PID-je 1. A systemd is egy init, ha ezt egy shell scripttel oldod meg az is egy init etc. (Utóbbi pl. egy beágyazott rendszeren működhet, ahol akár nincsenek "rendes toolok, hanem csak busybox.) Amiről te beszélsz az a sysvinit (ami rohadtul nem szabványos, mert nincs két distró, amin ugyan úgy működik).
-
bambano
titán
debianon és solarison is ugyanúgy működött, tehát van két "disztró", akkor már szabványos?
ha az init maga szabványos, de nem korrekten implementálják, akkor az az init hibája vagy az implementációé?szerinted jó a systemd, szerintem egy nagy vödör csavar. hogy ne tartson ez a vita túl sokáig, azt is megígérem neked, hogyha külső segítségre lesz szükségem hardverfejlesztési stratégia kialakításához, te leszel az első, akit meg fogok keresni.
és azt az állításomat is fenntartom, hogyha szerinted a systemd magas százalékban le van fedve tesztekkel, akkor a tesztek se érnek többet egy vödör csavarnál. a systemd használata egy rakás elpazarolt munkával jár és ez engem bosszant.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
haddent
addikt
válasz bambano #28771 üzenetére
Hittől, terminológiától, hangzatos definícióktól és mindenféle 30 éves télapó szakállas unix idézetektől mentesen leírnád, hogy mire pazarlod a munkaidőd, amikor systemd -re kényszerülsz? Őszintén érdekel, nem szarkazmus / kötekedés. Csak mert nekem tényleg eddig kivétel nélkül csak megrövidítette a munkám, de kb. tizedére minden esetben. Nyilván ezért ""szeretem"", semmi másért
-
inf3rno
nagyúr
válasz bambano #28769 üzenetére
"volt service manager, úgy hívták: init." - Ha a sysvinit-re gondolsz, akkor erősen az a benyomásom, hogy túl keveset tud, és nem igazán támogatja a fejlesztést. Mármint az jött le, hogy annyit csinál összesen, hogy elindít egy bash scriptet bootoláskor, amit megadsz neki, aztán kalap. A systemd-ről az jött le, hogy van egy event bus, arra küld mindenki eseményeket, és onnan veszik le a szolgáltatások azokat, amikre nekik reagálni kell. Sokkal kiforrottabb ez így nekem, bár a megvalósításról továbbra is az a benyomásom, hogy fos. De ezeket tényleg csak érzésre mondom az alapján, amiket olvastam. Ma van egy kis időm, rászánok néhány órát, meg belenézek a kódokba is, hogy tisztázódjon ez az egész. Én személy szerint valószínűleg OpenRC vagy ilyesmi mellett kötök ki, de érdekel a téma.
Buliban hasznos! =]
-
haddent
addikt
válasz inf3rno #28774 üzenetére
Mindkettő syntaxa annyira csúnya, hogy már ott alapból elhasal részemről.. De huzamosabb ideig nem használtam egyiket sem, lehet, hogy a funkcionalitása amúgy jó. Tényleg tisztázni szeretném, hogy nincsen preferenciám sem favoritom, azt használom amit kényelmes és működik, illetve nyilván ami mögé beáll a suse meg a redhat
-
bambano
titán
válasz haddent #28772 üzenetére
"mire pazarlod a munkaidőd, amikor systemd -re kényszerülsz?": hát systemd-re, mi másra.
ha azt akartad megkérdezni, hogy mit nem tudtam megcsinálni vele, akkor a válaszom: stackelj egymásra raid1-et, drbd-t, lvm-et, cryptofst, raid1-et különböző sorrendekben. ez nem működik a debian systemd-jével.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz inf3rno #28773 üzenetére
"az a benyomásom, hogy túl keveset tud": érted már, hogy miért JÓ?
"Mármint az jött le, hogy annyit csinál összesen, hogy elindít egy bash scriptet bootoláskor, amit megadsz neki, aztán kalap.": ennél azért többet csinál, nem ártana ismerni, mielőtt azt hiszed, hogy arra a feladatra a systemd jobb.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz haddent #28778 üzenetére
alapvetően most cseréltünk szervereket az egyik helyen, ahol dolgozom, újra lett húzva minden nulláról, és azt találtam ki, hogy drbd-vel realtime mentést csinálok. mivel kitolom a házból máshova, így legyen rajta titkosítás. és hogy gyors is legyen, raid1-be raktam. ezt elvileg meg kellett volna tudni csinálni systemd-vel, de a doksija alapján nem működött. mondjuk az md raid drivert is szétokoskodták, a raid1-be rakott raid1 például egy neuralgikus pontja.
vagy ilyet akartam megcsinálni, hogy a postfix ne induljon el addig, amíg nincs felmountolva a leveleket tároló partíció.
úgyhogy most úgy van összerakva, hogy rebootkor a gép félig elindul, utána kézzel összerakom a maradékot.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
haddent
addikt
válasz bambano #28779 üzenetére
Tisztán elméleti okoskodás részemről. Szóval lehet, hogy "oem" nem megy, de amit meg tudsz kézzel csinálni, azt scripttel is. Mi lenne, ha scriptelnéd amit kézzel csinálsz, és beraknád multi-user.target.wants -ba, majd szintén ide a postfix-et, csak a postfix.service -be tennél egy
After=manual-hax-startup
- ot? Ennek pontosan azt kéne elérnie amit szeretnél, elméletben.Az más kérdés, hogy out-of-the-box miért nem működik, de szerintem azért eléggé egyedi igény ahhoz, hogy egy manual scriptet elviseljen. A sors fintora, hogy más inittel úgyis kéne írtni scriptet
[ Szerkesztve ]
-
aki33
csendes tag
Systemd mentes arch linux [link]
-
ivana
Ármester
válasz haddent #28780 üzenetére
Szvsz célszerűbb a Wants= alkalmazása, ha minden service fájl normálisan meg van csinálva akkor elvileg elég lenne dependálni a mount service-ére. A szkriptnek meg ennyi kell egy service fájlba, erre ugyan úgy tudsz dependálni. A oneshot típus aktív marad ha nullával lép ki a szkript.
[Unit]
Description=<...>
[Service]
Type=oneshot
ExecStart=<script path>
RemainAfterExit=true
StandardOutput=journal -
haddent
addikt
válasz bambano #28783 üzenetére
Mert a többi 90% -ban egyszerűbb és hatékonyabb. De ezt már túltárgyaltuk, hogy neked nem begyerés akkor sem, itt csupán szükségmegoldásról volt szó, hogy azért működésre lehet bírni, nem kell kézzel
ivana eh, jah, lényegében ugyanaz csak kicsit tisztább, hosszú volt a nap
-
kovaax
őstag
válasz haddent #28780 üzenetére
A függőség kezelése is szar, az After nem azt jelenti, hogy akkor indul, ha az előző elindult ténylegesen, hanem ha elkezdte indítani. Szóval amikor szépen összeügyeskedtem, hogy az oracle után induljon el az azt használó alkalmazás, azt tapasztaltam, hogy az alkalmazás mindig elhal, mert nem tudja elérni az adatbázist, mivel a systemd nem várja ki azt a 10 másodpercet, míg az oracle tényleg elérhető lesz. Míg ha egy buta scriptbe beleírom, hogy oracle majd az alkalmazás, akkor működik minden, szarni a systemd-be...
-=- There's no place like /home -=-
-
haddent
addikt
válasz kovaax #28786 üzenetére
Ezt eddig nem tapasztaltam, de ha te igen biztosan előfordulhat. Mondjuk ilyen "szoftvernek" csúfolt szemetekkel, mint oracle meg java nem biztos, hogy bármi másban keresném a hibát
bambano személy szerint nekem messzemenőkig túl explicit és feleslegesen szájtépő a sysvinit. Ettől függetlenül ilyen extrém felhasználásban mint a tiéd, lehet, hogy jobb, vagy neked jobb, ezt nem vitatom, mert nem próbáltam
-
bambano
titán
válasz haddent #28787 üzenetére
azt gondoljátok, hogy az init csak egy shell szkriptet indít el, ami nem így van. induláskor a runlevelnek megfelelő szkripteket indítja el, és amikor elérte a végleges runlevelt, akkor utána az inittabban leírt daemonok futását menedzseli ugyanúgy, mint a systemd. viszont az inittab kevesebb szájtépést tartalmaz, mint a systemd fájljai, tehát nem igaz, hogy a sysvinit szájtépő.
továbberősítitek bennem azt a véleményt, hogy azért rossz a sysvinit, mert nem tudjátok, mit tud.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
"Ha minden normálisan működik és rendesen van megírva a service fájl": ezt nem vitatom, csak ha összeveted azzal, amit a vita elején írtam, akkor kiderül, hogy ez egy üres állítás.
te azt támasztod feltételnek, hogyha minden normálisan működik, én meg azt írtam, hogy a systemd jelentős része nem működik. következmény: a feltétel utáni rész sosem valósul meg.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
haddent
addikt
válasz bambano #28789 üzenetére
Én egy szóval nem állítottam, vagy akkor félreértettél, hogy csak annyit tenne. Nem ismerem olyan mélységeiben, hogy működési elveiről vitázzak és különösebben jelenleg nem is foglalkoztat, hiszen az iparban systemd van, akárkinek akár tetszik, akár nem. Majd ha más lesz akkor megtanulom azt 1 nap sz**ással aztán ennyi
Két dolgot állítok, egyik az személyes véleményem és tapasztalatom, hogy szerintem/nekem/én tapasztalataim alapján tök jó a systemd. Ezzel vitába lehet szállni, csak felesleges, mert mostmár egészen világosan kiemeltem, hogy szubjektív, illetve felőlem hívhatod izolált esetnek, bár nem hiszem, hogy egyedül vagyok.
A másik, objektíven, hogy ha talán pl. neked / te felhasználásodban nem is a legjobb, azért bőven használható és workarounddal simán megoldható minden, ahelyett, hogy kézzel kelljen bizbaszkodni, még ha mondjuk sysvinitben szebb is lenne, vagy neked jobban kézreállna/tetszene.Sőt, lehet, hogy többet tud a sysvinit, nem tudom. De nekem se itthon, se a szervereken melóban sehol nem volt eddig másra/többre szükségem. Azt akarom csak ezzel mondani, hogy továbbra sem vagyok semminek a hívője, pl. ott lenne a networkd is, de nem használom, mert ku***ra kevés az én igényeimnek egyelőre. De a netctl, ami nem is tudom pontosan talán Arch saját projekt de systemd mintára, az egyik legjobb, megint, nekem
-
Frawly
veterán
Init rendszeren tágabb értelemben nem csak a PID 1-es folyamatot hívják, hanem azt az egész megoldást, amivel a többi folyamat indítható, az induló folyamatok konfigurálhatók, stb..
De nem véletlenül írtam, hogy a systemd-vel az a baj, hogy nagyon rég nem csak egy initrendszer. Egy komplett, bloat mini OS beékelve az kernel és userspace közé. Nem csak az initfeladatokat veszi át, hanem egy csomó hálózati, biztonsági, naplózási, hardverkezelési dolgot is, meg alkalmazások közötti kommunikációs felületet.
Ha tényleg megmarad volna initrendszernek, ami tényleg csak initként működik, semmi mást nem is tud, akkor nem lenne vele nagy baj. De így kezd egyre jobban elfajulni, most fogják behozni, hogy a homed komponens a home mappát, meg egy csomó felhasználói konfigot is fog kezelni, azt is saját kézbe veszi. Így meg egy szép nap azon kapjuk magunkat, hogy az egész Linux megszűnik Linuxnak lenni, és linuxd lesz belőle, amit nem a Torvalds-féle kernel fog hajtani, hanem Pöcstering által foltozott kerneld. Na, ennek kéne elejét venni.
[ Szerkesztve ]
-
inf3rno
nagyúr
válasz haddent #28792 üzenetére
Én állítottam, de én sem ismerem mélységeiben, csak sok videoban ilyesmit mondtak, hogy a sysvinit csak elindítja a dolgokat, de nem menedzseli, ezért mennyivel jobb a systemd vagy a launchd BSD-nél. Mélyebben belenézni nekem sem volt még időm. Ha nem így van, akkor valóban értelmetlen pénzkidobás volt az átállás systemd-re. A másik érv a sysvinit ellen az volt, hogy distro függő a scriptelése. Ennek se jártam utána, hogy tényleg így van e, viszont ez annyira nem probléma, ha valaki csak a kedvenc disztroját használja. Inkább akkor gond, ha valaki sokak által használt szoftvert ír, és szeretné, hogy eltérő disztrokon is ugyanúgy viselkedjen.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Frawly #28793 üzenetére
Szerintem önmagában nem gond, hogy a systemd ilyen, ami gond, hogy szinte az összes disztroba belenyomják, ahelyett, hogy a fazon hobbi projektje lenne, hogy hogyan csináljunk Linux-ból Windows-t. Én azóta mióta először hallottam róla értetlenül állok az egész előtt.
Buliban hasznos! =]
-
totron
addikt
Idlétlen probléma. Mélykonzolban fájlmásolás, csakhogy --= könyvtárnév =-- formátumú a védvonal: sajnos kapcsolónak veszi az első két karaktert. Nincs másik live linux, ezt kellene megoldani. Köszi, ha van ötlet.
-
Jester01
veterán
válasz inf3rno #28799 üzenetére
Idézőjelben sem jó, mivel azt a shell bontja ki. A program (jelen esetben gondolom
cp
vagymv
) az pontosan ugyanúgy, idézőjelek nélkül kapja meg.$ find . -name --\*
./--foo
$ mv --foo --bar
mv: unrecognized option '--foo'
Try 'mv --help' for more information.
$ mv "--foo" "--bar"
mv: unrecognized option '--foo'
Try 'mv --help' for more information.
$ mv '--foo' '--bar'
mv: unrecognized option '--foo'
Try 'mv --help' for more information.
$ mv -- --foo --bar
$ find . -name --\*
./--bar[ Szerkesztve ]
Jester
Új hozzászólás Aktív témák
- Call of Duty: Modern Warfare III (2023)
- VR topik (Oculus Rift, stb.)
- KERÉKPÁR / BRINGA / ALKATRÉSZ beárazás
- Poco X6 Pro - ötös alá
- Kerékpárosok, bringások ide!
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- Alkalmazásbemutató: Keep
- Gaming notebook topik
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Debrecen és környéke adok-veszek-beszélgetek
- További aktív témák...
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- AKCIÓ! - STEAM kulcsok /Anuchard, Aragami, Children of Morta, stb. - 2024.04.17.