Ubuntu-fr

Il faudrait avertir les utilisateurs que la 18.04 est une catastrophe sur les laptops Nvidia Optimus récents.
Là où la 17.10 brillait par son support de ces configs dès l'installation, la gestion de l'énergie est ici absente.

Le module bbswitch qui servait à économiser de l'énergie et limiter la chaleur dégagée n'est plus utilisé par nvidia-prime, l'outil fourni (le module n'est plus maintenu, donc les devs d'Ubuntu ont choisi de ne plus l'utiliser).
À sa place, le driver nouveau est chargé et tente de désactiver la carte nvidia dédiée... Ce qui ne fonctionne pas et cause un freeze sur les cartes de série 10xx.
Sur les configs récentes, ce comportement est interdit par la configuration par défaut, ce qui revient à admettre qu'Ubuntu ne gère plus l'énergie sur les laptops Nvidia Optimus.

Je suis dégoûté et je pense downgrader mon installation, impossible d'utiliser mon laptop dans ces conditions.

EDIT: J'ai réussi à désactiver la carte intel en créant un service systemd qui appelle bbswitch. Nouveau doit aussi être backlisté pour que ça fonctionne. Si quelqu'un veut des instructions détaillées, je pourrai faire un tuto.

Non, ça désactive complètement la gestion de l'énergie par nouveau
On peut alors se connecter en mode graphique sans causer de freeze, mais la carte nvidia consommera de l'énergie et chauffera.

Par contre, chez moi, même avec cette option, j'ai des gros ralentissements... La seule solution a été de blacklister totalement nouveau.

J'ai pas mal tâtonné pour trouver une config qui fonctionnait... Je vais essayer de retrouver toutes les étapes.

J'ai fait de Gnome Calendar mon client pour les agendas, par défaut. Lorsque Gnome Shell affiche une notification pour un événement et que je clique sur cette notification, Gnome Calendar ne s'ouvre pas. C'est normal, ou c'est un bug ?

Geary est le client email par défaut en 17.10 ? (et quelqu'un sait comment marque un dossier comme lu sous Geary ? J'ai cherché un peu sur Google, rien à ce propos...)

On a une idée de quand Artful sera compatible avec les cartes graphiques Nvidia (+ pilotes proprio) ?

J'ai réussi à identifier le pattern de mon bug de switch de carte graphique
Sélection d'une carte graphique différente de la carte actuele via nvidia settings -> déconnexion -> reconnexion impossible et retour à GDM.
Si je redémarre avant d'essayer de me reconnecter, le bug n'apparaît pas.
Le bug apparaît dans les 2 sens (intel -> nvidia, nvidia -> intel)

Quelqu'un confirme ?

@Gatsu : Je ne peux rien révéler, hélas !
Par contre on vient de recevoir la version Linux de Shadow Warrior (2013), qui est maintenant en ligne sur le site : le portage est vraiment excellent ! Je l'ai fini hier soir sans rencontrer aucun problème.

@Maz : Puisque mon poste de travail est sous Ubuntu 15.04, et que celui du responsable de nos paquets pour Linux est sous Debian, on est les premiers concernés... GOG Galaxy repose principalement sur Qt, la version Linux devrait arriver prochainement (pas de date précise pour le moment), en tout cas je confirme que le portage est en cours, j'ai croisé un dev qui travaille dessus depuis pas mal de temps

Bref, j'ai des Virtualbox avec Windows 7 et 8 qui fonctionnent en permanence (pour pouvoir aider les utilisateurs en plusieurs langues et sur plusieurs systèmes), idem pour Ubuntu 14.04 et Mint 17 (les distributions officiellement supportées).

Half-Life 3 sans DRM sur GOG, evidemment.

Je n'ai pas accès au détail des contrats avec les éditeurs, mais oui, en général, une version Linux existante manquante dans notre catalogue indique un problème de droits. System Shock 2 est présent depuis longtemps dans le catalogue, avant que le support Linux soit annoncé sur GOG, je pense donc que le contrat avait été négocié pour Windows et Mac, et Linux n'a simplement jamais été mentionné. Et maintenant, personne n'a trop envie de renégocier...

