# Verständnisfrage: Wieso kann ein Programm "sterben" <Skype>

## scurrell

Da das Thema ja jetzt (eigentlich ja noch nicht) auf gelöst gesetzt wurde, möchte ich trotzdem etwas dazu nachfragen.

Ne, eigenes Thema. Hintergrund: https://forums.gentoo.org/viewtopic-t-1013820.html

Als Beispiel möchte ich mal "Game of Life in 3D" anführen. Irgendwann läßt die Resonanz nach, der Dev zieht sich zurück

und das Programm "bleibt stehen". So wie es eben ist, färbt es Felder in verschiedene Farben.

Skype allerdings benutzt das Internet und um Einbrüche ( also Einbruch wie Straftat ) zu verhindern, muß der SourceCode regelmäßig verändert werden. Mal besser, mal schlechter. So wie jeder RL-User sein Passwort alle 4 Wochen ändert.

Das kann ich ja irgendwie noch nachvollziehen.

 *Josef.95 wrote:*   

> ...
> 
> Ich würde davon abraten sich die alten, nun ungepflegten toten, inzwischen hart maskierten 
> 
> app-emulation/emul-linux-x86-* Pakete freizuschalten.

 

https://forums.gentoo.org/viewtopic-t-1012714.html -> Vorsicht Chaos.

[OT]

Ok, ich bin vielleicht nie in der Lage gentoo zu installieren/pflegen. Aber vielleicht bin ich möglicherweise irgendwann in der Lage....

möglicherweise in der Lage jemandem zu erklären, wie man das macht.

Ein alter Mann mit Krückstock lernt nicht mehr Einradfahren, guckt aber gern den Akrobaten zu, die das in 30 Metern Höhe ohne Netz machen.

[/OT]

Jetziges Verständnis: QT hat einen Bug, deswegen ist Skype "gestorben" doch das wird doch von  ∞ Usern benutzt.

Die Resonanz ist also da.

Ergebnis = Abhängigkeit hat einen Bug -> Programm "tot" ?

Doch so einfach ist das wohl nicht.

Jetzt hab ich schon wieder mein Googler-Problem: Was soll ich eigentlich googlen, wenn ich nicht weis, was

----------

## ChrisJumper

hi scurrell,

bitte nimm es mir nicht übel. Du stellst manche Fragen weil dir die Zusammenhänge nicht bewusst sind. Das ist auch alles nicht schlimm, aber man stößt auf Zurückhaltung anderer die Zeit investieren dir bestimmte Zusammenhänge zu erklären.

Ich bin jetzt selber nicht mehr up2date was Gentoo betrifft. Skype ist wenn ich mich nicht täusche ein 32 Bit-Program. Das wird bestimmt nicht eingestampft zumal es ja jetzt von Microsoft kommt. Der Gentoo-Support ist auch noch da. Allerdings vermute ich das sich das etwas schwieriger Gestaltet zur Zeit, da (besonders die 64 Bit Systeme) jetzt ihre Multilib-Eigenschaft umstellen.

Wie es vorher war: 32 Bit Systeme erzeugen 32 Bit Code, auch Library's also Programmbibliotheken. 64 Bit Systeme, können 32 Bit Code zwar ausführen hatten bis vor kurzem aber keine selbst kompilierten 32 Bit Bibliotheken. Man kann kein 32 Bit Binary gegen eine 64 Bit Library Linken.

Stelle dir einfach eine Windows .exe Datei vor, gegen diese Datei sind eben die Bibliotheken gelinkt, welche zur Ausführung im Speicher sein müssen. Die meisten Windows Programme teilen sich keine Bibliothek sondern kopieren/packen die Bibliotheken teilweise in die Exe-Datein. Das hat den Vorteil das das Programm dann auch läuft, selbst wenn der Ausführende die Bibliothek-Datei nicht installiert hat oder eine andere Version installiert.

