Xfce ou KDE Plasma 5? #2

Dans le billet précédent, je parlais de mes petits soucis graphiques avec Plasma, alors j’ai trouvé le responsable de mes déboires et je met ici ce qui m’a rendu mon Plasma incassable. En faite par défaut dans Debian et sûrement chez les autres, Plasma arrive avec les effets de bureau activés et paramétrés pour utiliser la méthode mise à l’échelle précise or cette méthode n’est pas prise en charge par tous les matériels et peut provoquer des dégradations de performances et des artefacts de rendu.

Pour changer, il faut se rendre dans « configuration du système » puis descendre dans la rubrique « matériel » et aller sur « affichage et écran », dedans on va sur « compositeur » et on choisi une méthode autre que « précise », dans mon cas j’ai pris « direct ».

Voila, depuis plus aucuns soucis d’artefacts ou de bureau qui s’affichait pas.

Virtualbox, soucis avec vboxdrv

Si au démarrage d’un OS émulé sous virtualbox, celui-ci se met a pestiférer ce genre de message:

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing

‘/sbin/vboxconfig’

as root.

where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) – The support driver is not installed. On linux, open returned ENOENT.

Un simple modprobe vboxdrv en root suffira pour tout remettre dans l’ordre, a condition d’avoir installer les paquets kernel-devel.

#modprobe vboxdrv

Court mais efficace.

Ce que je fais après l’installation de ma Debian #2

Depuis le dernier billet parlant de mon installation de debian, j’ai remarqué des oublis, et comme annoncé a la fin du billet, je vais écrire ici certains manques. Pourquoi pas sur le précédent, simplement que j’ai peur que ça passe a la trappe.

J’avais oublié l’étape qui permet de rendre les applications GTK mieux intégrés dans KDE:

Donc dans une console:
 # apt-get install kde-config-gtk-style gtk2-engines-oxygen gtk3-engines-oxygen

Je rassemblerais les différents billets, car d’autres vont suivre, sur une seule page.

Ce que je fais après l’installation de ma Debian

J’aime bien lire les blogs de mes compatriotes, généralement je lis surtout ce qui touche a linux et le logiciel libre. Je voulais faire ce billet depuis quelque temps, en faite depuis que Gilles a posté le sien sur son blog.

Il commence par:

Comme souvent en ce moment, j’ai installé la dernière version d’Ubuntu : la 16.04 LTS (Long Term Support), appelée Xenial Xerus. Comme ma dernière liste d’installation date un peu et que j’ai changé d’ordinateur, je remets ici pour mémoire ce que j’ai fait après l’installation de base.

Alors avec debian je n’ai pas autant de raison de réinstaller, en effet les sorties d’une stable c’est tout les deux ans alors qu’ubuntu c’est tout les 6mois, a part si on installe que les LTS d’ubuntu et la ça revient au même qu’une debian. Bref, ça n’empêche pas que le temps fait que j’oublie certaine pratique, que je dois ensuite regarder sur ce blog pour trouver les différents penses bête et ensuite les mettre en pratique. Il est peut être temps que je récapitule dans un seul billet les principales actions que je fais a chaque nouvelle debian.

Pour l’installation, je ne change pas, je prend normalement une net-install ou un DVD d’installation si je sais que je dois en installer plusieurs. Normalement je ne prend que le Amd64 mais j’ai encore deux vieux coucous en i386. Ensuite je lance l’installation, je suis les étapes que je connais par cœur depuis le temps. C’est simple, rapide et comme Debian nous habitue a ne pas changer pour changer, on est pas surpris par cette installation.

Continuer la lecture de « Ce que je fais après l’installation de ma Debian »

Ma debian grossit, vite au régime.

https://i0.wp.com/download.tuxfamily.org/passionlinux/IMG/png/10png-a2d700a2d7.png?w=840

Aujourd’hui, je vais parler de ce qui arrive quand on utilise une debian sid ou simplement une stable upgrader de version en version(4->5->6->7->8->…), au fil des mises a jour ou des installations de programmes, celle-ci prend du poids. C’est moins vrai si on part d’une stable propre c’est a dire d’une installation fraîche a chaque release.

Ce qui se passe, c’est simple, les paquets téléchargés sont gardé dans le cache de apt, pour être en cas de réinstallation des paquets, être installé plus rapidement et au passage, économiser de la bande passante aux dépôts, a condition de ne pas avoir une version plus récente dans les dépôts ; ou simplement revenir a une version plus vieille, utile sous sid. Cette base peut devenir vraiment très grosse sur une sid… Sous debian, il y a deux types de cache, le cache des paquets viables, encore présent dans les dépôts (même version) et celui des paquets obsolètes qui sont dans une version plus récente dans les dépôts notamment les paquets qui ont eu des mises a jour. Sur ma stable j’avais 4.6go de cache, 2.4go de cache des versions obsolètes et 2.2go de paquets pressent dans la même version dans les dépôts

Ce qui suit vient de la documentation de debian-facile.

Continuer la lecture de « Ma debian grossit, vite au régime. »

Activer le Multiarch sous debian

Qu’est ce que Multi-arch ?

Multi-arch vous permet d’installer des bibliothèque de paquets venant de différentes architectures sur un même système. C’est très utile dans beaucoup de cas, cela permet le plus souvent d’installer à la fois des logiciels 32 et 64 bits sur la même machine, tout en conservant une résolution des dépendances automatique correcte. Notez que cela ne permet pas d’installer simultanément plusieurs versions d’une même « application » dans de multiples architectures.

Concepts

Il y a une architecture dite architecture courante, et affichée par la commande dpkg --print-architecture. Elle est définie dans le paquet dpkg actuellement installé.

(Notez qu’ici « architecture » désigne une Interface Binaire-Programme (ABI, Application Binary Interface), et non une Architecture de Jeu d’Instruction (ISA, Instruction Set Architecture). Ainsi, par exemple, « armel » et « armhf » sont bien des « architectures » différentes car, bien qu’elles utilisent (presque) le même jeu d’instruction, elles se reposent sur des ABI différentes pour l’appel de fonctions depuis les bibliothèques.

Il est maintenant possible de se référer à un paquet via « paquet:architecture » à peu près partout où il était possible de le faire avant avec « paquet » — nous avons donc libc:i386 et libc:amd64 — malheureusement, les sémantiques comprises par dpkg et apt étant légèrement différentes, les résultats obtenus via ces deux interfaces peuvent être légèrement différents. Cependant, préciser l’architecture d’un paquet devrait toujours être sûr et sans ambigüité, quant au nom « paquet » sans précision, il se réfère au paquet dans l’architecture courante d’apt.

Les autres architectures disponibles sont visibles grâce à la commande dpkg --print-foreign-architectures. Dpkg gèrera les paquets de ces architectures ainsi que ceux de l’architecture de la machine.

Il y a un entête « Multi-Arch » inscrit dans les méta-données pour chaque paquet multi-architectures concerné.

Les paquets existants fonctionnent très bien dans un environnement multi-architectures, mais pour bénéficier d’une co-installation ou d’un arbre de dépendances multi-architectures, beaucoup de paquets ont besoin d’être rendus compatibles en multi-architectures.

  • Pour un paquet inchangé vous pouvez choisir quelle version d’architecture du paquet vous souhaitez installer (par exemple, « amd64 » ou « i386 »).
  • Si un paquet est étiqueté « Multi-Arch: foreign », alors il peut satisfaire la dépendance d’un paquet d’une architecture différente (par exemple, « make:amd64 » permettra de satisfaire une dépendance faite pour un paquet de n’importe quelle architecture).
  • Pour activer plus d’une version d’architecture d’un paquet en même temps (généralement les librairies et les paquets dev-) les fichiers ont besoin d’être déplacés pour ne pas avoir de conflit. Ces paquets sont eux aussi tagués « Multi-Arch: same ».

Des paquets étiquetés « Multi-Arch : allowed » existent aussi. Ils peuvent être traités à la fois comme « :same » ou comme « :foreign » en fonction des paquets dont ils dépendent.

Le plus souvent, les responsables des paquets travaillent sur leur distribution en commençant par installer les paquets les plus utiles pour la rendre multi-architectures. Voir multiarch spec et howto implementation pour avoir des détails sur le fonctionnement actuel et pour savoir comment mettre à jour les paquets et tirer avantage de cette fonctionnalité.

Continuer la lecture de « Activer le Multiarch sous debian »

Firmware manquant pendant l’installation de debian.

Le mot firmware, qui peut être traduit par le terme microcode (ou microprogramme), fait référence à un programme intégré qui contrôle des périphériques électroniques. Il n’y a pas de frontières précises entre microprogramme et programme dans la mesure où les deux termes recouvrent parfois des codes similaires. Habituellement, le terme microcode (firmware) désigne un programme qui se charge des opérations de bas niveau dans un périphérique, sans lesquels le périphérique ne pourrait fonctionner… (pour en savoir plus Wikipedia).

Microcodes, Périphériques et Pilotes

 

De nombreux périphériques ont besoin d’un microcode pour fonctionner. Historiquement, les microcodes étaient incorporés à la ROM ou à la mémoire flash des périphériques, mais, de plus en plus souvent, ils doivent être chargés dans le périphérique par le pilote au moment de leur mise en route. Certains de ces microcodes sont libres et open-source, mais d’autres non ce qui fait que vous devez ajouter les sources non-free et contrib à votre fichier /etc/apt/sources.list ; voir sources.list(5) et Debian archive basics (Debian Reference) pour des informations complémentaires.

Continuer la lecture de « Firmware manquant pendant l’installation de debian. »

HTACCESS : Quelques infos…

Introduction :

Un petit topo rapide sur les fichiers .htaccess
Les fichiers .htaccess sont des fichiers de configuration des serveurs HTTP Apache. Leur particularité est leur emplacement : dans les répertoires de données du site Web, au lieu du répertoire de configuration d’Apache. La portée de leur configuration est limitée au contenu du répertoire où ils résident. Cette particularité apporte deux principaux avantages : leur gestion peut être déléguée à des utilisateurs n’ayant pas le droit de gérer le serveur HTTP lui-même ; les modifications sont prises en compte sans qu’il soit nécessaire de redémarrer le serveur HTTP.

Les fichiers .htaccess sont notamment utilisés pour configurer des droits d’accès, des redirections d’URL, des messages d’erreur personnalisés, et des associations d’extension de nom de fichier à un type MIME.

  

Quelques lignes rapides

Rediriger une URL de manière permanente

Code HTML :
Redirect permanent /news/news-6-13+linuxien-decouvre-windows-7.php /news/0-root/13-linuxien-decouvre-windows-7/

Et pour un changement de nom de domaine, si on veut récupérer la suite d’une URL (exemple linuxtricks.asso-linux-online.fr/truc-bidule pour pointer sur inuxtricks.fr/truc-bidule ) On place le .htaccess sur l’ancien site (linuxtricks.asso-linux-online.fr) avec ceci dedans :

Code HTML :
RedirectMatch 301 /(.*) http://linuxtricks.fr/$1

Ces modifs sont prises en compte par les moteurs de recherche et mettent à jour leur base de données.

Redirection temporaire

Code HTML :
Redirect temp / /maintenance.html

Ces modifs ne sont pas prises en compte par les moteurs de recherche.

Pages d’erreur personnalisées

Code HTML :

ErrorDocument 403 /intrdit.html
ErrorDocument 404 /erreur.html

Supprimer l’extension .php

Si on veut que l’URL /truc appelle /truc.php voici ce qu’il faut mettre dans le htaccess :

Code HTML :

RewriteEngine on
RewriteRule ^([^.]+)$ $1.php [NC]

Créer un fichier .htaccess sous Windows

Ouvrir cmd et se rende dans le dossier du site :

Code BASH :
cd C:....

Puis créer le fichier ainsi :

Code BASH :
echo >.htaccess

Voir en ligne : HTACCESS : Quelques infos… 

Merci a Adrien.D de me permettre de copier intégralement son article sur Linuxtricks selon les termes : Licence Creative Commons CC by SA

Activer le nettoyage automatique de /tmp sur une openSUSE

    Pour activer le nettoyage automatique de /tmp :

  1. Copier /usr/lib/tmpfiles.d/tmp.conf dans /etc/tmpfiles.d/
  2. Modifier /etc/tmpfiles.d/tmp.conf pour les dossiers /tmp et /var/tmp au niveau des lignes :
    Code :
    v /tmp 1777 root root 10d
    v /var/tmp 1777 root root 30d

    (Note : ne pas modifier la première lettre, ce n’est pas forcément v,
    ça peut être d par exemple, mais modifier le dernier champ des deux
    lignes : « – » → « 10d » pour activer le nettoyage pour les fichiers de + 10
    jours par exemple)

  3. Vérifier que systemd-tmpfiles-clean.timer est bien lancé :
    Code :
    antoine@antoine-laptop : > systemctl list-timers NEXT                          LEFT     LAST                          PASSED    UNIT                         ACTIVATES lun. 2015-12-07 00:00:00 CET  22h left dim. 2015-12-06 01:39:54 CET  12min ago logrotate.timer              logrotate.service lun. 2015-12-07 01:52:27 CET  23h left dim. 2015-12-06 01:52:27 CET  13s ago   systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
    
    2 timers listed.
    Pass —all to see loaded but inactive timers, too.
    antoine@antoine-laptop : >

     

Un grand merci a Antoine sur Alionet

Voir en ligne : alionet

Créez une clé bootable

    Merci a Tnut

Si vous êtes déjà sous GNU/Linux :

[Important]En root

A l’aide de fdisk, déterminez où se trouve votre clé USB :

fdisk -l

A l’aide de dd, créez votre clé bootable :

dd if=NuTyX_x86_64-saravane-14.11.iso of=/dev/sdX

La valeur sdX est donnée par la commande :

fdisk -l

Si vous êtes sous Windows :

Utilisez votre outils de gravure favori pour graver l’iso sur un CD-RW (si possible) …