Skype for Linux 4.2

Címkék

Megjelent a Skype for Linux 4.2-es kiadása. Benne néhány új funkció mellett egy rakás hibajavítás található. Részletek a bejelentésben.

Hozzászólások

Vegre lesz uj olvasnivalojuk Redmondban.

Remelhetoleg a kovetkezo verzioknal ha szukseg lesz ra, beszalhat a csevegesbe egy unatkozo ms alkalmazott is. :D

szerintem igazan integralhatnanak bele egy botot, hogy kerdezze meg mire kivancsi, aztan kopjon le :-]

--
FBK

Azért az nem lehetett semmi a $MS-nak, hogy linux alá kellett fejleszteni. :)

Nem azért vette meg a Skype-ot az M$, mert annyira kellett volna neki, inkább zavarta, hogy a titkosítást nem tudták feltörni (erősen szvsz).
Amúgy az MS kicsit visszavehetne az orcájából. Míg itt becsmérlik a Google-t az információk gyűjtéséről - amit persze minden Google felhasználó elfogad -, addig, itt pedig kiderül, hogy ők gyűjtenek adatokat minden beleegyezés nélkül. Skype-ot már csak olyan dolgokra használom, ha valakinek csak X-fire-e van, akkor megkérem, hogy telepítse a Skype-ot, arra a két percre, amíg apró dolgokban egyeztetünk.

Jelen pillanatban 52 millio online usert ismer a Skype. Ez nem a osszeregisztraciok szama, a jelen pillanatban aktiv juzerek szama ekkora. Ezert es a mukodo infrastrukturaert fizettek ki nehany milliardot, nem a titkositas miatt, az senkit nem erdekel, foleg mikor mar a harombetusok tobb, mint egy evtizede ezt is le tudjak hallgatni ha akarjak.

---
pontscho / fresh!mindworkz

Skype az eddig is csak 32 bites volt? Hihetetlen, hogy meg mindig van amit nem sikerul leforditani 64 bitesre...

Nem csak az a hihetetlen, hanem az is hogy nincs a beállítások -> video beállítások menüpont alatt lehetőség kiválasztani hogy fejjel lefele akarok kamerázni vagy "fejjel felfele". Hát komolyan mondom röhej... Mindig bele kell nyúlni a skype.desktop konfig fájlba minden frissítés után hogy "fejjel felfele" működjön..

Tipp: tedd a LD_PRELOAD-os cuccot idezojelek koze, es akkor vissza lehet csempeszni a %U parametert is.

Ez utobbi azert nagyon fontos, mert ez felel a Skype integraciojaert, a skype:userke cimu link megnyitasa peldaul ugy tortenik, hog a %U behelyettesitodik erre a linkre. A skype linkekrol bovebben itt
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Philips SPC 620NC Webcam is pont ezt produkálta. Természetesen elhiszem, hogy a teljesen egyértelmű csiptetője nem azért van rajta, hogy azzal erősítse a boldog tulaj a laptop felső széléhez, hanem hogy a fölötte a Szentlélek által tartott vékonyka faágról lógassuk le, de sajnos nem volt kéznél Szentlélek, ezért bőven elég lett volna egy ilyen képfordító opció bárhol - akár a driverben, akár a Skype-ban. (Ráadásul mintha a sajt tesztszoftverében viszont jól mutatta volna a képet. De hálistennek régen volt, így minden mozzanatra nem emlékszem.)

Milyen állomány lenne nagyobb? A telepítő? Legyen külön. És azért legyen végre lefordítva 64-bitre, hogy aki nem szeretné, annak ne kelljen a 64-bites oprendszerére feltenni a 32-bites fv-könyvtárakat. Úgy tudom, hogy nem a Skype az egyetlen, de azért ha mindig azzal takarózznak, hogy de hát az X és az Y sincs megcsinálva, akkor tényleg a büdös életben nem lesz tisztán 64-bites OS egy PC-n.

