Seren

Ez is VoIP alkalmazás, csak terminálban fut, ncurses felülete van. Kipróbáltam, igen jó hangja van, helyesebben szólva széles tartományban konfigurálható a bitráta, így eldönthetjük, hogy legyen-e szép hangunk, benne a nagyobb frekvenciás harmonikusokkal, vagy inkább kis sávszélességet egyen. Ha felépítettük a kapcsolatot, akkor tudunk chat-en üzenni, linket küldeni a partnereknek. Addig nem, mert pont-pont kapcsolatot valósít meg, nincs közbenső szerver, így azt sem tudná, a chat üzenetet milyen IP-címre küldje. Alapértelmezetten a 8110-es UDP porton várja a hívást meg a hangot, így a tűzfalon ezt kell beengedni, illetve NAT mögé forwardolni.

'/' jellel - aposztrófok nélkül - kezdődő chat sorok parancsnak minősülnek. A /h paranccsal kérhetünk helpet. Normál terminál méretben a help egy része felül kiszalad, célszerű lehet teljes képernyőn nézni, amíg meg nem tanultuk a használatát, ami egyébként végtelenül egyszerű. A leggyakrabban használt parancsok illetve funkcióbillentyűk:

F4            infók lekérdezése
F5            mikrofon némítás, engedélyezés
F7            hívás fogadás
F8            hívás elutasítás
/c host       hívás
/C            csengetés abbahagyása
/H            beszélgetés vége, kagyló lerakása
/q            kilépés

Skype helyett akár X nélküli gépre nagyon jó lehetőség. Jó, tudom, file-t küldeni nem tud, arra ott az scp, rsync, mc, ízlés szerint.

Írtam hozzá egy wrapper scriptet, ami dokkolja az értesítési területre, ezt nem itt a bevezetőben, hanem hozzászólásban teszem közzé. Kell hozzá alltray, wmctrl, libnotify vagy yad.

( locsemege v | 2014. 08. 12., k – 21:03 )

Az ígért wrapper script. A /usr/local/bin-be kell rakni, fontos, hogy seren legyen a neve!

#!/bin/bash

PRG='seren'
TITLE='Seren'
MESSAGE="A <b>$TITLE</b> már fut egy példányban!"
ICON='/usr/local/share/pixmaps/ihubig.png'
TIMEOUT=10
BITRATE=24000
ID_FILE="/tmp/$USER-seren.winid"

if [ -f "$ID_FILE" ] && read <"$ID_FILE"; then
    wmctrl -ia "$REPLY" && exit 0
    rm -f "$ID_FILE"
fi
if [ `pgrep -cu "$USER" -x "$PRG"` -gt 1 ]; then
    if type -p notify-send >/dev/null; then
        notify-send -t $((TIMEOUT*1000)) -i "$ICON" "$TITLE" "$MESSAGE"
    else
        yad --title="$TITLE" --timeout=$TIMEOUT --button 'OK:0' --text="$MESSAGE"
    fi
    exit 1
fi
alltray -i "$ICON" "xfce4-terminal -e \"/bin/bash -c 'PULSE_PROP=filter.want=echo-cancel /usr/bin/$PRG -S -b $BITRATE; rm -f $ID_FILE'\"" &>/dev/null &
while :; do
    WIN_ID="`wmctrl -l | grep 'Termin[aá]l (AllTray)'`"
    if [ ! -z "$WIN_ID" ]; then
        WIN_ID=`cut -d' ' -f1 <<<"$WIN_ID"`
        break
    fi
    sleep 0.5
done
echo "$WIN_ID" >"$ID_FILE"
wmctrl -ir $WIN_ID -N "$TITLE"
exit 0

A kódban vannak csúnya részek, de bizonyos információkhoz nem tudtam hozzájutni. Például még nem létező ablaknak nincs azonosítója. :) Ettől függetlenül nagyon jól használható. Baj akkor lehet, ha másik terminálos alkalmazást is dokkolni akarunk az alltray-jel.

Értelemszerűen a $ICON valami telefonnal kapcsolatos ikon file legyen. Visszhangelnyomásról a pulseaudio hangszerver gondoskodik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nincs vele gondom. Fedora 20-ban már az 5.0-s PulseAudio van. Most nélkülözhetetlen, ez a VoIP-os cucc is használhatatlan echo cancel nélkül. Kipróbáltam, simán összegerjed, ha visszahallja a mikrofon a hangszórót, visszajön a hang a másik gépre, annak hangszóróját hallja a mikrofonja... Viszont a pulseaudio visszhangelnyomásával teljesen jól használható kihangosítva.