Im Gentoo macht es z.B. nicht, bis auf manche Kommerzielle ausnahmen. Weil wenn man sie nicht als Kopie in Ausführbare Dateien einbaut, kann man die neue Version von der Bibliothek einfach bei der Ausführung des Programmes ein mal in den Speicher laden. Im Gegensatz zur Kopie der Windows Version teilen sich verschiedene Programme welche die selbe Bibliothek brauchen auch eine Kopie davon. Bekommt die Bibliothek ein Update, müsste man die Exe/Ausführbare Datei neu bauen.

Das hat man unter Gentoo zwar auch, aber im Ideal Zustand eher seltener wenn man System-Bibliotheken nutzt, statt diese fest einzubauen. Hat eine Bibliothek eine Sicherheitslücke, wie letzt sqlite (welche auch von Firefox und anderen Programmen als Datenbank-Backend genutzt wird), braucht man nur die Bibliothek neu bauen und die Programme neu starten. ;)

Die emul-linux Pakete wurden wirklich aus Sicherheitsgründen raus genommen, denn sie wurden "selten" aktualisiert zu oft wäre Problematisch für alle Programme die sie unterstützen und zu langsam ist halt schlecht für Bugs. Somit, gab es damit immer Probleme und letztlich wie du sagtes Sicherheits-Schlupf-Löcher.

So jetzt noch mal zu Gentoo und Skype hier gab es eine Umstellung bei der Multilib. Sofern ich das verstanden habe kompilieren die 64 Bit Systeme im Cross-Compile (?) Modus die 32 Bit-Bibliotheken selber und die kommen dann in /usr/lib32 das 64 Bit Exemplar wird normal kompiliert und landet in /usr/lib64 aktuell mag es mit Skype noch Probleme geben aber ich bin mir sicher das sich das von alleine in Luft auflöst.

Im Zweifelsfall zuerst Skype deinstallieren. Das System auf Multilib ausrichten, also in der make.conf

```
ABI_X86="64 32"
```

eintragen. Alles neu bauen (wegen dem neuen Use-Flag) und vorher alle emul-linux-Pakete entfernen. Auch die QT-4.8.6 Pakete nutzen, wie Josef.95 sagt:

 *Quote:*   

> Hehe, True Qt Multilib-Support ist doch nun im Tree (ab qt-4.8.6) verfügbar :)
> 
> Ich verstehe nicht warum ihr ihn nicht nutzt...

 

Dann einfach Skype wieder installieren und alles sollte funktionieren wie vorher.

----------

## py-ro

Das Problem bei Skype ist, dass Qt noch nicht mit dem neuen Multilib in Stable angekommen ist. Demaskiert man die ~amd64 Qt Pakete lässt sich auch Skype relativ schmerzfrei installieren.

Als Ergänzung zu dem ausführlichen Beitrag vor mir,

Bye

Py

----------

## Klaus Meier

Bei mir ist skype sehr lebendig. Ein emerge skype gibt bei mir folgendes aus (Nur ein Teil):

