- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Magyarázat:
A system init-rendszer alatt a PID1-es systemd-t és a hozzá fordítási idejű függőségként kapcsolt dolgokat értem (pl. journal).
A systemd-ernyőprojektbe minden más systemd-* kezdetűt értek (pl. hostnamed, localed, logind, timedated ...), amik gyakorlatilag sima service-k, választhatóak és nem függőségei a systemd-nek.
Probléma alatt bármit értek, ami a normális/elvárt működést akadályozza és tényleg a systemd hibája (nem simán pl. a disztró egyik package maintainere ütött el egy unit fájlt vagy vette fel rosszul a függőségeket).
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
szerkesszed man az opciokat, es tedd bele az alabbit is: kifejezetten utalom ezt a bloatfuckbugware-t.
Kivancsi vagyok, hogyan valtozik szavazatok eloszlasa...
- A hozzászóláshoz be kell jelentkezni
Ez a feature request asszem már treynek kell, hogy menjem, mert nem látok szerkesztés opciót. (ill. a lentebb leírtakat [elvi alapú utálás vs. valós személyes tapasztalatok] továbbra is tartom)
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
Nincs vs.
Személyes szívás és elvi utálat & rettegés egyaránt fennáll!
- A hozzászóláshoz be kell jelentkezni
Inkabb a windows, mint a systemd... Majd kinovi a linux ;)
- A hozzászóláshoz be kell jelentkezni
Euaz :D kanalat a soderhez is.
- A hozzászóláshoz be kell jelentkezni
+1
Mint megrogzott win kerulo is osztom a velemenyed :)
- A hozzászóláshoz be kell jelentkezni
Én nem tudtam egyikre sem szavazni, mert ugyan problémát még nem okozott, de nem tetszik ez a Kraken megközelítés, hogy mindent bekebelez.
- A hozzászóláshoz be kell jelentkezni
Ha nincs "szabványos" megoldás, amit a legtöbb disztró használ akkor az a baj, ha van, akkor meg az?
A legtöbb disztróban ahol ez az alapértelmezett, ott is van lehetőség másik használatára, így használhatod a kedvenc disztródat másikkal is.
- A hozzászóláshoz be kell jelentkezni
A problema inkabb az, hogy annyifele terjeszti a fuggosegeit a stackben le es folfele is, hogy terjed mint a pestis.
Pl. ha jol emlexem, akkor az uj gnome-ok mar systemd fuggoek. BSD-ken pl. kulon valamit hakolni kellett, hogy kepes legyen futni az uj gnome3.
Lehet, hogy rosszul emlexem, majd kijavit, akinek pontosabb az emlekezete.
- A hozzászóláshoz be kell jelentkezni
Ha jól emlékszem a logind-re kezdtek el dependelni (systemd ernyőprojektbe tartozó izé, a korábbi ConsoleKit-et hivatott leváltani) a multi-seat támogatás miatt, és végül arra jutottak, hogy "non-basic functionality" dependelhet a systemd komponensekre (https://mail.gnome.org/archives/release-team/2012-November/msg00015.html), alap funkcionalitás nem.
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 Ubuntu melyikbe esik?
- A hozzászóláshoz be kell jelentkezni
A kérdés nem erről szól, hanem hogy te hasznosnak találod-e a systemd -et. Ha azt sem tudod hogy mi van az Ubuntuban akkor szerintem ne válaszolj.
--
arch,debian,retropie,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
Tudom mi van benne.
Azt kérdeztem, melyik. (az utolsó 3 közül)
- A hozzászóláshoz be kell jelentkezni
Ha olyan release-t használsz, ami még nem systemds, akkor szvsz. leginkább "az általam használt disztró még nem tért át systemd-re, de nincs vele kifogásuk". Mivel a legnagyobb kifogásuk ellene kb. az volt, hogy nem az Upstart, de azóta át is vették. Ha közben distupgradeltél olyanra, ami már systemd-s, de nem tűnt fel a változás, akkor az első kettő közül valamelyik.
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
Jéééé, ebben van systemd? Észre se vettem.....
trey@alderaan:~$ pstree
systemd─┬─ModemManager─┬─{gdbus}
│ └─{gmain}
├─NetworkManager─┬─dhclient
│ ├─dnsmasq
│ ├─{gdbus}
│ ├─{gmain}
│ └─{pool}
├─accounts-daemon─┬─{gdbus}
│ └─{gmain}
├─acpid
├─agetty
├─atd
├─avahi-daemon───avahi-daemon
├─bluetoothd
├─colord─┬─{gdbus}
│ └─{gmain}
├─cron
├─cups-browsed─┬─{gdbus}
│ └─{gmain}
├─cupsd───dbus
├─dbus-daemon
├─fwupd─┬─3*[{GUsbEventThread}]
│ ├─{fwupd}
│ ├─{gdbus}
│ └─{gmain}
├─gnome-keyring-d─┬─{gdbus}
│ ├─{gmain}
│ └─{timer}
├─hddtemp
├─irqbalance
├─lightdm─┬─Xorg
│ ├─lightdm─┬─upstart─┬─at-spi-bus-laun─┬─dbus-daemon
│ │ │ │ ├─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─at-spi2-registr─┬─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─hud-service─┬─{QDBusConnection}
│ │ │ │ ├─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-appli─┬─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-bluet─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-datet─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ ├─{gmain}
│ │ │ │ ├─4*[{indicator-datet}]
│ │ │ │ └─{pool}
│ │ │ ├─indicator-keybo─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-messa─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-power─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-print─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-sessi─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─indicator-sound─┬─{dconf worker}
│ │ │ │ ├─{gdbus}
│ │ │ │ └─{gmain}
│ │ │ ├─sh───url-dispatcher─┬─{gdbus}
│ │ │ │ ├─{gmain}
│ │ │ │ └─3*[{url-dispatcher}]
│ │ │ ├─2*[sleep]
│ │ │ ├─2*[upstart-dbus-br]
│ │ │ ├─upstart-file-br
│ │ │ ├─upstart-udev-br
│ │ │ ├─window-stack-br───{QDBusConnection}
│ │ │ └─xbrlapi
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─{gdbus}
│ └─{gmain}
├─master─┬─pickup
│ └─qmgr
├─nmbd
├─packagekitd─┬─{gdbus}
│ └─{gmain}
├─polkitd─┬─{gdbus}
│ └─{gmain}
├─rsyslogd─┬─{in:imklog}
│ ├─{in:imuxsock}
│ └─{rs:main Q:Reg}
├─rtkit-daemon───2*[{rtkit-daemon}]
├─smartd
├─smbd─┬─cleanupd
│ ├─lpqd
│ ├─smbd
│ └─smbd-notifyd
├─snapd───10*[{snapd}]
├─systemd─┬─(sd-pam)
│ ├─GoogleTalkPlugi─┬─5*[{GoogleTalkPlugi}]
│ │ ├─{ProcessThread}
│ │ └─{Trace}
│ ├─bamfdaemon─┬─{gdbus}
│ │ ├─{gmain}
│ │ └─{pool}
│ ├─compiz─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ └─5*[{pool}]
│ ├─conky───8*[{conky}]
│ ├─dbus-daemon
│ ├─dconf-service─┬─{gdbus}
│ │ └─{gmain}
│ ├─evolution-addre─┬─evolution-addre─┬─{dconf worker}
│ │ │ ├─{evolution-addre}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─{dconf worker}
│ │ ├─{evolution-addre}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─evolution-calen─┬─evolution-calen─┬─{dconf worker}
│ │ │ ├─2*[{evolution-calen}]
│ │ │ ├─{gdbus}
│ │ │ ├─{gmain}
│ │ │ └─{pool}
│ │ ├─evolution-calen─┬─{dconf worker}
│ │ │ ├─{evolution-calen}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─{dconf worker}
│ │ ├─{evolution-calen}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─evolution-sourc─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─firefox─┬─plugin-containe─┬─{Chrome_ChildThr}
│ │ │ ├─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─plugin-containe─┬─{Chrome_ChildThr}
│ │ │ ├─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ ├─{gmain}
│ │ │ ├─9*[{plugin-containe}]
│ │ │ └─{threaded-ml}
│ │ ├─{Cache I/O}
│ │ ├─{Cache2 I/O}
│ │ ├─{Compositor}
│ │ ├─{DNS Res~er #472}
│ │ ├─{DNS Res~er #475}
│ │ ├─3*[{DOM Worker}]
│ │ ├─{DataStorage}
│ │ ├─{GMPThread}
│ │ ├─{Gecko_IOThread}
│ │ ├─{HTML5 Parser}
│ │ ├─{Hang Monitor}
│ │ ├─{IPDL Background}
│ │ ├─{ImageBridgeChil}
│ │ ├─{ImageIO}
│ │ ├─{ImgDecoder #1}
│ │ ├─{ImgDecoder #2}
│ │ ├─{ImgDecoder #3}
│ │ ├─8*[{JS Helper}]
│ │ ├─{JS Watchdog}
│ │ ├─{Link Monitor}
│ │ ├─{MediaPD~er #157}
│ │ ├─{MediaPD~er #158}
│ │ ├─{MediaPD~er #159}
│ │ ├─{MediaPD~er #160}
│ │ ├─5*[{MediaPl~ck #238}]
│ │ ├─{MediaPl~ck #239}
│ │ ├─{MediaPl~ck #240}
│ │ ├─{MediaPl~ck #241}
│ │ ├─{MediaTimer #56}
│ │ ├─{Proxy R~olution}
│ │ ├─{Socket Thread}
│ │ ├─{SoftwareVsyncTh}
│ │ ├─{Timer}
│ │ ├─{URL Classifier}
│ │ ├─{dconf worker}
│ │ ├─44*[{firefox}]
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ ├─{localStorage DB}
│ │ ├─{mozStorage #19}
│ │ ├─{mozStorage #1}
│ │ ├─{mozStorage #2}
│ │ ├─{mozStorage #3}
│ │ ├─{mozStorage #4}
│ │ ├─{mozStorage #5}
│ │ ├─{mozStorage #6}
│ │ ├─{mozStorage #7}
│ │ ├─{mozStorage #8}
│ │ └─2*[{threaded-ml}]
│ ├─firefox─┬─{Cache I/O}
│ │ ├─{Cache2 I/O}
│ │ ├─{Compositor}
│ │ ├─{DNS Res~er #262}
│ │ ├─{DNS Res~er #263}
│ │ ├─{DNS Res~er #264}
│ │ ├─3*[{DOM Worker}]
│ │ ├─{DataStorage}
│ │ ├─{GMPThread}
│ │ ├─{Gecko_IOThread}
│ │ ├─{HTML5 Parser}
│ │ ├─{Hang Monitor}
│ │ ├─{IPDL Background}
│ │ ├─{ImageBridgeChil}
│ │ ├─{ImageIO}
│ │ ├─{ImgDecoder #1}
│ │ ├─{ImgDecoder #2}
│ │ ├─{ImgDecoder #3}
│ │ ├─8*[{JS Helper}]
│ │ ├─{JS Watchdog}
│ │ ├─{Link Monitor}
│ │ ├─{Proxy R~olution}
│ │ ├─{Socket Thread}
│ │ ├─{SoftwareVsyncTh}
│ │ ├─{Timer}
│ │ ├─{URL Classifier}
│ │ ├─{dconf worker}
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ ├─{localStorage DB}
│ │ ├─{mozStorage #1}
│ │ ├─{mozStorage #2}
│ │ ├─{mozStorage #3}
│ │ ├─{mozStorage #4}
│ │ ├─{mozStorage #5}
│ │ ├─{mozStorage #6}
│ │ ├─{mozStorage #7}
│ │ └─{threaded-ml}
│ ├─gconfd-2
│ ├─gnome-session-b─┬─deja-dup-monito─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─gnome-encfs-man─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─gnome-software─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─nautilus─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ ├─{gmain}
│ │ │ └─4*[{pool}]
│ │ ├─nm-applet─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ ├─{gmain}
│ │ │ └─{pool}
│ │ ├─polkit-gnome-au─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─telepathy-indic─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─unity-fallback-─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─update-notifier─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─zeitgeist-datah─┬─{gdbus}
│ │ │ ├─{gmain}
│ │ │ └─4*[{pool}]
│ │ ├─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─gnome-terminal-─┬─bash───pstree
│ │ ├─{dconf worker}
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ └─{pool}
│ ├─gpg-agent
│ ├─gvfs-afc-volume─┬─{gdbus}
│ │ ├─{gmain}
│ │ └─{gvfs-afc-volume}
│ ├─gvfs-goa-volume─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfs-gphoto2-vo─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfs-mtp-volume─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfs-udisks2-vo─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd-burn─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd-dnssd─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd-fuse─┬─{gdbus}
│ │ ├─{gmain}
│ │ ├─{gvfs-fuse-sub}
│ │ └─2*[{gvfsd-fuse}]
│ ├─gvfsd-http─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd-metadata─┬─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd-network─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd-smb-brows─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─gvfsd-trash─┬─{gdbus}
│ │ └─{gmain}
│ ├─ibus-daemon─┬─ibus-dconf─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─ibus-engine-sim─┬─{gdbus}
│ │ │ └─{gmain}
│ │ ├─ibus-ui-gtk3─┬─{dconf worker}
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ └─{pool}
│ ├─ibus-x11─┬─{gdbus}
│ │ └─{gmain}
│ ├─mission-control─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─notify-osd─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─pulseaudio─┬─{alsa-sink-CX207}
│ │ ├─{alsa-sink-HDMI }
│ │ └─{alsa-source-CX2}
│ ├─sh───zeitgeist-daemo─┬─{gdbus}
│ │ └─{gmain}
│ ├─thunderbird─┬─{Cache I/O}
│ │ ├─{Cache2 I/O}
│ │ ├─{Cert Verify}
│ │ ├─{Closing Service}
│ │ ├─{Compositor}
│ │ ├─{DNS Resolver #1}
│ │ ├─{DNS Resolver #2}
│ │ ├─2*[{DOM Worker}]
│ │ ├─{Gecko_IOThread}
│ │ ├─{HTML5 Parser}
│ │ ├─{Hang Monitor}
│ │ ├─{IPDL Background}
│ │ ├─{ImageBridgeChil}
│ │ ├─{ImageIO}
│ │ ├─{ImgDecoder #1}
│ │ ├─{ImgDecoder #2}
│ │ ├─{ImgDecoder #3}
│ │ ├─8*[{JS Helper}]
│ │ ├─{JS Watchdog}
│ │ ├─{Link Monitor}
│ │ ├─{Proxy R~olution}
│ │ ├─{SSL Cert #982}
│ │ ├─{Socket Thread}
│ │ ├─{SoftwareVsyncTh}
│ │ ├─{Timer}
│ │ ├─{URL Classifier}
│ │ ├─{dconf worker}
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ ├─{mozStorage #1}
│ │ ├─{mozStorage #2}
│ │ ├─{mozStorage #3}
│ │ ├─{mozStorage #4}
│ │ ├─{mozStorage #5}
│ │ ├─{mozStorage #6}
│ │ ├─{threaded-ml}
│ │ └─{thunderbird}
│ ├─unity-files-dae─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ └─4*[{pool}]
│ ├─unity-panel-ser─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─unity-scope-hom─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─unity-scope-loa─┬─{dconf worker}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─unity-settings-─┬─syndaemon
│ │ ├─{dconf worker}
│ │ ├─{gdbus}
│ │ ├─{gmain}
│ │ └─{threaded-ml}
│ └─zeitgeist-fts─┬─{gdbus}
│ └─{gmain}
├─systemd-journal
├─systemd-logind
├─systemd-resolve
├─systemd-timesyn───{sd-resolve}
├─systemd-udevd
├─thermald───{thermald}
├─udisksd─┬─{cleanup}
│ ├─{gdbus}
│ ├─{gmain}
│ └─{probing-thread}
├─unity-greeter-s─┬─{gdbus}
│ └─{gmain}
├─upowerd─┬─{gdbus}
│ └─{gmain}
├─vmnet-bridge
├─2*[vmnet-dhcpd]
├─vmnet-natd
├─2*[vmnet-netifup]
├─vmware-authdlau
├─vmware-hostd─┬─2*[{hostd-IO}]
│ ├─{hostd-fair}
│ ├─{hostd-poll}
│ └─12*[{hostd-worker}]
├─vmware-vmblock-───2*[{vmware-vmblock-}]
└─wpa_supplicant--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ha jol latom upstart is?
--
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
pastebin, vagy kiszámlázom a területfoglalási díjat a monitoromon ;P
- A hozzászóláshoz be kell jelentkezni
alderaan? omg, annak nem lesz jó vége lol...
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
Új lehetsz errefelé... :D
- A hozzászóláshoz be kell jelentkezni
Tehát azt kérdezed hogy az Ubuntu systemd-es vagy sem? :)
--
arch,debian,retropie,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
hibát nem okozott, csak meglepetést, amikor valami szolgáltatást le akartam állítani, és a korábbi módon nem ment.
- A hozzászóláshoz be kell jelentkezni
Gentoo linuxon nálam az openrc a default, de lehetne systemd is. Egyáltalán semmi okát nem látom amiért érdemes lenne áttérni rá.
- A hozzászóláshoz be kell jelentkezni
+1
+= Ha a Gentoo úgy gondolja hogy ez legyen a default akkor áttérek.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
A systemd.timer-t előszeretettel használom, többek között emiatt lett a 7. lehetőség.
- A hozzászóláshoz be kell jelentkezni
+1 a timer-t pont tegnap hasznaltam eloszor, meglepoen egyszeru volt. Bar cron-nal meg csak java-bol dolgoztam es mas tapasztalatom nincs utemezokkel desktopon.
- A hozzászóláshoz be kell jelentkezni
csak a tapasztalataimat tudom leirni, hogy ez bug vagy feature azt nem tudom.
deb8 alatt ezt kaptam:
rsync:
nem hasznalta az /etc/default/rsync:RSYNC_OPTS-t, workaroundkent bele kell irni a /lib/systemd/system/rsync.service:ExecStart-ba
openvpn:
nem mukodik az "/etc/init.d/openvpn start ovpnconf", ahol az ovpnconf az /etc/openvpn/*.conf kozul barmelyik lehet, igy barmelyik ovpn-t el tudtam inditani.
ehelyett modositani kell az /etc/default/openvpn:AUTOSTART-ot, - pedig nem akarom hogy automatikusan elinduljon, a jelszo miatt nem is tud - majd ujrainditani az openvpn-t. ha rendszerinditaskor AUTOSTART=”none” volt, akkor semmit nem csinal (systemctl daemon-reload utan sem), de workaroundkent ha ujrainditom a gepet akkor megtalalja az ovpnconfot.
openvpn inditasakor regebben bekerte a jelszot, most az osszes terminalba beleirja hogy a systemd-tty-ask-password-agent-el tudom beirni a jelszot.
illetve ha valaki ert hozza, be lehet-e allitani olyat, hogy ha egy service leall automatikusan ujrainditsa? akkor nem kellene mindenhez watchdog scripteket irnom, ezt fel tudnam irni a merleg pozitiv oldalara.
koszi!
--
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
workaroundkent bele kell irni a /lib/systemd/system/rsync.service:ExecStart-ba
Ne, azt a kövi rsync frissítés gondolkodás nélkül felül fogja csapni. Terjeszd ki a konfigot (pl. /etc/systemd/system/rsync.service.d/read-defaults.conf néven hozz létre egy fájlt, amiben csak azt módosítasz, amit szeretnél [esetedben egy EnvironmentFile direktívára lesz szükség szvsz - ha csak statikus dolgok vannak a /etc/default/rsync-ben])).
nem mukodik az "/etc/init.d/openvpn start ovpnconf", ahol az ovpnconf az /etc/openvpn/*.conf kozul barmelyik lehet, igy barmelyik ovpn-t el tudtam inditani.
Erre vannak a paraméterezhető service-ek:
Optionally, units may be instantiated from a template file at runtime. This allows creation of multiple units from a single configuration file. If systemd looks for a unit configuration file, it will first search for the literal unit name in the file system. If that yields no success and the unit name contains an "@" character, systemd will look for a unit template that shares the same name but with the instance string (i.e. the part between the "@" character and the suffix) removed. Example: if a service getty@tty3.service is requested and no file by that name is found, systemd will look for getty@.service and instantiate a service from that configuration file if it is found.
(https://www.freedesktop.org/software/systemd/man/systemd.unit.html#)
be lehet-e allitani olyat, hogy ha egy service leall automatikusan ujrainditsa?
Nézd meg a Restart= direktíva leírását (https://www.freedesktop.org/software/systemd/man/systemd.service.html#B…) neked spec az Always kell. A fentivel (unit extension) ez így összesen két sorral megoldható, bármilyen service-re.
Az ask-password őszintén passz, még soha nem találkoztam vele, nem használok semmit, aminek induláskor jelszó kéne,
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
koszonom a segitseget, majd kiprobalom
--
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
kezdem egyre jobban ertekelni (CoreOS alatt hasznaltam)
ami sztem nagyon meno feature, ami az egesz systemdt jo projektte teszi, h nem kell tobbe rendszer-specifikus initscriptekkel bohockodni
- A hozzászóláshoz be kell jelentkezni
nem kell tobbe rendszer-specifikus initscriptekkel bohockodni
??? Mert ha a systemd nincs ott mindenhol (esetleg egy adott linux disztroval dolgozol), akkor bukta. Ha meg 1 adott, gondolom, jol kitesztelt linux disztro van nalatok, akkor eleve nem is volt szo "rendszer-specifikus" problemakrol...
- A hozzászóláshoz be kell jelentkezni
Nézd meg egy Samba forrását:
- packaging/systemd/{samba,smb,winbind,nmb}.service - ezzel minden systemd-t használó disztrót letudtak a fejlesztők (ill. egy samba.conf.tmp [a tmpfiles.d-nek, hogy legyen /var/run/samba] és egy samba.sysconfig, amire hivatkozik a samba.service)
- packaging/LSB/samba.sh - jól hangzik, hogy minden LSB-kompatibilis disztrót letudnak vele, de:
- packaging/sysv/samba.init - eléggé minimál
Ebből mi lesz a disztrókban:
A CentOS 6-os csomagban két init script van, egyik sem a fenti kettő.
A Debian 7-es csomagban két init script (smbd, nmbd) van, egyik sem a fenti kettő.
A Debian 8-as csomagban négy init script (smbd, nmbd, samba-ad-dc és samba [ami előző hármat indítja])
...
A CentOS 7 és OpenSUSE Leap csomagban két systemd unit fájl van - az smb.service-ben módosítottak annyit, hogy a kerberos ccache env. változót beállítják.
OpenSUSE 13.1-es csomagban két systemd unit fájl van - egy az egyben a Sambahoz csomagolt.
A Debian-t leszámítva (ami már systemd-s ugyan, de még init scriptekkel szórakoznak) mindenkinél egyszerűsödött az élet...
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
Na erről van szó!
Nem mellesleg felesleges init-script írást és tesztelést kerül el vele a disztribútor.
- A hozzászóláshoz be kell jelentkezni
1) Az egyseges runtime-nak van egy ilyen furcsa szokasa, hogy csak akkor mukodnek a ra irt szolgaltatasok, ha van runtime. Nahat.
2) Kimaradt az az eset, amikor nem 1, hanem tobb disztro van, marpedig az indito pontosan errol beszelt, csak neked veletlenul sikerult pont az ellenkezojerol beszelni.
- A hozzászóláshoz be kell jelentkezni
+1
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
- A hozzászóláshoz be kell jelentkezni
+1
Meg valami. A vinit mit csinal ha leall egy process? Semmit. A systemd ujrainditja. A ketto kozt van kulonbseg.
Gyoker a szavazas.
- A hozzászóláshoz be kell jelentkezni
A systemd ujrainditja.
Ha erre expliciten megkéred (Restart= on-failure, always, ...). Ha nem adsz meg Restart direktívát és a defaultot használod, akkor Restart=no, és magától nem indítja újra.
Azaz de, előfordulhat, hogy újraindítja. Ha pl. egy timer elindítja. Vagy egy socket elindítja. Vagy a D-Bus-on keresi valami azt a szolgáltatást.
--
Szerk.: ja, leesett, hogy ezt te mint pozitívumot emelted ki és nem a "dehátazengedélyemnélkülújraindítgatjavégtelenciklusban" komment volt :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ért próbáld meg egyszer összehasonlítani egy rendes watchdoggal, mondjuk monit-tal és rájössz, hogy mennyire keveset ér ez a Restart=always feature. Ahhoz, hogy egy watchdog ne okozzon több kárt, mint amennyit használ, elég jól kell tudni finomhangolni és a systemd kemény két paraméterezési lehetősége (StartLimitIntervalSec=, StartLimitBurst=) itt finoman szólva nem kielégítő.
Nem feltétlen csak akkor kellhet restartolni, ha a process leállt, viszont amit erre kitaláltak, systemd-notify-os heartbeat megoldást... hát nem is tudom, hogy egyáltalán bármi pozitív elmondható-e róla (mióta is használhatatlanul bugos? Úgy 2008-óta?). Persze lehet workaroundolni, de ennek pont az lesz a vége, hogy custom shell scriptekkel kell indítanod a service-t, visszatérünk ugyanoda, ahonnan a systemd előtt kiindultunk.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
man inittab /respawn
Oszt akkor utána oszd az észt. Simán lehet SysV inittel újraindíttatós módon futtatni valamit. Ja, hogy nem úgy szokták a getty-n kívül. Az nem az init hibája.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
Van azért ennél sokkal fejlettebb megoldás ami nincs ennyire agyonbonyolítva.Lásd:System Resource Controller. Mellette akár több alternatív módszer használata is lehetséges. Sőt, van olyan Method, amely rc-k helyett adatbázisból végzi az egyes rendszerkomponensek konfigurálását. (Tiszta Windows! ;)) Pl. cfginet.
Szóval csak annyi kellett volna, hogy a systemd alkotója valami jól működő példát megnézzen. Helyette bizonyára szidta az elavult vacakot, majd az egyik kezét a seggébe dugta a másikkal meg írta a systemd-t.
Elnézést az argóért, de mifelénk ezt így mondják. ;)
- A hozzászóláshoz be kell jelentkezni
Jobbara egyetertek, csak en pozitiv peldakent az SMF-et hoztam volna fel. AIX-et kevesbe ismerem.
De minden masban kb. pont ugyanaz a velemenyunk.
Kiveve, hogy ezt az argo-t, amit szepen beleszottel a megfogalmazasba, meg nem ismertem.
Ma is tanultam valamit! :)
Egyebkent nota benne: Ez a systemd-szerzo lenart pottering, ugyanaz az ember, aki a pulseaudio-t is elkovette. Es biztosan van meg mas is a bunlajstroman! ;-)
- A hozzászóláshoz be kell jelentkezni
boot-olás közben ilyet látni hogy:
starting networkmanager
stopping netvorkmanager
starting netvorkmanager
stopping networkmanager
...
starting networkmanager
stopping netvorkmanager
starting netvorkmanager
stopping networkmanager
starting networkmanager
Nem tűnik valami átgondolt rendszernek. Más szolgáltatással is többszörösen megteszi ezt az indít-leállít ciklust.
Felhasználói szinten nem érezni különbséget a hagyományos init és a systemd között.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
- A hozzászóláshoz be kell jelentkezni
Nem láttam olyan választási lehetőséget, ami ellenérzést fejezne ki vele kapcsolatban.
Kicsit elfogultnak tűnik a szavazás.
Nagyjából az elborult ennél szarabb architektúrát szándékosan se lehetne tervezni kategóriának találom.
Nade ha már a Linux desktop éve nem jött össze soha, ez egy jó esély lehet arra, hogy a FreeBSD desktop éve eljöjjön.
Még a végén elmozdítja az embereket a linuxról! :)
Bantuból pont kezdett kicsit elegem lenni. Aztán a laptopomra nemrégiben Debiant raktam. 8. Systemd.
Avval, és ott, és ilyen rövid idő alatt még véges mennyiségű problémába sikerült csak belefussak.
Network management elborultabb lett + a 12.04-es bantun stabilabb volt a hibernate mint debian 8-on... A végén most az b..ta fel az agyam, hogy debianra a gyári repókban nem találni egy kib...t avidemuxot mindenféle jogászkodás miatt, de legalább gyors google kereséssel lehet találni egy mail thredet ahol még a Debianon belül is azt az egy embert csesztetik a repója miatt, aki csinált unoff repót + oda mert tenni valami paypal vagy akármi linket, és hogy nevezze át debian-multimedia.org -ról a domain-jét ezt meg legyen szíves bedobni a közösbe és senkinek semmi se jó... Szóval kb. olyan színvonalú észosztás ment, mint mikor fb-on olvasni szittyamagyarkodókat...
Aztán egy virtualboxba kipróbáltam a FreeBSD11.0-Release-t.
Volt FreeBSD-vel pár rossz emlékeket hagyó próbálkozásom még 2002-3-4 környékén. Nem lett a kedvencem.
Most egész gyorsan volt egy használható mátés desktop rendszerem vboxban.
Egyelőre nem akarom teljesen eldobni a debian-t.
De ha kicsit kitanulom a bsd bootmanagerét, meg trükkjeit, hogy hogy békítsem össze a laptop gyári windowsával, (amire sajnos a telefonom b..kurálása miatt egyelőre még szükségem van), és a mellette meglévő debiannal,
akkor elég jó eséllyel a laptopomon az elsődleges rendszer FreeBSD-re fog változni.
Némi OpenIndian meg OmniOS után nem is olyan rossz a freebsd. (Tulzásokba ne essünk, azért az illumos kernel még mindig jobban tetszik!)
De az egy nájsz feature hogy már a telepítő egy geli-vel encryptre tudja tenni a rpool-t!
Eddig pont a zfs encrypt hiánya miatt óvakodtam illumos based rendszerre váltani a laptopon.
A freebsd szépen megoldotta unix filozófiásan!
Mr. Potteringnek meg már remélem készítik az extra bugyrot a pokolban a többi kártevő mellé.
- A hozzászóláshoz be kell jelentkezni
Kicsit elfogultnak tűnik a szavazás.
Azért ahhoz képest, hogy elfogult a kiírás, a negítv:semleges:pozitív arány egyelőre 56, 51, 37. ;)
Az meg, hogy "utálom/szeretem" egy másik kérdés, nem ok nélkül kérdeztem, hogy okozott-e problémát vagy hogy használjátok-e a feature-jeit. Ugyanis divat szidni a systemd-t elvi alapokon, de amint rákérdezel pl. a "mekkora bloat szar a PID1-ben, ha összeomlik, viszi a rendszert" szálon, hogy "és nálad mikor omlott össze a PID1?", csend szokott lenni...
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
mondjuk, hogy az egyes ponthoz írjak, pont ma reggel volt egy olyan, hogy beragadt az otthoni nas kézzel felhúzott temp mountja, emiatt valami homokórázott, az umount meg aszonta, hogy debizony ez busy, én meg gondoltam, hogy ezt most keresgéli a fene, restart, úgyis volt új kernel, és leáálásnál hosszasan homokóráztunk arra, hogy majd umountoja, és oda volt írva, hogy ezt ő bármeddig hajlandó lesz próbálni, úgyhogy volt egy "köcsögsystemd" :)
(és egyékbént az egyik pozitívra szavaztam)
- A hozzászóláshoz be kell jelentkezni
Ideiglenes mountnál nem sokat ér (szvsz. senki nem áll neki override-olni/újramountolni), de a mount pontokra ott van a LazyUnmount (umount -l) / ForceUnmount (umount -f) direktíva.
A másik része meg, hogy az se lenne szerencsésebb megoldás, ha nem foglalkozna egy-egy nem lecsatolható FS-sel...
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 másik része meg, hogy az se lenne szerencsésebb megoldás, ha nem foglalkozna egy-egy nem lecsatolható FS-sel..."
Na jah, csak a while (!success) {..} nem retry-logika.
- A hozzászóláshoz be kell jelentkezni
/* retry umount, until nothing can be umounted anymore */
do {
umount_changed = false;
mount_points_list_umount(&mp_list_head, &umount_changed, false);
if (umount_changed)
*changed = true;
} while (umount_changed); (https://github.com/systemd/systemd/blob/4a5567d5d6ab01974dd089eb8907fec…)
Majdnem... (umount_changed-et a mount_points_list_umount változtatja, ha a umount2 hívással a kerneltől bármelyik mount point-ra nullát kap.
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
Tudom, hogy ezek ki vannak vezetve, de mint mondtad, ideiglenes mount pointnál, amit nem is a systemd mountolt fel, nem lettem előrébb, és az sem segített, hogy valami ennél sokkal direktebb dolognál valószínű ki tudtam volna belőle cltr+c-zni, itt rövid nyomkodás után IJ volt.
Az imho szuboptimális, hogy úgy foglalkozik egy nem lecsatolható mounttal, hogy végtelen ciklusba ül vele, pláne nem, ha láthatólag képes másként is viselkedni. És persze a főbűnös természetesen az nfs, ami ebbe a csoda állapotba kerül, ha az ember nem jár előtte esőtáncot.
- A hozzászóláshoz be kell jelentkezni
"Azért ahhoz képest, hogy elfogult a kiírás, a negítv:semleges:pozitív arány egyelőre 56, 51, 37. ;)"
Igazan negativ valasztasi lehetoseget nem is tettel oda, az "okozott mar problemat" az nem a "hasznosnak tartom" ellentete (azaz ha az egyik iranyban nem elfogultsagot akarsz hallani, akkor a masik iranyban se kene).
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ennyi erővel a Gentoo Linuxot is kipróbálhatod.
- A hozzászóláshoz be kell jelentkezni
1 kerdesem a systemd kapcsan: megis miert kellett ezt?
- A hozzászóláshoz be kell jelentkezni
Hiányzik a listából, hogy az init-rendszer folyamatosan problémát okoz...
- A hozzászóláshoz be kell jelentkezni
SLES12SPx
- VMWare VM-ből klónozott gép. Igénynek megfelelően átméretezendő a swap disk, mert a template-ben csak 1GB. yast disk... hajra.
- klónozás után nem generáltál új machine-id-t? Hát akkor nincs SuSEManager reg. - jó, ez nem systemd, de vele kell újracsináltatni...
--
A gyors gondolat többet ér, mint a gyors mozdulat.
- A hozzászóláshoz be kell jelentkezni
Ez van. Letojom mi van a distroban, amit beletesznek azt tanulom meg es hasznalom.
- A hozzászóláshoz be kell jelentkezni
(sub)
- A hozzászóláshoz be kell jelentkezni
- ha nincs /etc/init.d/* (pl. centos 7), nagyon gaz, hogy nem lehet a tab-ot hasznalni. Tudnom kell a service pontos nevet, pl. tobb vpn interfacenel
- ha van, kepes total osszeszarni magat, rendszer nem bootol (tavaly nyaron a debian testing, a "networking" nem idnult, nem timeoutolt, talan meg a Magic SysRQ sem mukodott, csak az on/off gomb, most is ugy van, hogyy az eredeti networking "exit 0"-val kiszall es egy masik file, boot utan rc.local-bol inditja a networkinget. Ismert debian bug, nyilvan nem mindenkinel jon elo, nalam igen.
Szoval ruhellem, nekem teljesen jo volt a sysvinit.
--
http://www.micros~1
Rekurzió: lásd rekurzió.
- A hozzászóláshoz be kell jelentkezni
Tudnom kell a service pontos nevet, pl. tobb vpn interfacenel
https://raw.githubusercontent.com/RoadRunnr/systemd/master/shell-comple…
/etc/init.d/*-nál is illik tudnod, mert a service wrapperen keresztül illik jóideje indítani mindent.
A network-ös rész passz, több hálózatkezelővel és anélkül is használom a systemd-t, de boot-képtelen még nem lett egyiktől sem.
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
- Lehet, hogy ugy illik, de ha nekem egyszerubb volt az /etc/init.d/ alol
- Ez biztos volt, meg azota nem tudom, mennyi, de erre anno fel voltam iratkozva. Nalam sztem azota sem mukodik, de egyreszt parhavonta inditom ujra a gepemet, masrezst ninc skedvem tesztelgetni, hogy vegre megy-e vagy nem (ha nem megy, livecd, kiiktatni a networking scriptet, ujra bootolni, stb)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218
--
http://www.micros~1
Rekurzió: lásd rekurzió.
- A hozzászóláshoz be kell jelentkezni
/etc/init.d vs. service-re (idézet a service man page-éből)
service runs a System V init script in as predictable environment as possible, removing most environment variables and with current working directory set to /.
(a linkelt bug reportban meg megtalálták a teljesen jogos deadlock-ot, az csak a SysV-initet minősíti, hogy nem foglalkozott a definiált függőségekkel; egyébként meg natív systemd service-kkel ehhez nem kellenek mindenféle hook scriptek)
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
Én szeretem a systemd-t. És pár év után a pulseaudio is tök jó lett. Jöhetnek a kövek :-).
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1 en is szeretem, legalabbis amiit a centos 7-en hasznalok belole.
A pulseaudiot nem hasznalom, de mas hasonlot sem.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Eleinte én is utáltam őket mert divat volt utálni mindent ami Pottering keze alól jött ki.
Még a pulseaudio-t is képes voltam levájni merthogy az mindenki szerint ganéj. Aztán amikor megláttam milyen nélküle akkor sürgősen visszatelepitettem.
Miután ráerőltettem magam, hogy előző befolyások nélkül, simán az én életemre levő hatása alapján itéljem megszerettem. Gond nincs vele, a boot viszont sokkal gyorsabb lett, én ennyit látok belőle.
--
:wq
- A hozzászóláshoz be kell jelentkezni
Pulseaudio egesz addig jo, ameddig zenet nem akarsz a gepeden munka kozben hallgatni.
Tudom, ha komolyan gondolom, akkor be lehet kapcsolni melle a regi analog LP lemezjatszot, es hadd szoljon.
De mondjuk egy normalis sacd.iso meghallgatasa, vagy egy 96, neadjisten 192kHz-s flac meghallgatasahoz ne kelljen mar tobb melot a zenehallgatasba beleolnom, mint egy komplett rendszer nullarol feltelepitesebe es finomhangolasaba (excluding az audio resz beallitasa).
Es meg ha a fejed tetejere allsz, se fogsz tudni normalis megoldast adni a problemara systemd-vel, mert by-design egy rakas tragya!
Utalok windows-t hasznalni, DE
az picit visszas erzes, hogy minimalis alatti windows eloismerettel egy windowst kepes vagyok normalis zenehallgatasra bekonfiguralni kevesebb ido alatt, mint a pulseaudiot rendesen ( / vagy legalabb temporalisan) kiirtani ( / kiiktatni ) egy ubuntubol.
- A hozzászóláshoz be kell jelentkezni
> De mondjuk egy normalis sacd.iso meghallgatasa, vagy egy 96, neadjisten 192kHz-s flac meghallgatasahoz ne kelljen mar tobb melot a zenehallgatasba beleolnom, mint egy komplett rendszer nullarol feltelepitesebe es finomhangolasaba (excluding az audio resz beallitasa).
Letöltöttem egy 96khz-es flac-ot, rádupláztam és az alapértelmezett Clementine-om lejátsza, pulseaudio-n kresztül, Ubuntu 16.04-en. Minden default beállításon van. Én (nem) rontottam el valamit?
- A hozzászóláshoz be kell jelentkezni
Gyanitom: Igen.
Mit ir ki az erositod, milyen felbontasu hangot kap?
Nekem spec. azt irta, hogy a pulse lebutitotta 48khz-re.
(Na jo, azt nem irta, hogy ki a bunos, azt mar nekem kellett kinyomozzam.)
De ha nalad minden flottul mukodik, akkor az jo.
De felek tole, siman elsiklottal efolott az aprosag folott, es fel sem tunt!
Az, hogy kijon valami a gepbol, meg hogy az jon ki belole, aminek kell, az ket kulonbozo dolog is lehet! ;-)
- A hozzászóláshoz be kell jelentkezni
Azt hiszem félreértettelek, azt hittem egyáltalán nem játssza.
Ezeket a beállításokat kipróbáltam.
Sajnos nincs erősítőre dugva és nem tudom így megnézni, hogy mi megy ténylegesen ki, de lekérdezéskor azt írja ki, hogy 96khz a sample.
> pacmd list-sinks | grep sample
sample spec: s32le 2ch 96000Hz
sample spec: s32le 2ch 96000Hz
- A hozzászóláshoz be kell jelentkezni
Erre az a divatos frappáns válasz, hogy a hosszú évek alatt a gépek "hozzáerősödtek" a pulseaudio futtatásához. :)
Annyi igazság biztosan van benne, hogy egy AthlonXP-s gépnek pulseaudioval komoly problémát okozott a folyamatos kihagyásmentes felvétel. Pedig nem akartam én tőle semmi úri huncutságot, mint mondjuk 44kHz 16 bit stereo (amit már win3.1 alatt 486-oson SB16-tal is tudtam felvenni), mindössze beszédhangra kellett volna 22kHz 16bit mono. Végül egy Core2duo már elég erősnek bizonyult hozzá...
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Akkor valamiért nekiállhatott szoftveresen újramintavenni (ugye automatikusan egyeztetnie kell a klienstől kért a formátumot a forrásformátummal) - lehet, hogy 48kHz 16bit-tel (passz, amit a kártya alapból kiad - ill. ahogy a rögzítő szoftver visszajátsza, ha csinál ilyet) jobban jártál volna.
De ez már eléggé a partszélről bekiabálás, a PA nálam többnyire működik és nagyon régen szórakoztam azzal, hogy perverz konfigokat tettem össze :)
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
Mondjuk ha jól rémlik (csak a partvonalról figyeltem) akkor az elején azért az volt, hogy neki állt szoftveresen mintavenni, mert ennyit tudott, és slussz. És mondjuk azért azt értem, hogy egy normálisabb kártya tulajdonosát ez zavarta :)
- A hozzászóláshoz be kell jelentkezni
Nem hiszem, hogy az volt a baj vele, de ez már elég régi sztori. Úgy emlékszem azt már kínomban próbáltam, hogy 44 vagy 48 kHz-ről visszavettem 22kHz sőt talán még lejjebb is. Inkább valami ütemezési probléma lehetett, nem folyamatosan droppolt, csak néha-néha de akkor burstösen egymás után sokat.
A pulseaudio letiltásával hirtelen megjavult. Aztán valahogy úgy hozta a sors, hogy a gép fel lett upgrade-elve core2-re. Akkor a 64 bit miatt újrahúztam, és ott már nem kellett letiltani a pulseaudio-t, hogy képes legyen folyamatosan felvenni. Az se kizárt, hogy az egy helyett két magra váltásnak volt köze hozzá, a jelenség alapján legalábbis a realtime ütemezés támogatása körül volt valami diszfunkció.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ha valakinek a boot folyamata túl lassúnak tűnik, akkor a
systemd-analyze critical-chain
utasítás nagyon szépen megmutatja az idő-kritikus service indulási láncot.
A többi paramétere is hasznos lehet, pl.: blame, time, plot
- A hozzászóláshoz be kell jelentkezni