A seren belül 48 kHz-et használ, ezért a pulseaudio-nak kell újramintavételezni - 44.1 kHz-es a hardware -, ezért is picit sok CPU-t eszik ilyenkor. Meg a visszhangelnyomáson is dolgozik. A seren meg azért eszik sokat, mert tömörít, titkosít, kititkosít, kitömörít. 3.2 GHz-es AMD Phenom II X4 CPU egy magjából 16 %-ot evett a pulseaudio, 14 %-ot a seren beszélgetés közben, ha jól emlékszem. A netet kb. 3.8 - 4.0 kB/s sávszélességre terhelte mindkét irányban 24000 b/s konfigurálása esetén.

Nem tudom, hogyan működik a kodek. Amikor 16 kb/s-ot konfiguráltam, 8 kHz audio sávszélességet vallott be. 32 kb/s és 24 kb/s konfigurálása esetén 20 kHz audio sávszélességet mondott. Maradtam a 24 kb/s-nál, mert igen kellemes hangot produkál gazdaságos hálózati sávszélesség kihasználás mellett.

Amúgy vicces, a kodek bitrátáját beszélgetés közben lehet módosítani, nem dobja el a kapcsolatot, szóval kényelmesen lehet vele kísérletezni. A vevő meg nyilván a csomag fejlécéből tudja, hogyan kell kibontani azt.

Miért csak Fedora 17-et használsz? Azóta világrengető bugokat találtak például az openssl-ben, a kernel is sokat fejlődött, a Firefox már a 31-es kiadásnál tart. Fedora 20-on nekem minden működik, amire szükségem van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Miért csak Fedora 17-et használsz?"

Jelenleg semmi bajom vele és amikor újat telepítek akkor napokig kell vacakolnom vele mire mindent beállítgatok úgy ahogy nekem jó. Erre még rájön az a pluszmunka amikor valami - egyébként jól működő dolgot - átbuherálnak és a megszokott módon nem lehet beállítani, lásd: http://hup.hu/node/134441#comment-1767820 Tehát nem sok kedvem van újra napokig tökölni egy minimális előny reményében. Előbb-utóbb persze sor kerül az új rendszer telepítésére, de egyelőre nem látok rá komoly okot.

"a Firefox már a 31-es kiadásnál tart"

Csak azért mert átvariálták a kinézetét, nem fogok ugrálni érte. A 22-es is jó arra amire kell.

(Jóval hamarabb elfáradok mint régebben, ezért nehezebb kibillenteni az energiával takarékoskodó állapotomból.)

Téged a nyilvánosságra került és kihasználható biztonsági rések nem zavarnak? A böngészőben nem a felület változása a fontos. Az openssl bugja meg ugye... Ezen felül funkcionális bugokat is javítanak, optimalizálnak dolgokat, stb.

A tiszta telepítés valóban nyűgös, sok beállítandó dolog van egy oprendszeren, amíg az az elvárásaink szerint működik. A /home tartalma természetesen külön filerendszer legyen, ekkor a személyes beállítások maradnak. De magát az oprendszert is lehet upgrade-elni egy, maximum két release távolságból. Nagyjából így lehet:

rpm --import https://fedoraproject.org/static/246110C1.txt
yum update yum
yum clean all
yum --releasever=20 distro-sync

Persze érdemes a doksit olvasni, attól el szabad térni, ha tudod, mit csinálsz. Ha gyors a neted meg a géped is elfogadható sebességű, egész barátságos idő alatt megvagy vele.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kipróbáltam a fentieket némi módosítással:

yum --releasever=19 distro-sync --skip

Még tegnap nyafogott pár rpm csomag miatt amit én készítettem és telepítettem. Ezeket levakartam és ma reggel elindítottam a fenti parancssort (runlevel 3, login:root és parancssor). Több mint egy órán át ömlöttek a kiírások a képernyőre a különféle függőségekről és zúgott a CPU ventillátora. Tegnap a kiírások előtt frissítette az adatbázisait, de ma már nem. Gondolom ezt abból a sebességből ahogyan futottak a sorok egymás után. Kizárt dolog hogy ilyen gyorsan tudott volna letölteni bármit is. Egyszercsak elegem lett a hosszú várakozásból és lepofoztam a yum-ot, mivel a jelek szerint teljesen meggárgyult. Jelenleg itt tartok. A fene egye meg.