```
The following USE changes are necessary to proceed:

 (see "package.use" in the portage(5) man page for more details)

# required by net-print/cups-2.0.2-r1::gentoo[dbus]

# required by dev-qt/qtgui-4.8.6-r2::gentoo[cups]

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=sys-apps/dbus-1.8.16 abi_x86_32

# required by x11-libs/libXfixes-5.0.1::gentoo

# required by x11-libs/libXcursor-1.1.14::gentoo

# required by dev-qt/qtgui-4.8.6-r2::gentoo

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=x11-libs/libX11-1.6.3 abi_x86_32

# required by media-sound/pulseaudio-6.0::gentoo[X]

# required by net-im/skype-4.3.0.37-r5::gentoo[pulseaudio]

# required by skype (argument)

>=x11-libs/libXtst-1.2.2 abi_x86_32

# required by net-libs/gnutls-3.4.0::gentoo[nls]

# required by net-print/cups-2.0.2-r1::gentoo[ssl]

# required by dev-qt/qtgui-4.8.6-r2::gentoo[cups]

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=virtual/libintl-0-r1 abi_x86_32

# required by x11-libs/libXrandr-1.4.2::gentoo

# required by dev-qt/qtgui-4.8.6-r2::gentoo

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=x11-proto/randrproto-1.4.1 abi_x86_32

# required by net-libs/gnutls-3.4.0::gentoo

# required by net-print/cups-2.0.2-r1::gentoo[ssl]

# required by dev-qt/qtgui-4.8.6-r2::gentoo[cups]

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=dev-libs/nettle-3.1 abi_x86_32

# required by virtual/pkgconfig-0-r1::gentoo

# required by dev-qt/qt3support-4.8.6-r1::gentoo

# required by dev-qt/qtgui-4.8.6-r2::gentoo[qt3support]

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=dev-util/pkgconfig-0.28-r2 abi_x86_32

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo[gstreamer]

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=media-libs/gst-plugins-base-0.10.36-r2:0.10 abi_x86_32

# required by dev-qt/qtgui-4.8.6-r2::gentoo

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=media-libs/libpng-1.6.17 abi_x86_32

# required by x11-libs/libXtst-1.2.2::gentoo

# required by media-sound/pulseaudio-6.0::gentoo[X]

# required by net-im/skype-4.3.0.37-r5::gentoo[pulseaudio]

# required by skype (argument)

>=x11-proto/inputproto-2.3.1 abi_x86_32

# required by x11-libs/libxcb-1.11-r1::gentoo

# required by media-sound/pulseaudio-6.0::gentoo[X]

# required by net-im/skype-4.3.0.37-r5::gentoo[pulseaudio]

# required by skype (argument)

>=dev-libs/libpthread-stubs-0.3-r1 abi_x86_32

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=dev-qt/qtcore-4.8.6-r1:4 abi_x86_32

# required by sys-libs/gpm-1.20.7-r2::gentoo

>=sys-libs/ncurses-5.9-r4 abi_x86_32

# required by media-libs/fontconfig-2.11.93::gentoo

# required by dev-qt/qtgui-4.8.6-r2::gentoo

# required by dev-qt/qtwebkit-4.8.6-r1::gentoo

# required by net-im/skype-4.3.0.37-r5::gentoo

# required by skype (argument)

>=dev-libs/expat-2.1.0-r4 abi_x86_32

```

Du fügst ein paar Zeilen zu der package.use hinzu und schon kannst du skype übersetzen. Und emerge sagt dir da genau, was du tun musst.

----------

## Christian99

 *Klaus Meier wrote:*   

>  und schon kannst du skype übersetzen.

 

Was musstest du denn machen, dass M$ dir den quelltext gibt?  :Smile: 

----------

## musv

Aber um mal auf die Anfangsfrage zurückzukommen:

"Wieso kann ein Programm (Skype) sterben?"

Man kaufe ein brauchbar funktionierendes Produkt mit großer Nutzerbasis, pumpe haufenweise Werbung hinein (Windows-Version), verwende noch dazu Lennaware für den Soundsupport und schon vergrault man einen Teil der Nutzer. Ein paar mehr werden es, wenn es einen Update-Zwang gibt und Nutzer älterer Versionen sich nicht mehr einloggen können. Das ist nämlich ziemlich doof, wenn man irgendwo ein Linux installiert hat, was Skype nicht im Paketmanager hat, z.B. OpenSuse.

Und seit Facebook ist auch der Anteil an anderen Messengern sowieso stark zurückgegangen. 

Bild- und Tonqualität fand ich bei Google Hangouts auch besser und problemloser. Bei Skype hatte ich immer Probleme, dass der Ton gekratzt hatte und das Mikro auch sehr sensibel war. 

Und da ich sowieso nur einen aktiven Kontakt außer der Familie in Skype hatte, ist das Programm bei mir gestorben. Die Familie verwendet mittlerweile Hangouts, wenn es wirklich sein muss. 

Und so ist Skype halt bei mir gestorben.