Meg a többi 32 bites program. Szerintem amíg nem zökkenőmentes a programok 32 és 64 bites változatai között az átmenet (nem csak átbillentesz egy fordítási kapcsolót a legtöbb esetben sajnos), addig olcsóbb tárolni egy rakás + libet, mint a fejlesztőkre terhelni a karbantartást.
----
India delenda est.
Hülye pelikán

Mesélj, egy olyan programban, ahol minden nyomorult művelet eredménye ellenőrizve van, hogy az van-e ott, ami szabad hogy ott legyen, ott mi a pék f-t kellen még javítani? Úgy *gondolom*, hogy a nyelv által nem teljesen definiált változók használata lehet zűrös (nem short meg long, hanem int pl.) De nyugodtan felhomályosíthatsz, én szeretek nálam okosabbtól tanulni.

Egyáltalán nem garantált, hogy más architektúrán ugyanazok lesznek a padding értékek például.
Az említett int (amúgy a short meg a long sem teljesen definiált) ritkán probléma, hiszen legfeljebb többminden fél el benne.
A pointerek és egyéb adatszerkezetek méretváltozása miatt simán adódnak például performanciabeli problémák (más méretek mellett más megoldások lehetnek szükségesek), szerializálás, lowlvl konverziók is máshogy működnek.
Nem olyan triviális, mint ahogy ezt beállítod. Ehhez nem szarul kell megírni, csak nem tervezni 64 bitre. Ha eleve úgy kezdted a programot, hogy szándékodban áll mindkét bitszélességre releaselni, akkor természetesen meg lehet oldani, hogy minimális munka legyen, de a szoftverek többségét nem így kezdték pár évvel ezelőttig biztosan.
----
India delenda est.
Hülye pelikán

Azert a skype baromira nem ez a kategoria. Amivel munka lehet, az max a sajat protokollja, de nem hiszem, hogy olyan sok gondot okozna a 64 bites verzio, foleg. Az osszes tobbi cucca nyiltforrasu libekre epit (XML es SQLite a konfig es a db, Qt a GUI konyvtar), szoval ez a legkisebb.

A problema az, hogy a Skype mar sok eve van Linuxra, es meg a szandek sincs meg, hogy legyen egy 64 bites binaris. Ha akkor elkezdtek volna a munkat, amikor az elso verziot kiadtak a platformra, akkor meg ugy is keszen lennenek, ha napi 1 orat foglalkoznak vele.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Ha napi 1 órát foglalkozol vele, akkor sose lesz kész, mert 1 óra csak hogy bekerülj a tudatállapotba a többi mundkádból (vagy nem csak 1 órát vesz el, ha ezzel kezdesz). Akárhogy is nézzük: erőforrást igényel, nem is keveset. Égető szükség van rá? Az 1% Linuxhoz? Nem, a Skype tipikusan nem az az alkalmazás, ami sokat nyer a 64 bitből.
----
India delenda est.
Hülye pelikán

En ezt nem igy latom. Valaki vagy foglalkozik egy platformmal vagy nem. Amit a Skype most csinal, azzal inkabb ne lenne Linuxra.

Arrol nem beszelve, hogy ma a legtobb Linux desktop tulnyomoreszt 64 bites. Ami most van, az olyan, mintha meg mindig Qt3-ra fejlesztenek a klienst. Szoval nem, nincs igazad.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

De, igazam van. Azt állítottam, hogy sok erőforrás. Ez igaz. Azt is állítottam, hogy az 1%-os Linux nem éri meg, főleg, hogy nem nagy erőfeszítés 32 bites kompatibilitást elérni. Mesélj, hol nincs igazam? Ja, hogy neked nem tetszik a Skype hozzáállása, és inkább ne lenne? Szerintem meg a Linuxos Skype teljesen jó (a UI még sokkal jobb is, mint a Windowsos csilivili), bár én csak szöveges kommunikációra használtam, és szerintem sokan vannak, akik sajnálnák, ha nem lenne.
----
India delenda est.
Hülye pelikán

