Mondtam, hogy nekem csak a következő bajaim vannak a systemd-vel:
- nem init system, hanem eszköz a teljes kontrollra az userspace felett, és az "init system" csak a trójai faló volt, a név "systemd" viszont az első naptól mutatja, hogy mi is volt az eredeti cél...
- viszont az init system részt sem tudja rendesen megoldani, minden rendszeremen gondok voltak az átállással és migrációval eddig, és azóta is rendszeres kisebb-nagyobb glitchek vannak
- de a technikai problémákat mellőzve a legnagyobb bajom a systemd-vel politikai - minden kritikus szolgáltatást átirányít magára, én pedig sem a szoftverben/projektben magában (compile time Google DNS fallback, a legfrissebb root fallback bug, vagy az emlékezetes eset, hogy minden vacakba pl. a tmuxba próbáltak systemd supportot tolni, stb), sem a karbantartójában, sem a mögötte álló cégben (Red Hat) sem bízom kicsit sem...
- mellékesen a nevezett karbantartó korábbi szoftvereit (Pulseaudio, köhm) is kellően hulladéknak tartom, és mivel magam is írtam audio kódot eleget, ezért ez esetben még megalapozottnak is tartom a véleményem
- szóval minden rendszerem inkább Devuanra állítom át
Na itt elszakadt a csávónál a cérna, és elkezdett fröcsögni...
- Lennart Poettering az ő közvetlen jó barátja én meg itt sározom - Madarat tolláról, mondom erre én...
- a sysvinit egy karbantartás nélküli szar, amit senki sem akart bevállalni, szóval a systemd-t legalább karbantartják - well... a systemd karbantartását inkább hagyjuk... a sysvinit meg nem jó, de mindig van lejjebb.
- amúgy is gyorsabb a boot - Szerveren pont leszarom, mondom erre én, ellenben amikor a VM alatt futó KVM-be kell rendszeresen beVNCzni hogy összekaparjam a gépet egy-egy systemd-s széthalás után, vagy force-olni kell egy rebootot, mert nem létező dolgokra vár perceket (félórákat), az nem annyira vicces.
- és neki teljesen jól működik a systemd, semmi baja vele - A worksforme nem érv. Nekem meg doesnotwork, so what?
- a Devuan Linux egy szemét, és a karbantartóinak fingjuk sincs arról hogy mit csinálnak - Ezt nem tudom megítélni, de eddig működik, elég jól és lényegesen kevesebb "ezt most megint miért kellett" macerával mint a systemd-s rendszereim.
- az Apple is custom userlandet futtat, még sincs rinyálás - Az OS X-et egyrészt nem használom szervercélra, másrészt tíz év OS X használat alatt a custom Apple userlanddel és system services cuccokkal nagyságrenddel kevesebb problémám volt mint a systemd-vel az elmúlt év alatt, mióta az utolsó systemd nélküli LTS disztrókról is muszáj volt váltani...
- ha most nem váltok systemd-s rendszerre, a jövőben rohadt nagy problémáim lesznek, mivel minden desktop és egyéb rendszer a systemd felé megy - Ez kb. klasszikus FUD, szóval nice try, azt meg majd a jövőben meglátjuk, hogy mi lesz akkor.
- a systemd sokkal modernebb, és mindent kényelmesebb alatta bekonfigolni - Én meg azt látom hogy olyan gépeim, amik eddig gyakorlatilag évtizedeken át mentek gond nélkül és frissültek újabb verziókra, hirtelen heti szintű nyüsztetést igényelnek, mert valami nem megy, mint valami ócska tamagocsik, mert egy service restart vagy service leállítás is véletlenszerű problémákat okoz. Mindezt úgy, hogy a kutya sem kérte a tisztelt disztrógyártókat hogy tolják ezt a kacatot a gépeimre, sőt, opt out sem nagyon volt, ha már az a default.
- az userek mindig csak ingyen szoftvert akarnak, de nem akarnak foglalkozni a karbantartással - Ez nekem nem érv. Egyrészt magam is Open Source hozzájáruló vagyok, másrészt userek nélkül a szoftver léte értelmetlen. Én konkrétan ott tartok, hogy fizetnék, csak ne tolják az arcomba ezt a vackot. Amúgy is, ha valami szolgáltatást ingyen kapsz te vagy a termék, szokták mondani...
- tényleg úgy gondolom, hogy a sokezer Red Hat, IBM, Intel, SuSE, Debian, etc mérnök mind hülye, hogy a systemd-t tolják? - Őszintén? Nem. De a sokezer mérnök aki a Vistán dolgozott sem volt hülye - mégis, az userek többsége szempontjából egy rakás szar lett a végeredmény. Amúgy ez a klasszikus "egyél tehénszart, ötmilliárd légy nem tévedhet" érvrendszer. Ez nekem már a Windows 95-nél sem jött be, inkább OS/2-ztem vagy fél évtizedet.
Erre kiröhögött, és mondta, hogy menthetlen vagyok. Igazából csak mert én akarok dönteni, mit futtatok a gépemen és nem látom, hogy a systemd-vel csak a javamat akarja mindenki. Software freedom, corporate Linux módra. Szóval továbbra sem lettünk, én meg a systemd, jóbarátok. De igazából csak az érdekel, hogy nélküle egyelőre lényegesen alacsonyabb a vérnyomásom...
Poetteringről meg csak annyit, hogy minden projektben a rettentően produktív, de mérgező természetű emberekkel a legnehezebb kezdeni valamit. Duplán igaz ez nyílt forrású projektekre, ahol nincs egy "felettes" aki kirúghatná vagy megfegyelmezné őket. Vagy ha van, a céges céloknak még pozitív is, ahogy viselkednek (pl. lásd a Red Hat corporate policy-t, a projektek kötelező upstreambe tolásáról, hát így lett a systemd...). Poetteringnek legalább annyit a javára tudok írni, hogy - persze csak a saját egóját masszírozandó, de ez mellékes - a saját kacatjaival tolja magát, nem pedig takeoverel amúgy jól működő projekteket, mint sok más hasonszőrű szociálisan gyengén teljesítő teszi.
(És a Pulseaudio kapcsán még volt egy csörténk, megemlítve, hogy most már kötelező dependency a Firefoxhoz Linuxon - erre meg csak annyit tudok mondani, hogy miután bedőlt a Netscape 5 projekt és a korai Mozilla sem igazán haladt sehova, egyvalaki fogta a forrást, kitakarította, legallyazta, és aztán ebből lett a projekt zászlóshajója a Firefox (leánykori nevén Phoenix, első férjezett nevén Firebird) nagyon hamar. Én most is erre számítok - lévén a Mozillát közösségi "legyen mindenkinek jó" helyett ismét olyan corporate-style döntések hajtják, amik annó a Netscape és a korai Mozilla projekt vesztét ill. sehovanemhaladását okozták, miközben a piaci részesedés stabilan esik. Lásd még pl. a Rust, mint függőség erőltetését, ami lehet bármennyire jó (amúgy szvsz a koncepció az, de ez most mellékes), szintén a "kutya sem kérte", nagyjából, és sokkal inkább politikai mint technológiai okokból létezik mint függőség, ill. valamiféle felesleges előre menekülés, stb...)
Ha megváltozik a véleményem a jövőben a systemd-ről, frissítem ezt a postot. De addig is jó összefoglaló, amit linkelni fogok mint FAQ, ha már megint kérdeznek... :P
- Chain-Q blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
itt jartam
--
Vortex Rikers NC114-85EKLS
- A hozzászóláshoz be kell jelentkezni
én is
- A hozzászóláshoz be kell jelentkezni
+1
Ja és a Pale Moon fork úgy tudom nem tervezni dobni az alsa supportot.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
én is feliratkozom
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
szintén
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
az en wtf? ertetlenkedesem ott kezdodik, hogy milyen code review, tesztek es hasonlo nyalanksagok vannak a rathead-nel, ha ennyi szar dol ki a systemd-bol? Ha a poetteringhulye minden bug-nal, amit elkovet 1 cm-t none (sec. bug eseten 10 cm-et), akkor mar reg ulve kene nyalja a Holdat...
--
Allitsuk meg Andorrat!
- A hozzászóláshoz be kell jelentkezni
"ha most nem váltok systemd-s rendszerre, a jövőben rohadt nagy problémáim lesznek, mivel minden desktop és egyéb rendszer a systemd felé megy"
Ezeknek a magas szintű dolgoknak egyébként mégis mi közük a systemd-hez? Miért nem valamilyen absztrakt, jól meghatározott interface-en keresztül kommunikálnak, amit mindenki azzal és úgy valósít meg, ahogy akar? Ekkor a systemd csak egy megvalósítás lenne a sok lehetséges közül.
"És a Pulseaudio kapcsán még volt egy csörténk, megemlítve, hogy most már kötelező dependency a Firefoxhoz Linuxon"
Ugyanaz a kérdés mint az előbb, a Firefoxot miért érdekli, hogy az általa használt API-t épp a Pulseaudio fogja implementálni? Persze az lehetséges, hogy az API-t a Pulseaudio project definiálja, de attól még lehet rá adni más implementációt is.
- A hozzászóláshoz be kell jelentkezni
> Miért nem valamilyen absztrakt, jól meghatározott interface-en keresztül kommunikálna
Úgy vannak, ezt utáljátok DBus néven
- A hozzászóláshoz be kell jelentkezni
Én nem utálom, én csak kérdezek. :)
Viccet félretéve, akkor az az állítás nem igaz, hogy ezek a szoftverek függenének a systemd-től, vagyis nem fognak szaporodni Chain-Q problémái (legalábbis ami a systemd kerülésével kapcsolatos).
- A hozzászóláshoz be kell jelentkezni
És a végkimenetelt tekintve teljesen mindegy is, mert:
A., nem lesznek problémáim, mert minden nyílt interfészekre épült, ergó könnyen fejleszthetők alternatívák - és fejlesztenek is, és akkor igazam volt, hogy elkerülhető a systemd, ergó a "nélküle rosszul jársz", csak FUD volt.
B., problémáim lesznek mert tényleg mindenhez systemd kell majd, ergó igazam volt, hogy az egész csak egy kurva nagy corporate vendor lock-in akció ami a Linux userspace-t illeti, és amiből nem kérek, se így, se úgy. Őszintén, ha már ígyis úgyis "userként" vagyok kezelve, nem egyenrangú partnerként a saját rendszeremben, akkor inkább macOS-t futtatok, az legalább működik és nem tolakszik az arcomba mindenféle hülyeséggel. (Saját választásom, de kinek mi. Amíg van választásunk, addig jó, asszem ebben egyetérthetünk.)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Még a FreeBSD környékén is körül lehet nézni.
- A hozzászóláshoz be kell jelentkezni
"Őszintén, ha már ígyis úgyis "userként" vagyok kezelve, nem egyenrangú partnerként a saját rendszeremben, akkor inkább macOS-t futtatok, az legalább működik és nem tolakszik az arcomba mindenféle hülyeséggel."
Salamoni gondolat... mondom úgy, hogy már az almás billentyűzetnél a 0-t súrolja a produktivitásom.
- A hozzászóláshoz be kell jelentkezni
felesleges előre menekülés
hajbazer, te vagy az? :-)
egyébként jó a cikk.
pulseaudiot nem is tudtam h ő csinálta, nagyon nem mélyedtem bele ugyan. alsa-áztam mindig, csak az x11rdp miatt kellett foglalkoznom vele. de azon kívül hogy user módban a daemon idle timeout után leáll, nincs különösebb aggályom.
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
- A hozzászóláshoz be kell jelentkezni
Tamagocsi, ez talalo.
- A hozzászóláshoz be kell jelentkezni
Ez a Pöttering lesz a Linux-világ Soros György-e.? ( ugye Trey )
Imádom a Devuan-t, az AntiX-ot, az MX Linux-okat és nem szeretem ha rám kényszerítik sem a systemd-t, sem a Unity-t, majd én eldöntöm, hogy akarom-e
--
God bless you, Captain Hindsight..
- A hozzászóláshoz be kell jelentkezni
> a sysvinit egy karbantartás nélküli szar, amit senki sem akart bevállalni
Egy tonna egyéb init rendszer van a sysviniten és a systemd-n kívül.
- A hozzászóláshoz be kell jelentkezni
a sysvinit egy karbantartás nélküli szar, amit senki sem akart bevállalni, szóval a systemd-t legalább karbantartják - well... a systemd karbantartását inkább hagyjuk... a sysvinit meg nem jó, de mindig van lejjebb.
Csak így ehhez szólnék hozzá: még ha a sysvinitet valaki el is kezdi karban tartani, a tonnányi init scriptre még mindig keresni kellene maintainert. Mert ott azokat is annak kell tekinteni. Ráadásul ott vagy, hogy ahhoz, hogy N maintainer (per disztró!) K különböző scriptjén bármi következetességet elérj, N ember kell, K különböző forráskódba (mert lássuk be, az init script is aktívan futó kód) kell belenyúlni.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Ez igaz a systemd configokra is.
Nem a systemd szallitja, hanem az adott alkalmazas.
- A hozzászóláshoz be kell jelentkezni
Viszont nem futó forráskódok.
pl.: valamelyik másik topicban említettem, hogy Jessie-n belefutottam, hogy a winbindd init scriptje gyakorlatilag egy killall winbindd-ot indít [start-stop-daemon-on keresztül, de a man page második bekezdése ezt írja le], amivel pl. egy LXC hoston újraindított winbindd az összes konténerben is lelövi, ha futott... A Stretch-ben már rendes unit fájl van hozzá (a Samba upstream unit fájlok, és a systemd ad PID-et hozzá - így rendesen működik.
Itt volt egy bug, amit a package maintainer tett a rendszerbe azzal, hogy egy új, aktív komponenst tett a csomagba.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Ertem, amit mondasz, de attol meg karban kell tartani.
- A hozzászóláshoz be kell jelentkezni
Na ja, de csak egy példányban (az upstreamnél), és nem disztró+disztró főverzió páronként egyszer. (és csak egy leíró fájl, nem aktív forráskód)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Az upstream-nel, ha az megirta, ha nem, akkor nem ott.
Es nem distro verziokkent, hanem systemd veriokkent. Hacsaknem valtozik soha, de annak mi ertelme lenne?
- A hozzászóláshoz be kell jelentkezni
Egy systemd unit fájlnak olyan túlságosan nem kellene változnia, vagy ha változik, akkor valószínűleg a programban is volt valami változás (ill. időközben megjelent egy új feature a systemd-ben, amit a disztró használna, de szvsz. a vendor által szállított konfigok a konfig opciók ~10%-át használják ki, az adminra és drop-inekre bízzák)
Nézd meg, a samba service-k unit fájljai mennyit változtak a létrehozásaik óta: nmbd 4 változás, samba 3 változás, smb 4 változás, winbindd 5 változás. Ez 2011 okt 28 óta - az akkori verzióhoz képest a különbség a Type-ban van (kapott systemd integrációt 2014-ben), kaptak ExecReload-ot [egyébként a systemd ajánlással szembemenve...] és egy LimitCORE direktívát.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
A sima init scriptek sem valtoznak tobbet szerintem.
Szerintem a kulonbseg es a lenyeg abban van v. kene, h legyen, h nem 1000 csillio fele lesz, lenyegeben mindet ra kellene tudni huzni 1-2 kaptafara.
- A hozzászóláshoz be kell jelentkezni
A sima init scriptek sem valtoznak tobbet szerintem.
Itt mondjuk a Samba kivétel, mert egyrészt egy mindent bele szemétdomb, másrészt volt egy nagyon nagy főverzió váltás közben, de wheezy és jessie között (pedig csak egy release különbség, két év különbséggel) gyakorlatilag a felismerhetetlenségig nulláról újra írták :)
Szerintem a kulonbseg es a lenyeg abban van v. kene, h legyen, h nem 1000 csillio fele lesz
A kaptafa is működik (gyakorlatilag minden disztrónak van kaptafája :) ), ami miatt _én_ személy szerint preferálom a systemd-t, az egyrészt az, hogy 3rd party-k sem tudják elbarmolni (disztón belül még egész konzisztensen tarthatók az init scriptek, a zárt forrású cuccoknál meg kb. a legbiztosabb írni sajátot :) ), másrészt hogy a függőség-kezelés sima konfigurációvá lép vissza (ill. sok minden más is).
Talán az egyik legjobb példa: a GlusterFS doksija javasolta, hogy ne az adat partíció gyökerében hozzuk létre a brickeket [vagy hogy hívják, régen játszottam vele], hanem azon belül egy külön mappában - mert így ha elindul a GlusterFS úgy, hogy nincs felcsatolva az adat partíció, akkor sincs gond, mert nem találja a mappáját és leáll; ami működik, de szvsz. egy nagyon csúnya hack; systemd-vel simán csinálsz egy dependency-t a megfelelő mount unit-ra és megoldottad, a glusterd el se akar majd indulni; ha ezt a javasolt megoldással, egy drop-in mappában csinálod, akkor a systemctl kapásból megmondja, hogy a disztró defaultoktól eltérsz, megmondja, hol vannak a saját konfig kiegészítések, és bele tudsz nézni a helyi sajátosságokba.
Init scriptnél sok más választásod nincs, ezt bele kell írnod az init scriptbe, aztán állandóan diffelned az rpmnew/dpkg-new fájlokkal :)
(én pl. már a cron-t is ahol csak lehet, kiváltom systemd service és timer unitokkal, nagyon kényelmes, hogy tudsz egy systemctl start backup
-ot írni és mindig garantáltan ugyanazzal a környezettel fog lefutni. Ami ugyanaz a környezet lesz, mint amikor a timer miatt indul. És bárhogy is indítod, a journalból ki tudod kérni a teljes kimenetét. Egy systemctl status backup
-pal le tudod kérni, sikeres volt-e az utolsó futtatás [esetleg még mindig fut-e] stb.)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Gyakorlatilag mindenben egyetértünk, de hát ez már csak így van velünk, hazaárulókkal. :D
Engem elsősorban az zavar benne, hogy a választás szabadságát veszi el, amiről nagyrész a szabad szoftverek szólnának. Említetted a politikai vonalat, gyenge párhuzamot tudnék fölvonni azzal, hogy a szólásszabadság korlátozása is igencsak irritál, bármilyen politikai szereplőtől is érkezzen az "igény" erre (de többnyire a PC/mainstream szokta ezt erőltetni).
Szomorú látni, hogy a Linux userlanddel ez történik, de mivel a történelem mindig ciklikus, ezért lesz ez még így se.
És mint fölöttem valaki megjegyezte, van másik n+1 választható init-rendszer. BSD-ken is van rc.d, Solarison az SMF, macOS-en a launchd - biztos, hogy mindegyiknek vannak hiányosságai, de egyik sem egy akkora katasztrófa, mint a systemd. Pöttering valahogy nem tud jó helyről és igényesen kódot lopni.
--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”
- A hozzászóláshoz be kell jelentkezni
Köszi a post-ért Chain-Q & subscribe.
> van másik n+1 választható init-rendszer.
Nálunk is hörögnek systemd-re rendesen, de nagyvállalati környezetben sajnos nem úgy megy hogy pl. RHEL7 lesz systemd nélkül :(
> BSD-ken is van rc.d
Nem is volt vele bajom sose, fene vinné el ezeket a régi, kiforrott, működő dolgokat ;) /Nagyvállalati környezeten kívüli maszek világ, bent nincsenek BSD-k./
____________________
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
Nagyvállalati környezetben nem érdekel, hogy mit kell használnom, amíg tudok vele dolgozni ÉS megfizetik. Cold, hard cash. :) No meg azért se, mert ha valami nem megy, akkor úgyis lehet a supporttal üvöltözni, hogy működjön a szarjuk, ha már egy vagon pénzt fizetünk. :D
Mondjuk perpillanat nem zavar a Redhat ámokfutása, mert leginkább Solarist tologatok.
--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”
- A hozzászóláshoz be kell jelentkezni
+1
Annyit tennék, hozzá, hogy amit Pötyibácsi nem ért, hogy az egységesítés és az egybeépítés nem ugyanaz. A systemd gőzerővel gyúr egybe, egymáshoz nem tartozó szolgáltatásokat, saját függőségi rendszert alakítva ki. Azt már megtanulhattuk volna, hogy a agyonintegrált megoldások, mindig is retkes nagy szívásokhoz vezetnek, mert ha kiesik egy komponens összeomlik az egész. Ugyancsak az egylábon álló rendszerek hibája, hogyha kirúgjuk a lábat, akkor összeomlik az egész.
Az init rendszereknél nem volt ilyen probléma, mert minden egyes script a maga önálló kis világa volt.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
- A hozzászóláshoz be kell jelentkezni
+1
megtanulhattuk volna, hogy a agyonintegrált megoldások, mindig is retkes nagy szívásokhoz vezetnek
Hát ez az, épp ez volt a Linux erőssége. Olyan volt, mint egy szerszámosláda, így igen nagy volt az ember szabadsági foka abban, mit milyen eszközökkel, hogyan valósítson meg. Lennart ennek tesz keresztbe. Mondom ezt úgy, hogy nekem nincs bajom a systemd-vel, már-már tetszik. Ennek részint az is oka lehet, hogy Fedora mindig a legfrissebbet, vagy közel legfrissebbet szállítja, így azok a gyermekbetegségek, amelyek korábban voltak benne, már nincsenek. Viszont az nem tetszik, hogy már minden bele van lapátolva. DNS kliens mit keres benne? És NTP? Ha ez így megy tovább, lesz desktop környezet meg böngésző is a systemd-ben...
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Fedora alapból bekapcsolja szállítja ezeket? (mmint a resolved-t és a timesyncd-t?)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
A Fedorat nem tudom, nem elek RPM alapu disztrokkal. Az Ubuntu 16.10+ defaultbol igen, legalabbis a resolved-t.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
A timesyncd-t meg semtaláltam, pedig grep-pel is kerestem. A másikat meg nehezemre esik értelmezni.
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: disabled)
Active: inactive (dead)
Értem, hogy eredendően tiltott, ugyanakkor nem emlékszem arra, hogy én engedélyeztem volna. Talán valaminek a függőségeként? Aztán, noha engedélyezett, de mégis inaktív. Pedig nem mondtam neki stop-ot. Most akkor mi van?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Passz, Süsü fel se teszi [lehet, hogy valami a D-Bus felületén kérdezett tőle] :)
De azon túl, hogy futtatod a resolved-t, még az nsswitch-be fel kell vinned a hozzá tartozó modult (nss-resolve) vagy meg kell adnod 127.0.0.53-at a resolv.conf-ban.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Poettering
- A hozzászóláshoz be kell jelentkezni
Igen, ő a főbűnös. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
csak arra szerettem volna ramutatni a magam esetlen modjan, hogy ez a neve es nem az hogy Pöttering.
- A hozzászóláshoz be kell jelentkezni
Szervusz jövevény!
Örülünk hogy megérkeztél országunkba. Kérlek szentelj időt nyelvünk sajátosságainak megismerésére!
További kellemes időtöltést!
- A hozzászóláshoz be kell jelentkezni
20k+ uid-dal (=2 hetes lofaszjoska vagy) kicsit halkabbra kene allitani az arcodat...
--
Allitsuk meg Andorrat!
- A hozzászóláshoz be kell jelentkezni
Ha jol sejtem, mar nagyon regota tartja a hup bolondja cimet kulonbozo reinkarnaciokkal:)
- A hozzászóláshoz be kell jelentkezni
Már megint?
:(
☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)
- A hozzászóláshoz be kell jelentkezni
Egyrészt majdnem két éves lófaszjóska, másrészt a uid fetisizmus egy maréknyi emberen kívül nem érdekel senkit. :)
- A hozzászóláshoz be kell jelentkezni
Jogos, javítottam. Látszik túl régóta élek német nyelvterületen, már automatikus az oe -> ö konverzió, és nem ellenőriztem az írásmódot.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
"Are you poettering?"
"No, I'm screwing up my system."
"So you're poettering it, aren't you?"
- A hozzászóláshoz be kell jelentkezni
Egyre jobban tetszik a Slackware, vagy Devuan. No meg persze a FreeBSD.
- A hozzászóláshoz be kell jelentkezni
Én mostanában vagyok úgy a FreeBSD-val, mint tizen-huszon éve a Linux-szal. Feltelepítem, használom, valamit rohadtul nem tudok megoldani, szenvedek vele, megunom, telepítek helyette Debiant (vagyis mostanában Devuant). Aztán megint elkap a gépszíj, és kezdődik minden elölről...
- A hozzászóláshoz be kell jelentkezni
valamit rohadtul nem tudok megoldani, szenvedek vele
Biztos jó a magányos harcos szerep, de itt a HUP-on lehet, hogy tudna valaki segíteni.
- A hozzászóláshoz be kell jelentkezni
a rettentően produktív, de mérgező természetű emberekkel a legnehezebb kezdeni valamit
"Az a legrosszabb, amikor a hülyeség a kitartással párosul."
- A hozzászóláshoz be kell jelentkezni
"I no longer feel like I can trust "init" to do the sane thing."
- A hozzászóláshoz be kell jelentkezni
"tényleg úgy gondolom, hogy a sokezer Red Hat, IBM, Intel, SuSE, Debian, etc mérnök mind hülye, hogy a systemd-t tolják?"
A többiről nem tudok mit mondani, de nem biztos hogy itt azzal az IBM-mel érvelnék, amelyik 15 éve féltéglákkal fejelget és csodálkozik, hogy valamiért, valahonnan a szemébe csorog a vér.
- A hozzászóláshoz be kell jelentkezni
su
Ha már Devuan, feltelepítettem próbából, és másik gépbe áttéve nem akar csatlakozni a hálózathoz, pedig a megfelelő modulok be vannak töltve
Nincs ilyen eszköz, írja
eth0, eth1
- A hozzászóláshoz be kell jelentkezni
ifconfig -a
Ujabb kerneleknel mar mas a neve.
- A hozzászóláshoz be kell jelentkezni
Szia
Jav
Sikerült!
Habár a Devuan még csak 3.16-os kernel
Köszi!
- A hozzászóláshoz be kell jelentkezni
Kernelfüggő ez a "csoda"? Én azt hittem, az udevd hozta az új neveket.
- A hozzászóláshoz be kell jelentkezni
Az udev intézi a device rename-et. Lásd pl. ezt a szösszenetet egy Ubuntu 16.04 dmesgből:
[ 1.491649] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:5a:55:c1
[ 1.491655] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 1.491681] ahci 0000:00:0d.0: version 3.0
[ 1.492143] ahci 0000:00:0d.0: SSS flag set, parallel bus scan disabled
[ 1.492293] ahci 0000:00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
[ 1.492296] ahci 0000:00:0d.0: flags: 64bit ncq stag only ccc
[ 1.493623] e1000 0000:00:03.0 enp0s3: renamed from eth0
Ez a rename az udev része ami most ugye alapból a systemd része, és ha nincsen persistent rule egy interfészre, akkor az ún. "predictable interface names" stratégiát használja az átnevezésre. Mindenféle gusztustalan részletek itt, plusz még ezeken kívül a distro specifikus defaultok is változhatnak... Szóval fasza. :)
De korábban is az udev nevezgette át az interfészeket, csak akkor a stratégia az volt, hogyha egyszer meglátott egy eszközt, akkor eltárolta mint persistent rule, és ha kicserélted másikra, akkor az új ethX-ként jelent meg, amíg a korábbi rule-t nem törölted. Szerintem ez utóbbi jelenség van most Devuanon, de most nem tudom fejből és leellenőrizni sem.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Chain-Q te melyik verziót használod?
A stable 1-et?
Ráfrissítettem a ASCII-re, a régi kernel miatt. és a libpolkit-agent-1-0 policykit-1 vissza van tartva.
Kézzel kell mountolni pl
Not authorized to perform operation.
kösz
- A hozzászóláshoz be kell jelentkezni