En général, si les développeurs sont toujours actifs, et indépendants ou sous contrat avec l'éditeur, on obtient des versions sans DRM sans trop de difficultés. Sauf si le jeu est très dépendant de Steam : dans ce cas, ça peut prendre du temps, et parfois les devs traînent un peu des pieds (c'est un travail relativement ingrat).
Si les devs ne sont plus actifs, ou plus directement en relation avec l'éditeur qui a les droits sur le jeu, on utilise d'autre méthodes pour désactiver les DRM (désactivation en modifiant l'exécutable, clés CD toujours valides, wrapper pour rendre securom inactif etc). Évidemment, cela est toujours validé par l'éditeur.

The Witcher: Wild Hunt nécessite DirectX 11, et Wine en est bien loin pour le moment...
La seule couche de compatibilité qui support DX11 pour le moment est eON, qui n'est pas publiquement disponible en dehors des quelques jeux avec lesquels elle est distribuée (Witcher 2, Bioshock Infinite, Spec Ops: The Line).

Concernant The Witcher 2, il ne devrait plus y avoir de décalage entre la version GOG et la version Steam.

En effet, pour nous, diffuser des DEB sans compression n'est pas envisageable, cela nécessiterait 20 à 50% de bande passante en plus.

J'ai suggéré l'idée de DEB interdépendants à notre responsable Linux, mais l'idée lui déplaît car nos outils sont mieux adaptés à la combinaison 1 exécutable + X archives bin qu'à de multiples DEB. En plus cela nous permet de faciliter la vie des utilisateurs des distros non supportées officiellement qui ne sont pas des dérivés de Debian.

Il me semble que c'est dans InnoExtract 1.5rc1, mais je n'ai pas eu à me servir de cet outil depuis plus d'un an.
https://github.com/dscharrer/innoextrac … t-68485024
(l'un des posts de la discussion indique précisément comment obtenir le mot de passe d'un .BIN protégé, les devs d'InnoExtract étaient donc au courrant)

Il me semble que cette solution posait plusieurs problèmes, mais je ne me souviens plus des détails. Apparemment, la différence est qu'il s'agit de fichiers directement téléchargeables, et non de fichiers à extraire depuis une archive ou un disque d'installation. Dans notre cas, on s'expose encore à des comportements bizarres de la part de certains navigateurs et gestionnaires de téléchargement.
Il faudrait aussi que l'on modifie InnoSetup pour changer l'extension, et même si la modification est triviale, c'est un outil proprio.

En général, pendant le téléchargement, les navigateurs et téléchargeurs ajoutent/remplacent l'extension par .DOWNLOAD . Dans certains cas, restaurer l'extension d'origine échoue. Problème pour les utilisateurs novices : les extensions de fichiers sont cachées par défaut sous Windows. L'utilisateur a l'impression d'avoir les fichiers requis, mais évidemment le programme d'installation ne les trouve pas.

C'est aussi à cette étape que l'extension des .BIN peut être changée en .RAR : il semble que certains logiciels sous Windows n'utilisent pas uniquement l'extension du fichier, mais aussi d'autres caractéristique (type MIME, en-tête ?). Une extension personnalisée, comme .GOG, ne nous protégerait pas, et pourrait même aggraver le problème (extension inconnue -> changement systématique de l'extension sur les systèmes concernés).

Si l'utilisateur a un PC un peu faible, qu'il installe a partir de son dossier de téléchargement pas nettoyé depuis longtemps, et qu'il y a des archives de plusieurs Go, le PC va donner l'impression de ne plus répondre pour une durée inacceptable. J'avais un outil perso qui faisait la même chose pour trouver les différentes versions du programme d'installation d'un jeu. J'ai dû désactiver cette fonctionnalité après les rapports de mes premiers testeurs.
Et je doute qu'il soit possible de rendre InnoSetup aussi ""intelligent" sans le modifier (et c'est un outil proprio).

J'ai un message type pour ce cas
Afficher les extensions de fichiers + Capture d'écran du dossier avec tous les fichiers bien visibles.

En plus :
- Je suis payé pour résoudre ce type de problème,
- Tout le monde n'a pas eu la chance de grandir avec avec un PC entre les mains, et la plupart des cas de "sabotage" sont bien involontaires...

Gowor était conscient que l'ajout du mot de passe était une protection très faible, il l'a dit lui même un peu plus bas dans la discussion. Mais l'avantage était de forcer ceux ajoutant des malwares à complètement reconstruire l'archive au lieu de simplement la modifier (les outils existants ne décompressent que les ressources contenues dans les archives, c'est à dire le jeu, et non la source du programme d'installation, toute sa config XML). Difficile dans ce cas de générer une archive identique ET signée sans créer des outils plus poussés que ceux qui sont disponibles publiquement. Les pirates sont bons, mais ils n'ont pas forcément des ressources illimitées.
Dans ce cas, les programmes d'installation reconstruits perdaient la signature Windows, et une alerte s'affichait si un programme d'installation modifié était utilisé.

Pour les fichiers renommés, Gowor est programmeur, donc pas exposé quotidiennement à ce problème, il a sans doute oublié d'ajouter ça à son post. Côté assistance technique, on voit ça très fréquemment.

Du nouveau !
http://www.gog.com/forum/general_fr/du_ … eurs_linux

[edit : oups, j'avais lu en diagonale, la fatigue. Content de voir que znes fonctionne.]
Hello @Help et @Xabilon, ça me rappelle un cas très courant au boulot (chez GOG.com) :
sur une installation fraîche et à jour d'Ubuntu 14.04.x (x étant 2, 3 ou 4), libgl1-mesa-glx n'est pas installable, car l'ensemble de la "pile graphique", serveur X, drivers, bibliothèques OpenGL sont en réalité des rétro-portages (backports) depuis des versions d'Ubuntu plus récentes, et les paquets installables doivent porter un suffixe correspondant à la distribution d'origine du rétro-portage.

C'est un choix qui a été fait par Canonical afin que leur distribution 14.04 LTS supporte du matériel sorti après avril 2014.

Les paquets à installer sont donc :

libgl1-mesa-glx-lts-utopic
libgl1-mesa-glx-lts-utopic:i386

ou

libgl1-mesa-glx-lts-vivid
libgl1-mesa-glx-lts-vivid:i386

ou

libgl1-mesa-glx-lts-wily
libgl1-mesa-glx-lts-wily:i386

Le suffixe à ajouter à tous les paquets en rapport avec Mesa/X/drivers... correspond à la distribution Ubuntu la plus récente au moment ou le média qui a servi à l'installation fraîche a été téléchargé.

D'ailleurs, j'ai un collègue qui m'a envoyé cette ligne un peu plus tôt. Pas encore testé (d'habitude j'examine la liste des paquets installés chez nos clients puis je leur envoie le nom des paquets à installer), mais ça m'a l'air d'automatiser la détection :

sudo apt-get install $(dpkg --get-selections | grep libgl1-mesa-glx | grep amd64 | awk -F ':amd64' '{print $1}'):i386  $(dpkg --get-selections | grep libgl1-mesa-dri | grep amd64 | awk -F ':amd64' '{print $1}'):i386 libtxc-dxtn0:i386

En espérant que ça aidera !