----------

## arfe

 *Klaus Meier wrote:*   

> Du fügst ein paar Zeilen zu der package.use hinzu und schon kannst du skype übersetzen. Und emerge sagt dir da genau, was du tun musst.

 

package.use wird in diesem Fall nicht reichen. Er muss die Packages in package.unmask eintragen, weil dort unstable packages drin sind.

Würde ich allerdings alles nicht empfehlen und warten bis 4.8.6-r1 stable ist.

----------

## Klaus Meier

Das hatte py-ro doch schon geschrieben. Trotzdem muss man aber noch einen Eintrag in die package.use machen und das habe ich beschrieben.

----------

## arfe

 *Klaus Meier wrote:*   

> Das hatte py-ro doch schon geschrieben. Trotzdem muss man aber noch einen Eintrag in die package.use machen und das habe ich beschrieben.

 

Einen? Das ist mehr als nur ein Entrag.

----------

## firefly

 *arfe wrote:*   

>  *Klaus Meier wrote:*   Das hatte py-ro doch schon geschrieben. Trotzdem muss man aber noch einen Eintrag in die package.use machen und das habe ich beschrieben. 
> 
> Einen? Das ist mehr als nur ein Entrag.

 

mit 

```
dev-qt/*:4 <useflag> 
```

 ist es nur eine zeile  :Wink:  (im falle für alle qt4 pakete)

----------

## Josef.95

 *arfe wrote:*   

>  *Klaus Meier wrote:*   Du fügst ein paar Zeilen zu der package.use hinzu und schon kannst du skype übersetzen. Und emerge sagt dir da genau, was du tun musst. 
> 
> package.use wird in diesem Fall nicht reichen. Er muss die Packages in package.unmask eintragen, weil dort unstable packages drin sind.
> 
> Würde ich allerdings alles nicht empfehlen und warten bis 4.8.6-r1 stable ist.

 

Hm nein, skype und deren Qt Deps sind allesamt im testing-zweig verfügbar - Einträge in der package.unmask sind nicht erforderlich. Nichts von dem ist hart maskiert.

Vermutlich war package.accept_keywords gemeint.

----------

## scurrell

 *ChrisJumper wrote:*   

> hi scurrell,
> 
> bitte nimm es mir nicht übel. Du stellst manche Fragen weil dir die Zusammenhänge nicht bewusst sind. Das ist auch alles nicht schlimm, aber man stößt auf Zurückhaltung anderer die Zeit investieren dir bestimmte Zusammenhänge zu erklären.
> 
> 

 

Du hast ja recht. Als ich gentoo das erste Mal in Händen hielt ( eigentlich war es ja nur eine stage3 auf der Festplatte ), dachte ich noch

.. na toll, noch so ein Linux. Doch der Packetmanager sieht sehr interessant aus.

[bildlich] Doch gentoo ist kein Auto. gentoo ist ein Flugzeug. Da benötige ich einen ganz anderen Führeschein für. [/bildlich]

Und falls jetzt der Einwand kommt: Mann, lern doch erstmal Linux....

Na ja, mach ich doch. Doch jede Distro ist wie ein Turnschuh. Mancher passt, mancher nicht.

Die Distro, die ich mir aussuchte, hat kein deutsches Forum.

Surely, I can ask the forum in different languages. But can I be able to understand the answers ?

Deswegen hatte ich mir ja auch ein deutsches Forum gesucht.

Und alle Fragen die ich hatte, wurden absolut vollständig beantwortet.

Das ich persönlich nicht in der Lage bin das umzusetzten... pech

Aber das man 32bit.libs nicht gegen 64bit.libs linken kann, wissen jetzt auch Mitleser. ( Edit: Nope, umgekehrt )

Und Skype scheint ja wohl nur der <Top of the Eisberg> zu sein.

----------

## musv

 *scurrell wrote:*   

> Und Skype scheint ja wohl nur der <Top of the Eisberg> zu sein.

 