Szerintem nekem már 25 évvel ezelőtt is szóltak az akkori okosak, hogy az ember értelmesen tervezi meg a struktúráit - azaz igyekszik úgy kitalálni, hogy lehetőleg minimális legyen a padding (ha egyáltalán), azaz feltételezem ezt az infót az elmúlt negyedszázadban is elmondják a kezdő kódernak. Nek.
Mindenesetre én azt látom, hogy pont leszarja az MS, hogy meg kéne csinálnia a 64-bites verziót. Pedig mintha az ő oprendszere is abba az irányba menne, és azért az világröhej kategória lenne, ha a saját oprendszerére a saját aktívan fejlesztett programja miatt *kellene* hogy legyenek 32-bites libek (feltéve, hogy win alatt is valahogy így oldják meg). Amúgy meg valami olyasmi is rémlik, hogy 64-bites rendszer esetén a 32-bites alkalmazások futtatása némi teljesítményveszteséggel járna, de mivel indokolni nem tudom, hivatkozási alapom nincs, csak a halvány emlék, nyugodtan el lehet könyvelni a FUD-kategóriában.

Természetesen a _felesleges_ padding kerülendő (nem rakod felváltva a charokat meg az inteket). De itt egyáltalán nem csak erről van szó.
No meg millió és egy debug módszer lehet kifejlesztve egy ilyen szoftverhez (memóriaszkennerek, leakhunt (a valgrind nem mindig megoldás erre sem), performanciamérések), és ezek is mind változ(hat)nak 64 bitre.
----
India delenda est.
Hülye pelikán

struct {
char yes_or_no;
int look;
char live_or_die;
}
vs
struct {
long look;
char yes_or_no;
char live_or_die;
}

Kicsit hordozhatóbb az int/long csere miatt, és szerintem nincs benne padding. Vagy mire gondolsz? (Bár szerintem ne tőlem kérdezd, a paddingot nem én találtam ki.)

Olyasmi feltételezéseket gyakran tehetünk, hogy az int legalább 32 bit lesz, és ha ezen elindulsz, önmagában az, hogy az int nagyobb lesz még nem okoz problémát. Szóval ez gyakran nem probléma, és inkább írj intet, mint valami specifikus típust, ha lehet. Az inttypes meg nem része a régi C++ szabványnak, és abban sincs garantálva, hogy az adott típusok létezni fognak, csak ha léteznek akkor így hívják őket.
----
India delenda est.
Hülye pelikán

A C++ mar eleve nem portolhato, mivel nincs ABI-ja. Egy masik compilerrel forditott libraryt a kulonbozo name mangling miatt nem is tudsz felhasznalni. Oh yeah.

"Olyasmi feltételezéseket gyakran tehetünk, hogy az int legalább 32 bit lesz"
A szabvany megelegszik 16 bittel is. Nem kell az intnek 32 bitesnek lennie egyaltalan, igy ezt nem is tetelezheted fel.

"és inkább írj intet, mint valami specifikus típust, ha lehet."
Pont ez a hozzaallas basz oda a portolhatosagnak.

"A C++ mar eleve nem portolhato, mivel nincs ABI-ja."

Ez adott programot csak akkor zavar, ha használ (olyan) libeket. De a hordozhatóság nem azt jelenti, hogy adott fordítóval kell tudni futtatható állományt létrehozni, hanem hogy adott platformokra kell tudni. Olyan nincs, hogy valami _mindenhova_ hordozható.

"A szabvany megelegszik 16 bittel is. Nem kell az intnek 32 bitesnek lennie egyaltalan, igy ezt nem is tetelezheted fel."

De, feltehetem. Nem azt mondtam, hogy a szabvány tesz fel bármit is, hanem hogy a projektek jelentős része egyáltalán nem céloz olyan platformot, aminél az int nincs legalább 32 bit, és a jövőben sem fog előreláthatólag. Ilyenkor ezt feltehetjük.

"Pont ez a hozzaallas basz oda a portolhatosagnak."

Látom szeretsz abszolút módon gondolkodni. Én azt írtam, hogy gyakran ez a követendő, ha tudod, hogy elég a 32 bit. De hőbörögj csak tovább.
----
India delenda est.
Hülye pelikán