Amit írtál nem feltétlenül hiba. A yum clean all paranccsal kitakarítottad a yum cache-t, metaadatokat? Az adott repóhoz a kulcs import megvolt? Az, hogy frissítette az adatbázist, ma már nem, normális, mert tegnap frissítette, ma meg már nem dobattad el vele yum clean all-al. A yum parancs a legfrissebb?

Milyen sorok futottak? Olyat szokott, hogy a függőségek feloldását kiírja, amikor ezzel elkészült, néhány ezer csomagnál jó sokat ír ki gyorsan. Csak ezután kérdezte volna meg, hogy ez OK, vagy sem, s ha 'y'-t nyomsz, elkezdi a letöltést, majd a frissítést.

Szerintem nem volt hiba, csak türelmetlen voltál. Azért párezer csomag függőségének feloldása idő, s közben nem ír progress bar-t. Esetleg másik konzolra belépve futtass egy top parancsot, úgy látod, mi viszi a futásidőt, az talán kicsit megnyugtat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

" A yum clean all paranccsal kitakarítottad a yum cache-t, metaadatokat?"

igen

"Az adott repóhoz a kulcs import megvolt?"

Az amit te írtál megfelelt az rpm-nek.

"A yum parancs a legfrissebb?"

A 17-hez nincs újabb.

"Milyen sorok futottak?"

A sebesség miatt nem sokat tudtam elolvasni de többnyire függőségekről regélt. Volt olyan hogy több oldalnyi üzenet kezdődött ugyanarra a lib-re való hivatkozással. Ezt úgy képzeld el hogy folyamatosan rohantak a sorok fölfelé egész idő alatt és csak az elején állt meg egy-két alkalommal molyolni valamivel a háttérben. Aztán amikor beindult, a hdd LED szinte nem is világított csak dőltek a sorok a képernyőre. Ez ment sokáig - legalább egy óráig - amíg meg nem untam. Nemrég újítottam fel a gépet és úgy vélem hogy egy ilyen CPU-nak nem kéne egy órán át tökölni a függőségek felismerésével: 


processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 19
model name	: AMD Athlon(tm) X4 760K Quad Core Processor
stepping	: 1
microcode	: 0x6001119
cpu MHz		: 3800.000
cache size	: 2048 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 16
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1
bogomips	: 7586.65
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

Ez persze csak az én elvárásom és a jelek szerint a világ nem eszerint működik még itt a szobámban sem. :-/

Szerintem nem jó file-t importáltál. Fedora 19 esetén ezt írja a könyv:

rpm --import https://fedoraproject.org/static/FB4B18E6.txt

Másrészt ezt találtam:

Incompatible systemd cgroups hierarchy layout
systemd in F19 lays out its cgroups hierarchy differently than in previous Fedora releases.

The new hierarchy has some advantages, but it is incompatible with the old one. No live conversion of the hierarchy is performed during the package upgrade, so the upgraded systemd will not understand the previous state of the system correctly. This is known to affect the tracking of user sessions by systemd-logind (bug #962983).
Expect breakage in active user sessions and make sure to reboot soon after performing the upgrade. If your screen locks during the upgrade, you may not be able to log back in due to the cgroup changes. Running the upgrade in a screen(1) session has been reported as a workaround (re-attach from a vt).

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kulcs valóban rossz, de ettől még nem kellett volna a yum-nak ilyen soká őrölni.

Tegnap próbáltam a frissítést a 18-ra is de akkor is kidobott a saját csomagjaim miatt. Ma már csak a 19-el próbálkoztam, gondolván ha lépésről lépésre csinálom - 17 => 18 => 19 => 20 - akkor ez annyi ideig fog tartani hogy a végére a Holdig fog érni a szakállam. A biztonság kedvéért töltöm lefelé a Fedora 20 telepítő DVD iso-t, a három órából még van 34 perc (512 kB/s). Ma már nem tökölök a frissítéssel/telepítéssel, mindenesetre az rpm-el megetettem mindhárom GPG-kulcsot (f18, f19, f20). Holnap reggel amikor tudom elindítom a frissítést az f18-al kezdve.

Csak, hogy átérezzem a problémáda, egy Fedora 21-re upgrade-et indítottam magamnál, amit persze nem fejeztem be. Az a helyzet, hogy szerintem talán 20 percet is elvolt a függőségekkel, miután azt mondta, 320 csomagot frissítene, talán 2100-at függőségi probléma miatt nem. Tegyük hozzá, Fedora 21 pre-alfa állapotban van, ezen felül a --skip-broken kapcsoló gondja, hogy jó, nem frissíti, amit nem lehet, de akkor amiatt mást sem lehet, és a függőségeken keresztül végül az oprendszer 85 %-át ignorálná. Ebből arra következtetek, hogy a --skip-broken ilyen sok csomag esetén rossz ötlet, lehetőleg manuálisan kell megoldani a függőségi problémát, s utána talán menni fog.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt azért nem kellett volna. :-) Csak azért kavarodtam bele az egészbe mert még soha nem csináltam ilyen jellegű rendszer frissítést és nem tudom hogy mi számít normális működésnek és mi az amikor valami már tényleg rossz. Különben is ennek nincs köze az eredeti témához, ezért köszönöm az eddigi türelmedet. Nem rongálom tovább az idegeidet.