Nö, ist es nicht. 

Die Multilibgeschichte betrifft eigentlich nur Software, die nur als Binary verfügbar ist. Zumindest auf meinem System kann ich mich da nur an Skype und Google Earth erinnern. Und bei Kodi (XBMC) gibt's ein Plug-In ProjectM zur visuellen Musikaufhübschung. Das war's dann eigentlich auch schon. 

Unter Windows ist das ungleich chaotischer. Da dort die meiste Software nur als Binary verfügbar ist, ist das System schon per Default ein wildes Gemisch. Der neueste Coup dabei ist, dass M$-Office 2013 zwar im c:\Program Files (also 64 bit) installiert wird, im Prozess Explorer sich aber als 32-bit Binary outet. 

Im Grunde genommen ist aber 64 bit bei den meisten Programmen erst notwendig, wenn der benötigte Speicher > 3,3 GB groß wird. 

Zwecks Standard-CPU-Flags für maximale Kompatibilität bringt aber amd64 noch ein paar weitere Vorteile, da mehr CPU-Features genutzt werden können. Bei 32bit muss man halt entscheiden, bis zu welcher alten CPU die Software noch laufen soll.

----------

## Josef.95

Die Liste mit Paketen, die zwingend multilib-Support benötigen, kann man in

/usr/portage/profiles/arch/amd64/no-multilib/package.mask

einsehen.

----------

## Schattenschlag

Also ich finde die Umstellung zwischen 32Bit auf 64Bit echt schon Witzig. Das zieht sich ja schon echt wie ein mega Kaugummi.

Wenn ich so zurück denke 8Bit 16Bit 32Bit hmmm da ging das irgendwie schneller (ok es gab auch weniger Programme)

Aber wenn es so weiter geht kommen ja schon bald 128Bit CPUs raus bevor wir mal richtig auf 64Bit alles umgestellt haben.

----------

## py-ro

Wir haben nicht einmal "echte" 64-Bit CPUs, meist sind die Speicherinterfaces "nur" 48-Bit.

Bye

Py

----------

## Schattenschlag

@py-ro  Hardwaremäßig kenne ich mich da zu wenig aus. Hättest du da gute Infos ?

----------

## mv

 *Schattenschlag wrote:*   

> Also ich finde die Umstellung zwischen 32Bit auf 64Bit echt schon Witzig. Das zieht sich ja schon echt wie ein mega Kaugummi.

 

Das liegt aber ausschließlich an proprietärer Software: acroread, googleearth, skype und Windows-Programme unter wine verweigern die Umstellung, und dadurch wird alles in Mitleidenschaft gezogen. Die gesamte freie Software ist schon lange 64-bit-fähig.

Ein schönes Beispiel, wie kommerzielle Eigeninteressen den Fortschritt blockieren.

----------

## __bjoern

naja, es ist schon gut, dass es noch Unterstützung für 32 Bit Plattformen gibt, denn die werden nach wie vor benutzt (von mir z.B.  :Very Happy: ). Die müssen es halt nur auf die Reihe kriegen 32 und 64 Bit builds von ihrer Software bereit zu stellen. Das kriegt jede Linux-Distribution hin, aber viele Entwickler reden sich halt immer mit dem selben ollen Spruch raus "Was brauchen wir denn 64 Bit Builds, unsere Software nutzt eh nicht so viel RAM".

Wenns nach den Brüdern ginge, würde der Taschenrechner noch mit 8 Bit DOS-Emulation laufen.

Das ist ja z.B. beim Firefox für Windows echt lächerlich. Wie lange die brauchen um mal nen 64-Bit build bereit zu stellen. Und dann wollten die das Projekt ja komplett absagen (!).

Aber unter Gentoo gab es eigentlich wenig Probleme. Das einzige, was ich hatte waren Opera, Skype und diverse Spiele. Ich hätte mir nur gewünscht, dass die noch gewartet hätten, bis die neue Qt Version auf stable ist.

----------

## musv

 *__bjoern wrote:*   

> Das einzige, was ich hatte waren Opera, Skype und diverse Spiele.

 

Closed Source Binaries. 

Wobei Opera das entgegengesetzte Beispiel ist. Das gibt's nur noch in 64bit.

----------

## bell

Etwas OT: x86 wurde ja noch nicht ganz durch amd64 abgelöst, das wird sich auch etwas hinziehen. Um das ganze interessanter zu machen, gibt es jetzt auch noch x32  :Wink:  Diese Architektur soll die Vorteile beider Welten vereinen.

http://de.wikipedia.org/wiki/X32_%28ABI%29

https://archives.gentoo.org/gentoo-dev/message/8ecc71e69a11ae39cd16f21bc553341b

----------

## mv

 *bell wrote:*   

> Diese Architektur soll die Vorteile beider Welten vereinen.

 

"Soll" ist die richtige Formulierung   :Wink: 

Außer auf speziellen eingebetteten Systemen oder für gigantische Datenbanken, die im RAM gehalten werden sollen, und wo daher jedes Byte Ersparnis eine Bedeutung hat, gibt es keinen Grund für ihre Benutzung: Theoretisch kann man im besten Fafll eine Arbeitsspeichernutzung von knapp 50% beim Datenverwaltungs-Overhead erwarten (also natürlich nicht für die eigentlichen Daten); in der Praxis - vor allem für Anwendungen, die für den "Normalbenutzer" interessant sind - ist dieser Overhead nur ein kleiner Bruchteil der eigentlichen Daten, und die Ersparnis im Overhead ist in der Praxis auch nur ein kleriner Bruchteil davon (vielleicht von sehr speziellen Anwendungsfällen abgesehen, für die ich allerdings keine Beispiele kenne).

Dafür hat man den Nachteil, dass es, wenn man nun doch in irgendeinem Fall mehr Speicher braucht (Filmschnitt o.ä.) plötzlich unerwartet zu Problemen und Überläufen kommen kann.

SInd diese geringfügigen Vorteile (aber auch Nachteile) den Ärger mit proprietären Binaries wert?

x32+32bit Multilib mag vielleicht noch Sinn ergeben. Sobald man aber zusätzlich ein 64bit Multilib braucht, hat man die Platzvorteile schon verspielt und letztlich also nur noch Nachteile und Ärger am Hals.

----------

## Yamakuzure

 *mv wrote:*   

>  *Schattenschlag wrote:*   Also ich finde die Umstellung zwischen 32Bit auf 64Bit echt schon Witzig. Das zieht sich ja schon echt wie ein mega Kaugummi. 
> 
> Das liegt aber ausschließlich an proprietärer Software: acroread, googleearth, skype und Windows-Programme unter wine verweigern die Umstellung, und dadurch wird alles in Mitleidenschaft gezogen. Die gesamte freie Software ist schon lange 64-bit-fähig.
> 
> Ein schönes Beispiel, wie kommerzielle Eigeninteressen den Fortschritt blockieren.

 Da sagst du was.

Als ich vorgestern gelesen hatte, dass das neue Star Wars Spiel ein 64bit Windows voraussetzt, habe ich gestaunt. [Sarkasmus]Echt? Jetzt schon?[/Sarkasmus]

Bei kommerzieller Software werden zum einen Entwicklungsumgebungen verwendet, die lange getestet und Qualitätsgesichert sind. Wir haben 2015, und manch eine Firma verwendet immer noch Visual Studio 2008.

Zum anderen werden Firmeninterne Bibliotheken eher schleppend aktualisiert und auf 64bit gezogen. Ich habe neulich mal, da ich das für ein Projekt brauchte, Allegro 4 auf Visual Studio 2013 64bit gezogen. Ich verstehe schon, dass das kein Spaß ist.

Und so lange die Leute nicht verstehen, warum WOW64 eigentlich ganz und garnicht spaßig ist, wird das auch weiterhin so schleppend laufen.

----------