Nem, de ettol meg nem jo, ha felesleges szemetet kell felrakni. Pont az ilyen hozzaallas miatt van az, hogy sok cucc pargigas telepitovel erkezik, plusz meg magara rant masik par gigat frissitesben, mert "hat ugyis van hely, nem?".
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Miert, egy tipikus usernek mi kellene hogy 32 bites legyen a gepen?
- Adobe Acrobat: minden nagyobb DE-nek van sajat PDF olvasoja, a Chrome pedig beepitetten szallitja a PDF plugint
- Flash: mar megjelent a 64 bites verzio, a legtobb disztro azt szallitja
- Skype: itt jarunk most.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Akkor most zavarba hoztatok. Ennek csak a neve 64 bites? Mert van belőle név szerint is 32 bites csomag is, ami persze nekem nincs fenn:

java-1.7.0-openjdk-1.7.0.19-2.3.9.7.fc18.x86_64

Vagy a böngésző pluginra gondolsz?

icedtea-web-1.4-0.fc18.x86_64

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

mivel egy program windowsos és linuxos verziója közül általában a windowsos javára (höhö) szokott billenni a mérleg nyelve a használhatóságot tekintve, ezért feltételeztem hogy ebben az esetben is így van.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Az, hogy milyen minőségű egy adott platformra egy program, mennyiben befolyásolja azt, hogy miről van szó ebben a topic-ban? Arról volt szó, hogy a 32 bites Skype miatt kell felrakni egy rakás 32 bites library-t 64 bites Linuxra. Érveltél a Java környezettel, mire mondtam, hogy abból is a 64 bites van fenn, s ez így van rendjén.

A mérleg nyelve dolgot nem értem. Teszem azt, mennyivel jobban használható egy Firefox Windows-on, mint Linuxon? Nem mindegy az alkalmazás szempontjából, hogy a memória foglalást a Windows vagy a Linux kernele realizálja? Ha meg nem azonos programokat hasonlítunk össze, hanem adott célra szánt programokat, akkor meg azt mondom, ez igen szubjektív. Mondhatnám, a linuxos rm parancs nekem jobban tetszik, mint a windows-os del parancs, s valószínűleg aligha fogsz meggyőzni az ellenkezőjéről. Ha meg az eredményt nézzük, a Windows del parancsa éppúgy letörli a file-t, mint a Linux rm parancsa. De mondom, annak, hogy Neked vagy nekem mi tetszik, semmi köze ahhoz, hogy lényegében csak a Skype miatt kell 32 bites függvénykönyvtáraknak, s a Skype-nak, mint 32 bites alkalmazásnak a gépen lennie.

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

"Teszem azt, mennyivel jobban használható egy Firefox Windows-on, mint Linuxon? Nem mindegy az alkalmazás szempontjából, hogy a memória foglalást a Windows vagy a Linux kernele realizálja?"

Egy rakás platformfüggő rész van benne, pl. gui, hw acceeration, stb. Sőt, még ha egy multiplatform libet is használ valamire, annak is platformfüggő implementációja lehet, ami eltérő minőségű lehet a különböző platformokon.

ja izé, a tipikus user élne velük... gondolom... nemtom, én se vagyok az :)

Hát, a steam nekem első induláskor rögtön sírt egy csomó hiányzó 32 bites lib miatt, szóval gondolom hogy 32 bites, játékokat meg láttam olyat, amihez csomagoltak külön 32 és 64 bites binárist, meg olyat is amihez csak egyet, gondolom utóbbi 32 bites lehetett...

Uj Ubuntu alatt vajon nem fog mar crashelni es a hangero is szabalyozhato?

Nekem ugy tunik, a libpruple-lel sajnos tovabbra sem mukodik megfeleloen egyutt.

S hogyhogy a sip kliensek nincsenek sehol?
Az nem ugyanaz? Élő videó és hang kapcsolat?

Mert SIP-en nem olyan egyszerű azért élet, magadnak ráncigálod be az összes codec-et, az legyen meg azért a túloldalon is, mert anélkül nehéz...
többet kell konfigurálni, stb.
A Skype-ba meg beleregisztrál a használó és megy, még kiszolgálót sem kell üzemeltetned.

Teljesen másra van kitalálva mind a kettő.