( balagesz | 2014. 08. 12., k – 23:09 )

Erre én is írok egy "subscribe"-t. A skype-tól lassan égnek áll a hajam, minden lehetőség érdekel. :-D

Próbáld ki, nagyon kellemesen csalódtam benne. Ajánlom a wrapper scriptemet is, amellyel egész használható grafikus felületen, illetve megoldott a visszhangelnyomás. PulseAudio 5.0 leginkább, de a 4.0-ssal is megy szerintem.

Egyébként konferenciára van kitalálva. Egyedül annyi, hogy a partner IP-címét nem árt tudni, vagy dinamikus dns szolgáltatást jó igénybevenni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( mynheer_gabor | 2014. 08. 14., cs – 19:13 )

és kivel tudsz így beszélgetni?
_____________________________
Powered by 1,3,7-trimetilxantin

( dzsolt v | 2022. 05. 31., k – 08:26 )

Szerkesztve: 2022. 05. 31., k – 08:27

Tudom, hogy pár éves bejegyzés, de keresek valami ilyesmit épp...

Ez lefordul még nálad? Illetve használható még egyáltalán? (megakadtam vele, bár sok energiát nem áldoztam rá)

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Kár, hogy nem aktív a projekt, nincs a gentoo adattárban, hegeszthetek hozzá (is) ebuildet :). Keresgéltem, hátha van valami további, erre épülő projekt(ek), mondjuk androidra is vagy akár egy dyndns-szerű „telefonkönyv”. Mindegy, álmodozom. Egy teljesen független környezetet szeretnék ami mindenre jó egy nagyon kis közösség számára (gyakorlatilag család és baráti kör). A nextcloud-talk az esetek 95%-ban rendben volt, de a 2-3 nat (nincs ráhatásom arra hálózatra, csak van akinek ott kell dolgoznia és mert a hülye policy ott ezt követelte meg) mögé helyezett gépeken olykor elhasal. Van ilyen irányú tapasztalat ezzel? Lehet ezt valahogy simán a 80/443-as portra konfigurálni? Elég kevés találatot dob a kereső, gondolom nem nagy a felhasználói köre a seren-nek.

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Ha NAT, akkor tud STUN szervert használni, de ha tudsz portot nyitni, akkor közvetlenül, peer to peer mehet a beszélgetés minden egyéb nélkül. Nekem publikus IP-m van, ennélfogva tudok az OpenWrt/LEDE router-emen portot nyitni, meg persze a Fedora tűzfalán is. Meg a beszélgetőpartnernél szintén. Bármilyen porton képes kommunikálni, a portot a -p kapcsolóval lehet megadni, de talán config file-ból is képes azt felszedni. Default 8110. Ja, és UDP. Opus codec-kel tömörít, szép hangja van, emlékeim szerint a tömörítési rátát még beszélgetés közben is meg lehet változtatni. Nagyjából 3.5 - 4 kB/s sávszélességet igényel irányonként.

Volt, hogy néztem a forráskódját is, nem különösebben bonyolult, legalább is nem olyan, hogy ne lehetne megérteni. Mit meséljek még róla? Ma is használtam. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Épp egy forrás alapú disztribúció esetében nem lehet gond forrásból felrakni. Volt, hogy Fedorára is forrásból fordítottam, mert módosítottam a kódján. Aztán kiderült, a pulseaudio volt rossz. Pipewire óta szép az élet. :) Most az eredeti - helyesebben a fedorás - buildet használom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem is lesz szerintem, de majd a hétvégén. Ez egyelőre kísérlet lesz egy kollégával, ott lehet nyitni portot, nekem meg fixen kinn van a gépem a neten. A többit aztán meglátjuk, mert ugye egy voip alkalmazásnál nem nagyon lehet egyedül kommunikálni :D Köszönöm az infókat!

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt