Hirdetés
- Xiaomi 13 - felnőni nehéz
- Fotók, videók mobillal
- Telekom mobilszolgáltatások
- iPhone 16e - ellenvetésem lenne
- Amazfit Balance - ár-érték egyensúly
- One mobilszolgáltatások
- Samsung Galaxy A53 5G - kevesebbet többért
- Akciófigyelő: Megnyílt a Xiaomi hivatalos magyar webáruháza
- Android alkalmazások - szoftver kibeszélő topik
- Apple iPhone 11 Pro Max - tiltott gyümölcs
-
Mobilarena
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
-
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
cpvagymv) 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 -
inf3rno
nagyúr
-
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.
-
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.
-
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
-
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.
-
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.
-
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
-
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...
-
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
-
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
#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
-
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.
-
-
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.
-
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. -
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
-
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.
-
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
-
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.
-
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
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.
-
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.
-
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.
-
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
-
-
-
-
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.
-
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
-
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.
-
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.
-
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.
-
bambano
titán
válasz
haddent
#28748
üzenetére
"Linuxból hány van? Hány olyan okoskodó jajdekülöndisztró kell akik annyit csinálnak, hogy reskin aztán hello": de mi ezzel a gond? te, mint user, megkapod a választás szabadságát, hogy bizonyos célra optimalizált disztrót választhass. te, mint fejlesztő, nyugodtan csinálhatsz saját disztrót, ha akarsz. szerintem ez nem gond, sőt.
gond akkor van, amikor valaki marhaságot tesz kötelezővé. van vagy 400 disztró, egyet se vagy köteles használni. virágozhat minden virág.
-
Sokat lehetne találgatni, hogy a Debian miért emelte be a systemd-t a rendszerbe, de az tényként kezelhető, hogy nagyjából pofán köpték magukat, amikor ezt megtették - szakítottak a KISS filozófiával, a POSIX kompatibilitással - és nincs kétségem afelől sem, hogy ezzel elindították a Linux világot egy proprietary irányba és már nem mások, mint a Red Hat szócsöve.
-
haddent
addikt
válasz
bambano
#28739
üzenetére
Ez így van, sokkal régebbi. És sokkal kevesebben használják. Most felsoroltál 3 (?) bsd disztrót ezen kívül van még talán 2 (?) direkt tűzfal (pfsense, opnsense) aztán nagyjából kifújt. Linuxból hány van? Hány olyan okoskodó jajdekülöndisztró kell akik annyit csinálnak, hogy reskin aztán hello? Mégis minek.. Mindegy, eltávolodtunk. Nekem sem felhasználói, sem programfejlesztői (igaz, nem direkt systemd plugin / lib, hanem saját..) szemszögből nem volt vele soha gondom, gyors, működik és számomra intuitív is, én szeretem. Ha ezek közül bármi változik, nem fogom szeretni. Egyszerű vagyok
Ha meg van / lesz (és nem érdekel, hogy mi vóót ecce meg talán lesz ecce..) jobb alternatíva akkor ugrok oda. Na meg ha suse, redhat, centos beáll mögé, mert köszönöm nem fogom magam szopatni melóban direkt.. inf3rno felesleges a Dockernél alacsonyabb szintű jail/container. Minimális overhead van linux host - linux container esetén, sokszor mérési hibán belüli.. Ami meg annyira erőforrás szenzitív, azt meg úgyis C -ben, ASM -ben vagy max Rustban írjuk és eszünkbe nem jutna még csak virtualizálni sem, nem?
Az meg nagyon igaz amit írtál még a Dockerről, ezer más egyéb előnnyel együtt. Na tessék, itt is itt ez a nyekergős szenvedős vergődés... Ott a Docker, megy, tökéletes, jó, támogatott, elterjedt és már van kb. 5 másik """alternatívának""" csúfolt szerencsétlenkedés (nem a bsd jailre gondolok) -
Jester01
veterán
azért ha a spotify-on leállítom a zenét, hogy megnézzek egy youtube videót ne kelljen valahogy átadni, mert rohadtul nem fog menni normálisan a dolog.
Megkockáztatom, hogy alsa-ban régebb óta van szoftveres keverés (dmix/dsnoop) mint amióta a pulse létezik. Normális rendszeren az az alapértelmezett és csak akkor van baj ha egy adott program konkrétan a hw eszközt kéri. De a legtöbb programban ez egyébként is konfigurálható. Ha meg nem, arra nem az a megoldás, hogy kitalálunk egy új hangrendszert amit minden programba külön implementálni kell hanem megjavítjuk azt az egy programot ami hülye volt. A spotify-t amúgy nem ismerem de esélyes hogy nem hülye és be lehet állítani melyik hangeszközt használja. A teljesség igénye nélkül a chrome, firefox, mplayer, xine, xbmc, wine, teamspeak, openal mind kiválóan működik alsa-val.
Az egyetlen pulse szolgáltatás ami kicsit hiányzik az az alkalmazásspecifikus hangerőszabályzás de általában ezt tudják a programok maguk.
-
bambano
titán
"A klasszik BSD style init lényegében egy shell scriptet indít, esetleg több shell scriptet, rohadtul nem a stabilitás mintaképe.": értem, tehát az egy darab, ezer éve használt, debuggolt init shell szkript az instabil, a rakás systemd szkript meg stabil.
kizártnak tartom, hogy magamévá tegyek egy ilyen véleményt systemd-től függetlenül.
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód": ez csak annyit jelent, hogy a teszteset írók munkája se ér egy vödör csavart se.
"service fájlt írni elég egyszerű.": és működő service fájlt?
"a sysvinit buta, mint a franc": aki ért hozzá, az ezt a tényt pozitívumként kezeli, nem hátrányként. érdekes módon én mindent meg tudtam oldani vele triviálisan.
"A gcc talán a legkomolyabb compiler jelenleg": melyik gcc? és miért nem az intel c fordítója a legkomolyabb?
-
válasz
bambano
#28740
üzenetére
minek kellene több programból használni a hangrendszert??? Pl. azért ha a spotify-on leállítom a zenét, hogy megnézzek egy youtube videót ne kelljen valahogy átadni, mert rohadtul nem fog menni normálisan a dolog.
Régen nem csak pulseaudioval lehetett szívni, hanem anélkül is Manapság simán csak megy, nem érdekel különösebben mi van alatta."A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan.": merugye a systemd az nem egy szkript gányolás... A klasszik BSD style init lényegében egy shell scriptet indít, esetleg több shell scriptet, rohadtul nem a stabilitás mintaképe.
(#28741) inf3rno Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód, ami fent van a githubon. Daemon fejlesztői szempontból meg egy standardnak mondható interfész, service fájlt írni elég egyszerű.
Irni kell rá egy pár soros scriptet, ami elfedi a különbségeket, ha ennyire fontos neked.
Azért vannak különbségek voltak különbségek a distrók között, mert a sysvinit buta, mint a franc és szét kell hekkelni, hogy használható legyen. Ez a script hidd el nem pár soros lenne, meg ma már igény sincs rá, emlékszem régen mekkora szívás volt a home serveren a transmissiont daemonként beizzítani, ma simán megy, mert service fájl bárki tud írni.nem emelnék be gondolkodás nélkül egyébként stabil rendszerekbe Szerinted egy Redhat vagy SUSE szintű helyen mennyi agyalás előzött meg egy ilyen váltást? Komolyan azt gondolod, hogy csak úgy eszébe jutott valakinek, hogy akkor cseréljük le a full initet aztán megcsinálta? 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.
Elvileg a musl a szabvány követő, és a gcc ami rosszul lett implementálva. A gcc talán a legkomolyabb compiler jelenleg, talán az icc játszik még ezen a szinten, de a gcc mindenképpen a legelterjedtebb. Az, hogy mennyire szabvány követő csak a flageken múlik.
-
inf3rno
nagyúr
válasz
bambano
#28740
üzenetére
"Az én rendszereimet meg hagyja békén, mert az én fizetésem függ tőlük és ezért harapok."
Szerintem erre az egész helyzetre csak az lenne hatással, ha az adakozók elvonnák a támogatásokat a systemd-s rendszerektől, és a systemd nélkülieknek adnák őket. Ha eddig sikerült áttolni a potter dolgait Debianba politikai hátszéllel, akkor ezután is menni fog.
Nekem nem ritka, hogy zene mellett megy valami más is, pl játék, valami youtube video, stb. Szerintem legalább két hangforrás keverésére szükség van. Ami igazán jó lenne, ha tudnám a két hangot eltérő eszközökre küldeni, de akár még olyat is el tudok képzelni, hogy pl egy netkávézóban többen használnak egy gépet több kijelzővel és több fejhallgatóval. Talán létező problémát old meg a pulseaudio, de ha egy instabil bughalmaz, akkor továbbra sincs értelme használni...
-
inf3rno
nagyúr
válasz
haddent
#28733
üzenetére
Lement a szerkesztési idő. :S Az egy iránnyal egyetértek, de ezt nem így csinálják normálisan. Csinálnak egy szabványt, hogy ilyennek kell lennie egy startup scriptnek, aztán azt a szabványt valósítják meg eltérő rendszerek. Nem tudok róla, hogy Linux-nál lenne ilyen szabványosító szervezet, de ráférne ugyanúgy, ahogy pl a webre megy a W3C. Talán egy fokkal demokratikusabb módon, hogy ne fél tucat ember döntsön egy-egy szabványról, de ne is bárki, aki az utcáról beesett.
Az, hogy disztrónként eltérő mi hol van igazából nem számít. Irni kell rá egy pár soros scriptet, ami elfedi a különbségeket, ha ennyire fontos neked. Tutira van már ezer létező dolog a témában.
Elvileg a musl a szabvány követő, és a gcc ami rosszul lett implementálva. Üdv. a való világban Neo.
Sajnos sok olyan dolog van Linuxban, ami azért olyan amilyen, mert valaki 30 éve tákolt valamit, ami félig használható, és mindenki más lusta volt újraírni. Nem mintha ez más OS-ekre nem lenne jellemző. Amennyire én tudom Windows-ban is vannak évtizedes kódok. -
inf3rno
nagyúr
válasz
haddent
#28733
üzenetére
Elvileg a BSD jail hasonló, mint az LXC, eggyel alacsonyabb szintű, mint a Docker. A Docker pl nekem azért jó, mert beírom, hogy hardened alpine dockerhubon, aztán nem kell security expert-nek képeznek magam hónapokig, hogy egy normálisan beállított rendszeren menjen a webszerver. Nyilván ennek nem csak előnye van, de mindenkinek véges az ideje...
Fejlesztői szemmel pont, hogy a systemd nem összeszedett. Lehet, hogy felhasználói szemmel annak tűnik, de a moduláris felépítés alapvető ahhoz, hogy egy nagy közösség tudjon hozzáfejleszteni. Az alapján, amiket a systemd-ről olvasni, inkább zárt forrású kódhoz való megközelítés, aminél egy szűk fejlesztői csapat dolgozik a kódon. A BSD-ről eddig az a benyomásom az alapján, amit linkeltem, hogy átgondoltabb, mint a Linux, viszont valszeg emiatt és a kisebb közösség miatt lassabban is fejlődik. A nagyobb közösség meg mindig hozza a potterhez hasonló fazonokat, úgyhogy van ennek előnye és hátránya is. Igazából az utóbbival se lenne gond, ha helyén kezelnék a fazont és a projektjeit és nem emelnék be gondolkodás nélkül egyébként stabil rendszerekbe. Ez már inkább valami politika lehet, másképp nem tudom elképzelni, hogy ilyesmi előforduljon.
-
bambano
titán
"A systemd amúgy az OS X initjére hasonlít erősen, nem a windowsra.": én nem arról beszéltem, hogy a szolgáltatásai mire hasonlítanak, hanem arról, hogy milyen szemlélettel programozták le. Ez a nagy bloatware egybe-minden-vackot szemlélet ez windows. Ez az állítás nem zárja ki, hogy beleértsd, hogy akkor az osx-et is lewindowsoztam.
"Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re.": mert a deb alapú csodák tökéletesen működtek külsőleg oktrojált szemét nélkül is. Semmi szükség nem volt rá, hogy az rpm kitalálójának alkalmazottja szétcsessze a deb alapú csodákat is. Egyébként pöcstering már kifejtette, hogy a csomag rendszert is meg akarja reformálni meg a home könyvtárakat is. Csak azt nem értem, miért nem tette még helyre senki. Ha osx-et meg windowst akar csinálni a debianból, tegye meg otthon magának. Az én rendszereimet meg hagyja békén, mert az én fizetésem függ tőlük és ezért harapok.
"A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez": nem, nem szükséges. De hagy emeljem már ki a korábbi állításomat ismét: sokkal könnyebben elfogadnák az emberek pöcstering lomjait, ha azok nem lennének tele hibával. És könnyebb lenne elfogadni pöcsteringet, ha amikor egy hibára reagál, a válasza nem tűnne totál elmebetegnek.
"Az ALSA magában nem elég több programos használathoz": minek kellene több programból használni a hangrendszert??? Az olyan lenne, mint amikor egy társaságba kerülsz több nővel, és egyszerre pofáznak mindenféléről. Az ember füle nincs felkészítve arra, hogy több, különböző audio streamet értelmezzen.
"A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan.": merugye a systemd az nem egy szkript gányolás...
-
bambano
titán
válasz
haddent
#28733
üzenetére
"a BSD -k mellett az érvelés Linux-szal szemben mindig az volt, hogy sokkal összeszedettebb": azért tűnhet messziről összeszedettebbnek a bsd, mert *SOKKAL* régebbi (úgy értem, le van maradva, mint állat), mint a linux. Amikor utoljára megnéztem, a töredékét tudta, a töredéke mennyiségű szoftver volt rá, és brutálisan ócska volt a kernele a linuxhoz képest. Tudásban nagyjából a 2.4.x-es linuxok szintjén járt, vagy még előtte. Például nem volt benne rendes smp, nem volt benne multithreaded hálózati stack, rotfl.
egyébként ja, a bsd-k sokkal összeszedettebbek, merugye nincs openbsd, freebsd, netbsd, pcbsd, meg freenas meg hasonlók... ja, de, mégiscsak töredezett az is, legalábbis a felhasználói bázisának nagyságához képest... nincs elég emberük, hogy széttördeljék
"Baromira nem érdekel melyik lesz az irányvonal, de ugyan már legyen már egy irány": volt egy irány: svr4 init. A debian rc rendszere pontosan ugyanúgy nézett ki, mint pl. a solarisé. Emlékeim szerint a slackware-é is ugyanilyen volt. Majd jött az okoskodó redhat, aki mindig mindenben mást csinált és sajnos túl ritkán verték érte pofán (lásd gcc 2.96), és elkezdték tördelni az egységességet. Hol is dolgozik pöcstering?
-
válasz
Jester01
#28735
üzenetére
Az, hogy a hangkártyát normálisan tudja használni több program is egyszerre elvárható egy modern rendszer esetén.
Igen, mert a deb alapú csodák már eddig is stabilak voltak. Maximum a debian, az ubuntu mindig is egy bughalom volt. Valahogy ilyen SUSE, Redhat simán működnek systemd-vel is, meg a openSUSE, Fedora, CentOS hármas is.
beletúrkálsz a megfelelő scriptbe mert pontosan érted mi miért felelős és hogyan működik Magyarul gányolsz, mert rendesen megoldani nem sikerült, aztán a következő update megint szétcseszi. Amúgy a systemd-ben általában elég könnyen megnézhető mi döglött meg, sokkal könnyebben, mint régebbi rendszereken, plusz hatalmas előny, hogy minden distrón elég hasonló. Nincs gányolva buta sysvinit fölé ezer féle script halom.
Nem kell windowst csinálni a linuxból aki azt az architektúrát kedveli az telepítsen windowst egyből. Továbbra sem a windowsra hasonlit a systemd, hanem az OS X-re, ami amúgy certified UNIX.
-
Jester01
veterán
A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez.
A feltétlen szükséges kicsit túlzás, én lassan 30 éve megvagyok nélküle. Mellesleg a felhasználói hang problémák 90%-a pulseaudio miatt volt abban az időben amikor még részt vettem egy program támogatásában.
Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re.
Igen, mert a deb alapú csodák már eddig is stabilak voltak. Semmit nem lehet nyerni a systemd-vel csak fejfájást ha valami mégse működik mert akkor nem annyi, hogy beletúrkálsz a megfelelő scriptbe mert pontosan érted mi miért felelős és hogyan működik. Plusz bizonyos disztrók használóit még érdeklik olyan dolgok mint a szabadság és a unix filozófia. Nem kell windowst csinálni a linuxból aki azt az architektúrát kedveli az telepítsen windowst egyből.
-
válasz
bambano
#28719
üzenetére
A systemd amúgy az OS X initjére hasonlít erősen, nem a windowsra. Az OS X meg certified unix.
Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re. Az RPM alapú distrók egyértelműen nyertek stabilitásban a váltás után.
(#28721) Jester01 A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez. Az ALSA magában nem elég több programos használathoz. Azért a mostani állapot előtt voltak érdekességek.
(#28733) haddent A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan. A sysvinit meg egy olyan szintű legacy kód, hogy évek óta nem mert hozzányúlni senki.
-
haddent
addikt
válasz
inf3rno
#28732
üzenetére
BSD -n van saját konténerizáció, nem Docker
Pont ezt akartam egyébként felhozni, hogy a BSD -k mellett az érvelés Linux-szal szemben mindig az volt, hogy sokkal összeszedettebb, nem ennyire szétszórt szanaszét ahogy ivana is írta "melyik disztrón vagyok?" Na most a systemd ezt (is) hivatott kicsit rendszerezni, és jól csinálja, ahogy írta a kolléga is.
Félreértés ne essék, én sem a fejlesztőjét sem a systemd -t nem szeretem és nem kötődöm hozzá. Baromira nem érdekel melyik lesz az irányvonal, de ugyan már legyen már egy irány, pl. ami mögé az enterprise server linuxok beállnak a többi kis szaros meg úgyis követi. Legyen már egy helyen, egy szintax szerint egy féle upstart script meg miegyéb.. Mert az kriminális ami előtte volt
Akinek meg ez az utópia (mondom, függetlenül, hogy systemd vagy más, nem érdekel! csak legyen egy uniform, ajánlott vanilla config) nem tetszik az természetesen továbbra is használhat bármi mást, csakk akkor szívjon vele személyesen és egyedül kivételesen ő, nem a sysadmin amikor egyszerre 4 distroval dolgozik rajtuk 15 különféle cuccal és mindegyiknek, még az azonosoknak is tök máshol és máshogy van minden hülyeségük..De ez továbbra is megfigyelhető, meg úgy ez jellemző a linux közösségre és pont ezért is szólják le, pontosan többek között a BSD -s srácok. Mert mindenki mindent IS jobban tud a másiknál és képtelen bármiben is megegyezni, mindenki mindent kicsit máshogy csinál. Mert pl. biztos ku.... fontos és lényeges, hogy ne "www-data" legyen hanem "www". Meg ne apache2 -nek hívjuk, hanem httpd -nek, de inkább mégis apache -nek stb stb... Na ez otthonra elmegy szórakozni, de máshova nem.
Épp ezért mondom, hogy szépen legyen csak egy "ajánlott", vagy bevállt, biztosan működő cucc, aztán mivel open source, majd akinek az nem begyere az gányol magának otthon mást
+1 elvont lelkizős kérdés: az miért nem gond, hogy kivétel nélkül az összes linux használja a GNU alapprogikat?
Ja várjunk.. pontosan van olyan elmebeteg állat aki csinál disztrót ami nem gcc -t használ -
inf3rno
nagyúr
válasz
samujózsi
#28731
üzenetére
Elvileg Docker sem jó rajta meg secure boot sem. :S Kár érte, pedig dícsérik, de gondolom túl kevesen fejlesztik. Azért kipróbálom valamikor. Hardverrel nem hiszem, hogy gond lenne, asztali és szerver gépek, nem egzotikus egyik sem, kivéve a DAC az asztali gépen. Azt lehet, hogy el is adom emiatt, mert csak Windows driver van hozzá, aztán veszek egy másikat, amit szeret a Unix is. Általában használt dolgokat veszek, ilyen szempontból meg még előny is, mert néhány éves dolgokhoz azért már szokott lenni Linux driver.
-
samujózsi
senior tag
válasz
inf3rno
#28728
üzenetére
Szimpatikus rendszer, de nagyságrenddel kevesebb felhasználója és fejlesztője van, emiatt lassabban fejlődik, a hardver támogatása meg a linuxét is alulmúlja. Én az egyik notebookom, akkor még egzotikusnak számító wifi adaptere miatt voltam kénytelen lemondani róla, amikor ki akartam próbálni élesben is. Utóbb meg az egyik java alapú IDE nem működött, akkor letettem arról is, hogy virtuális gépen használjam.
-
-
bambano
titán
válasz
inf3rno
#28725
üzenetére
a deuvan például összekeveri az ethernet interfészeket telepítés után. én nem tudok olyan disztróval dolgozni, ami telepítés után nem érhető el, mert a másik ethernet lett az eth0.
a systemd-ről meg annyit, hogy nem valós problémákat talál fel. tehát például lehetne probléma, hogy mennyi idő alatt bootol egy linux. csak ki a bánatos francot érdekli, hogy 10 másodperc vagy 4, amikor egy csomó ibm szerveren a raid vezérlő kernele 300 másodpercig bootol. Ha systemd-vel 307 másodperc alatt bootol be a debian, svr4 inittel meg 312. és akkor mi van? miközben ritkábban, mint évente egyszer kell bootolni.
ezzel szemben meg ha nem teljesen abban a sorrendben stackeled össze a raidet, az lvm-et meg a drbd-t, ahogy az ostobenkó elképzelte, akkor fél éves sz.pás kideríteni, hogy te írtad rosszul a mount unitot vagy a köcsög szkriptjei nem működnek (hint: utóbbi). Ezt a fél évet ki fogja kifizetni?
-
-
samujózsi
senior tag
-
inf3rno
nagyúr
válasz
samujózsi
#28714
üzenetére
Nagyjából én is ezt találtam erről a Harry Potterről annak idején. Nekem az jött le, hogy túl nagy falat ez neki, amit csinálni akar, és nem ért annyira nagyon hozzá, szóval inkább systemd ellen vagyok. A kritikát meg nagyon nem bírja, ami miatt szintén inkább hanyagolom a szoftvereket, amiket ő ír.
-
bambano
titán
a systemd-ben levő cuccok jelentős százaléka nem működik.
megismétlem: NEM MŰKÖDIK. az svr4 init töredékét se tudta annak, amit a systemd, de azt mindig megcsinálta jól.a másik probléma, hogy a unix attól lett unix és sikeres, hogy kis, egyszerű építőelemekből van összerakva. van másik irányzat, azt windowsnak hívják. windowsos szemlélettel unixot programozni alapvető tévedés, mintha egy vegán arról kezdene vitatkozni, hogy a bélszínt mennyire átsütve szereti.
a harmadik probléma, hogy egy közösség által összelapátolt rendszerben egy őrültnek ekkora hatalmat adni a kezébe pocsék ötlet. különös tekintettel arra, hogy pöcstering nem először próbálkozott és bukott meg a hülyeségével, lásd pulse audio.
a negyedik probléma, hogy senkinek nincs joga ekkora pénzkidobásra kényszeríteni senkit, amennyibe a systemd megtanulására fordítandó erőforrás kerül, különös tekintettel arra, hogy egyébként a systemd nemlétező problémákra ad (rossz) megoldást.
tehát a 2-4 problémák akkor is a systemd ellen szólnának, ha egyébként az rendesen működik. de mivel ettől a rendes működéstől igen messze vagyunk, az, hogy a systemd megvalósítása egy rakás sz.r, übereli az összes többi problémát.
további probléma még, hogy például akik devuant fejlesztenek, fejleszthetnének debiant is, ha nem ette volna bele a fene a systemd-t a debianba. azzal, hogy systemd-s lett a debian, pazarlódik a munkaerő és lassul a fejlesztése. így eljutottunk odáig, hogy akik eddig debianra alapozták az életüket, azoknak most jelenleg nincs működő oprendszer választási lehetőségük.
-
A példád bőven nem ok arra, hogy egy bloatware fos legyen. Csinálja az initet és csak azt, semmi mást, de nem, már ez kezeli a logind-t, a tűzfalat, a networköt, a cups-ot... Ha elindítasz egy hosszú futásidejű ssh sessiont, majd kilépsz, cseszheted, mert teljesen kitakarítja a userspace-edet... Naccerű...
-
válasz
sh4d0w
#28713
üzenetére
Az a baj, hogy az alternatívái a sysvinit-tel az élen ezerszer szarabbak. Mióta systemd van ezerszer stabilabbak lettek a desktop rendszerek, a szerverek esetén meg a service konfiguráció lett jóval egyszerűbb. Vannak hibái a systemd-nek, de a többihez képest sokkal jobban működik.
Példa: Futtatni akarok egy scriptet boot alatt fejlesztőként...
systemd: csinálok egy service fájlt és bemásolom a megfelelő helyre.
sysvinit: milyen distrón vagyok?
-
samujózsi
senior tag
válasz
Jester01
#28715
üzenetére
Ez kicsit több, mint szimpla vélemény.
Ugyan mélyebben nem ástam bele magam, de logikailag kísértetiesen emlékeztet a felépítése a windows valamelyik korábbi verziójának a felépítésére (boot, init folyamatok, service-ek, függőségek satöbbi)
Persze lehet, hogy ez csak a felszín, de szóval na, azért mégis...
-
Jester01
veterán
válasz
sh4d0w
#28713
üzenetére
A systemd a linux windowsa
![;]](//cdn.rios.hu/dl/s/v1.gif)
samujózsi: ja látom neked is ez a véleményed. Egyébként sima debianban is le lehet cserélni a systemd-t a régi jól bevált sysvinit-re (én is így használom). A devuan pontosan nem tudom miben másabb, talán minden nyomát el is tünteti , még a libsystemd-t is
-
samujózsi
senior tag
válasz
haddent
#28712
üzenetére
Konkrétumot nem tudok linkelni, nem suoktam bookmarkolni az írásait. A systemd bug reportok környékén érdemes nézelődni, ha ilyet akarsz látni. Néha bicskanyitogatóan arrogáns stílusban reagál és természetesen mindenki hibás, csak ő a helikopter... én kb ezt láttam tőle.
Nekem nem volt dolgom vele, csak olvastam róla negatív kritikákat és emiatt néztem utána, hogy mennyi az igaz mindebből. Úgy tűnt, elég sok.
Systemd meg nagyjából a linux windows-osítása.
-
válasz
haddent
#28710
üzenetére
Mert egy határ szar? Mert bloatware módon minden alrendszert be akar nyelni? Mert kinyírhattad vele az alaplapodat? Mert a printer install szétcseszi a tűzfal konfigot, ettől függetlenül elindítja a networköt, de a sysadminnak nem szól róla? Mert sokmindent akar csinálni, de semmit sem jól? Mert Frawly fórumtárs (és még sokan mások) mostanság szívnak a seed service-szel, mert belassítja a bootot? Mert ha invalid username-mel indítottál bármit, akkor fallbackelt rootra (!)? Mert ha nincs DNS szerver a hálózatban a network indulásakor, akkor minden további értesítés nélkül fallbackelt a Google DNS-re? Mert... Mert... Mert...?
Mert az egész hóbelevanc törekvés a corporate linux létrehozására?
-
haddent
addikt
válasz
samujózsi
#28711
üzenetére
Őszinte leszek, az életben nem olvastam a Potter gyerekről egy sort se, le**** amíg működik a cucca
De most azért kiváncsivá tettél, linkelsz 1-2 olvasmányt amiből átjön, hogy miért nem szimpatikus? Bár legyünk őszinték, Linus és Stallman is elég hát special snowflake, én mégis bírom őket -
haddent
addikt
válasz
inf3rno
#28703
üzenetére
Évek óta Archozok desktopnak és itthon szervernek is, sőt, stikában melóban is az a desktopom
Minimál, friss, rolling release és mégis stabil, teljesen vanilla lényegében a pacmant leszámítva és a Wiki tényleg fenomenális. Nyilván nem eröltetem meg nem is lehet, neked lehet, hogy nem fog bejönni, de ha hasonlóban gondolkodsz egy próbát mindenképp érdemes tennedFrawly A Gentoo lényegében annyiban más az Archtól, hogy te buildelsz/compileolsz. Tudom, hogy ez egy óriási különbség, de én a mai világban mai procikkal ezt elenyészőnek érzem, minimális vagy talán mérési hibán belüli overheadet jelent szerintem a prebuilt. Igen, az a legszexibb, de az már tényleg nem éri meg, szerintem
Egyébként ha tényleg könnyű kezelésű cucc kell, nem akarunk ennyire elmenni a vadonba, csak ne legyen telehányva akkor én az Ubuntu Server -t szoktam ajánlani az óriási community és repok, tutorialok stb.. miatt
Systemd hitvitába nem akarok megint belemenni, de annyit csak nem bírok ki, hogy offtopicba ne írjam le, hogy személyes és linux sysadminos tapasztalatom szerint is az utóbbi idők legjobb történése linux körökben.. Fenntartható, stabil, implicit és rendkívül jól rendezett
-
samujózsi
senior tag
válasz
inf3rno
#28703
üzenetére
Arch-nak kiemelkedően jó a dokumentációja, talán a FreeBSD-nek volt hasonló színvonalú doksija amikor azzal próbálkoztam.
Viszont ha elkényelmesedtél az évek során, akkor esélyes, hogy már az arch telepítőjétől meghátrálsz.
Hacsak az elmúlt két évben nem kapott valami kevésbé fapadost, mint amivel én találkoztam. -
Frawly
veterán
válasz
inf3rno
#28702
üzenetére
A Devuan ugyanaz, mint a Debian, csak systemd nélkül. A Void minimalistább, de arra kevés a csomag, az a hátránya. Az MX-et kipróbálhatod, nem tudom mennyire minimalista a legkisebb .iso-juk, de az nem számít minimalista disztrónak, már régen sem, inkább gyenge gépes volt, mint minimalista.
-
inf3rno
nagyúr
válasz
haddent
#28700
üzenetére
Az Arch dokumentációját már elég sokat használtam, valamiért mégsem telepítettem még soha azt a disztrót. Lehet adok neki egy esélyt. :-) Igazából megint ott vagyok, hogy ki kéne próbálni 4-5 disztrót mielőtt döntenék. :-) Végülis pendrive-ról megoldható vagy esetleg virtuális gépen.
-
-
Frawly
veterán
válasz
inf3rno
#28699
üzenetére
A legminimalistább, desktopnak is jó disztró a Gentoo. Minimalista az Alpine is, de nem desktopra való, a Linux from Scratch meg nem disztró, hanem csak egy dokumentáció.
Kicsit „könnyebb” telepítésű az Arch, ArcoLinux, Debian minimal netinstall, Ubuntu minimal netinstall, ezek akkor, ha nem zavar a systemd (vagy kifejezetten kell systemd, mert olyan fullosabb DE-t használsz rajta, aminek kell, pl. Gnome3).
Ha systemd-mentes, de még mindig minimalista, de azért könnyebben emészthető rendszer kell, akkor Devuan netinstall vagy Void.
Az Arch, Arco vonalnak előnye a sok AUR-os csomag és a rolling frissesség. A Debian, Ubuntu, Devuan vonalnak előnye a sok csomag, sok extra tároló, hosszabb támogatási ciklus.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha meg van / lesz (és nem érdekel, hogy mi vóót ecce meg talán lesz ecce..) jobb alternatíva akkor ugrok oda. Na meg ha suse, redhat, centos beáll mögé, mert köszönöm nem fogom magam szopatni melóban direkt.. 
Azért vannak különbségek voltak különbségek a distrók között, mert a sysvinit buta, mint a franc és szét kell hekkelni, hogy használható legyen. Ez a script hidd el nem pár soros lenne, meg ma már igény sincs rá, emlékszem régen mekkora szívás volt a home serveren a transmissiont daemonként beizzítani, ma simán megy, mert service fájl bárki tud írni.
Ja várjunk.. pontosan van olyan elmebeteg állat aki csinál disztrót ami nem gcc -t használ 
Új hozzászólás Aktív témák
- Fujitsu USB Port Replicator PR09 docking station (1x5K vagy 2x4K felbontás) (DisplayLink)
- LG 25GR75FG - E-Sport Monitor - FHD 360Hz 1ms - NVIDIA Reflex + G-sync - AMD FreeSync - HDR 400
- Honor Magic7 Lite 512GB, Kártyafüggetlen, 1 Év Garanciával
- MacBook felváráslás!! MacBook, MacBook Air, MacBook Pro
- Gamer PC-Számítógép! Csere-Beszámítás! Mini PC! I5 10600KF / RTX 3060 12GB/ 16GB DDR4 / 1TB SSD
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest