Après faut être plus malin : utiliser une techno qui ne permet pas de faire de double mot de passe (Luks ne le permet pas ?), et s'assurer de n'utiliser qu'une portion, au début, de la partition cryptée.
Et puis on fait pareil, dans le même fichier, mais avec un offset.
Par exemple tu as une partition cryptée de 2Go, tu en remplis environ 500Mo, et à l'offset 1Go ou 1,5Go, tu recrées une autre partition chiffrée de la même manière.
Faut faire gaffe : tu as un risque de flinguer la seconde partition en utilisant la première. Et puis c'est théorique, ça peut très bien ne pas fonctionner du tout à cause de la façon dont luks chiffre sa partition.
Mais si luks chiffre le fichier entier, tu peux malgré tout peut-être créer ta sous-partition à un offset donné de ton device loop, si luks chiffre le device il chiffrera ce qui est caché dedans, et il te faut donc les deux mots de passe en cascade. Monter et déchiffrer le premier pour avoir accès au second.
L'idée c'est que sous la contrainte tu donnes le mot de passe numéro 1, qui déchiffre effectivement ton coffre-fort, la contrainte disparaît, tu as cédé, tout donné, mais il en manque en réalité une partie disponible uniquement si on a déchiffré avec le second mot de passe.
Tu es propre de ton côté : tu as cédé, mais le type qui te contraignait n'a pas trouvé ce qu'il cherchait et en conclus que ce n'est pas là que ça se trouve.
Donc tu as cédé, mais pas tout, pas le principal.
Et a priori personne ne le sait, donc la contrainte ne devrait pas reprendre.
Oui, c'était un abus de langage, valable pour la grande majorité des cas, et tu as raison.
Bon, la solution GoboLinux qui fait des liens dans l'archi classique /usr /lib etc, ça a l'air un poil bourrin, et pas aussi souple puisqu'il faut un outil pour gérer ces liens. Je préfère, à choisir, une approche en filesystem d'union, mélanger des archives, ou des répertoires, dans une arborescence unique.
Plus élégant on va dire.
D'accord !
C'est super intéressant, ça donne un FS de base bien plus clair, et sans risque d'avoir des fichiers qui traînent.
C'est souvent la question que je me pose sous Linux : j'ai tout mes paquets installés proprement et tout, mais s'il y avait par erreur, hasard, bug, ou autre, des fichiers qui traînent de versions antérieures, comment je les trouverais ?
Sous Haiku cette question ne se pose pas, et basculer de version d'un logiciel se fait en deux secondes si tu as les deux versions du paquet sur ton disque.
De plus ils sont plus difficiles à modifier à ton insu.
Ça donne envie d'essayer Haiku tout ça…
Tu sais, si personne ne t'aime, c'est peut-être un peu de ta faute aussi.
Et même si il existe de nombreux lieux où la bêtise est dressée sur un piédestal et érigée au rang de vertu… Ben pas ici, désolé de te décevoir.
Ah, c'est pas mal !
Mais du coup, une bibliothèque partagée va être dans un package compressé, ça gère comment les liens ?
Il maintient une liste virtuelle des fichiers, ou alors le chemin de la lib inclus le nom du package ?
Et question à la con, mais si tu veux par exemple utiliser l'icône d'un paquet donné dans un outil à toi, comme au pif un menu de sélection de navigateur web avec les icônes dedans. Tu y accèdes comment ? Il y a une facilité, type montage virtuel du fichier compressé (genre AVFS ou un pseudo-fs à-la-FUSE ?)
Bah la compression sert en général à prendre - beaucoup - moins de bande passante, donc à avoir un téléchargement beaucoup plus rapide.
Mais ce que tu veux dire c'est que pour une mise à jour d'un logiciel ça ne récupère que les fichiers modifiés en laissant en place tout ce qui ne bouge pas ? Donc un gain par rapport à télécharger la nouvelle version toute entière, virer toute l'ancienne, mettre la nouvelle à la place, avec 95% des fichiers remplacés par eux-même ?
C'est une approche qui peut être pertinente pour des gros logiciels ou des jeux, mais pas pour des bibliothèques comme presque tout est binaire, presque tout est remplacé à chaque fois.
Et puis tout nettoyer et remettre au propre à aussi un certaine avantage de fiabilité face à une corruption d'un fichier d'un paquet, même si tu le remplaces par lui-même, s'il a été altéré sur ta machine (ça arrive, même sans virus ou fausse manip, on parle d'informatique quand même c'est de la magie et c'est chaotique) il sera remis au propre à la mise à jour.
Et puis c'est censé à terme remplacer Gecko non ?
Comme Blink par rapport à Webkit.
Et c'est la même équipe qui est à la base, donc même si le langage change, la culture restera la même, il devrait y avoir de grosses similitudes comportementales entre Gecko et Servo (ce qui n'est pas un mal, Gecko marche plutôt bien).
Ça fait que des moteurs y'en a de moins en moins sur desktop en fait puisque Opera est passé à Webkit.
Et donc en gros il y a Netsurf en plus de Gecko et Webkit (et Trident, d'accord).
Donc une seule alternative non über-bloatée, mais forcément pas encore au niveau.
Webkit bouffe tout, c'est triste un peu :(
La réponse tient à 90% en un seul mot : le web.
Plus précisément, le logiciel qui va te pomper tes 4Go de RAM, en cascade parce qu'il génère du travail dans les couches inférieures et par exemple va aussi accroître la RAM pompée par ton serveur X, c'est le navigateur internet.
Sans lui, tes 4Go sont inutiles.
Il peut y avoir des jeux qui pompent autant de ressources aussi, mais là personne ne niera les avancées énormes en terme de rendu et de puissance déployée pour en mettre plein la vue, mais comme c'est l'un des objectifs du jeu vidéo, c'est non critiquable.
Et dans un autre cas d'utilisation il y a les serveurs, qui peuvent utiliser des tonnes de RAM aussi, pour répondre plus vite et mieux. Typiquement un serveur de base de donnée, s'il gère 40Go de data, va répondre plus vite (a priori, dans le cas général bien sûr) avec 16Go de RAM qu'avec 128Mo.
Mais pour l'utilisateur desktop standard, toute ta réponse est à chercher dans le brouteur !
Et si tu veux faire tourner un brouteur modernement bloaté avec ses extensions indispensables, même sur Haiku, il continuera à te pomper des Go de RAM quand tu auras tes faceboucs, goggles mail, twitteur, et trois-cent trente quatre onglet et demi d'ouverts en parallèle dans dix-sept fenêtres différentes.
Maintenant tu as aussi d'autres couches modernement bloatées, inutile de nier qu'un Gnome ou un KDE pompe plus qu'il y a 15 ans, mais rien ne t'oblige à les utiliser pour profiter malgré tout à 100% des capacités de ta machine : l'apport est ergonomique pas fonctionnel (ergo ça unifie et simplifie ton utilisation, mais tu peux faire la même chose sans, avec d'autres moyens, moins intégrés, moins unifiés, en tout cas c'est leur objectif à Gnome et KDE).
Mais le brouteur, c'est devenu le cœur de l'utilisation, le vrai cœur de la machine, et c'est ça qui déglingue tes ressources à grands coups de Go, et de Ghz.
Et après une étude sérieuse digne des méthodes de la RACHE, il n'y a pas de différence significative (20% de ressources en plus ou en moins ne sont pas significatifs quand on parle de l'ordre de grandeur en Go de RAM) entre Firefox, Chrome, ou n'importe quel autre brouteur utilisant l'un des gros moteurs webs (Gecko, webkit, opéra…), pour avoir plus léger il faut taper dans des moteurs alternatifs, genre Vivaldi pour n'en citer qu'un.
Et ça restera malgré tout le gros point lourdeur de ta machine.
Le noyau Linux lui, il tourne toujours au poil avec une quantité de RAM pitoyable, ou même un processeur tout lambin (mon exemple d'utilisation est un ARM à 400Mhz, mono-cœur, avec 128Go de RAM, déjà bien assez gros pour Linux), et tu feras même très bien tourner un serveur X dessus avec un gestionnaire de fenêtre basique (type WindowMaker pour avoir un truc utilisable malgré tout), c'est l'étape d'après qui va tout foutre en l'air : ce que tu fais tourner DANS ton serveur X.
C'est un peu comme pour tout : tu as une part d'inné et une part d'acquis.
Il y a des études qui montrent que les filles et les garçons sont inégaux face à la représentation des choses dans l'espace, du genre concevoir et s'imaginer des formes en 3d dans sa tête par exemple. Qui tendent à prouver qu'il y a dans l'inné des différences.
Après dans l'acquis il y en a incontestablement : ya qu'à voir la gueule des grandes enseignes de ventes de jouets et jeux, c'est rose et c'est bleu, les jeux n'y sont pas les mêmes dans les sections filles et garçons. Il y a donc une pression sociale, que personne ici ne niera, et dont je pense que personne ne niera le sexisme d'ailleurs, qui donnent des préférences différentes entre les deux sexes.
Ces facteurs sociaux engendrent plus que probablement des différences de goût quand plus âgés ils ont accès à tout ce qui se fait en termes de jeux vidéos.
Et un sondage très bien fait et tout à fait représentatif te montrera de fait des différences de goûts et de couleurs selon le sexe.
Tout ça parce que certaines ont deux chromosomes X et certains un chromosome Y et un seul X.
Maintenant, ces différences existantes ont une (certainement) grande part dû au sexisme de notre société. Mais ces différences existent. Est-ce sexiste de les montrer ? D'en présenter le résultat sur une sélection de jeux vidéos ?
On peut dire d'un côté que ça entretient le sexisme, et d'un autre que ça le montre et donc le dénonce, mais ici il n'y a clairement pas de volonté d'essayer de forcer le choix des filles, et de les cadrer, donc on oscillerait entre le constat neutre (tu es une fille, il est plus probable que tu trouves ton bonheur dans cette sélection de jeux) et la dénonciation anti-sexiste (notre société fait en sorte que les filles préfèrent ces jeux).
Donc sur le même principe que la compatibilité 32bits avec des bibliothèques 32bits compilées sur archi 64 bits, pour faire tourner des soft x86 sur x86_64, il faudrait un jeu de bibliothèques de compatibilité x32, et un soft x32 tournerait sur x86_64.
Bon, étant donné que mes serveurs type embarqué sont en ARM, tout de suite ça sert beaucoup moins, mais peut-être à garder en tête pour certains soft précis sur desktop/laptop.
Genre les logiciels de compression (gzip, bzip2, xz) qui n'ont pas besoin de 4Go de RAM mais font chauffer le CPU à mort, peut-être du ffmpeg aussi, et pourquoi pas un Apache en mode pre-fork, chaque processus n'ayant jamais besoin de quantité démesurée de RAM (ça doit probablement dépendre du site derrière cela-dit).
5 à 8% de gain en vitesse selon la page wikipédia, mine de rien c'est pas mal du tout !
Même X.org ne va pas monter très haut en RAM, 1Go c'est rare, faut sacrément bourriner.
C'est sympa comme idée.
Et dans le détail, il serait possible de compiler un logiciel en x32 et de le faire tourner sur une distrib x86_64 ?
Parce que pour l'ultra-optimisation, on pourrait avoir le meilleur de tout les mondes, avec les applis n'ayant jamais besoin de plus de 4Go, et pouvant profiter pleinement d'une optimisation d'utilisation du CPU, en x32, et les autres en x86_64.
Trouver dans quel paquet se trouve un fichier :
$ grep chemin/du/fichier/sans/slash/au/début *
-> Et bien sûr tout ce qu'on peut faire avec grep, genre trouver tout les paquets/fichiers dans tel répertoire, ou qui contiennent telle expression rationnelle, etc.
Plus de détails sur un paquet :
$ less paquet # au début il y a la description du paquet
Savoir ce que fait le script d'installation d'un paquet :
$ less /var/log/scripts/paquet
Savoir quels paquets ont été installés précédemment, avec les mêmes infos :
Tout pareil mais dans /var/log/removed_packages/ et /var/log/removed_scripts/
Le nom du fichier devient paquet-upgraded- si on a mis à jour, on a donc tout l'historique.
Ça peut aussi se faire avec des outils du gestionnaire de paquet, avec slackpkg par exemple et aussi pour trouver un paquet sur un dépôt distant, son contenu, quel paquet non installé contient tel fichier etc.
Là on est dans une utilisation type Debian, mais sans les fonctionnalités supplémentaires liées à dpkg/apt genre gestion des dépendances.
CVE-2015-1212 CVE-2015-1211 CVE-2015-1209 ne s'appliquent pas (failles de Google Chrome), or on parle de serveurs ici.
La CVE-2015-4003 est sur le module OZWPAN kernel 4.0.5.
Les suivantes impliquent un serveur CIFS compromis ou l'authentification CEPH, ou l'utilisation de B.A.T.M.A.N.
Les précédentes par contre… Elles permettent toutes de planter le système (DOS puis boum).
L'intérêt de les patcher est donc énorme sur un système à forte visibilité.
A peu près négligeable sur un petit serveur (l'intérêt de faire tomber un serveur dont tout le monde se fout est négligeable, alors qu'en prendre le contrôle est particulièrement utile, mais on n'a pas de failles de ce genre, heureusement).
Mais tu as tout à fait raison, on a ici des failles DOS exploitables à distance, sur du TCP ou de l'UDP, ça en fait 4 sur la période considérée, largement de quoi planter un système. À voir aussi si un firewall protège ou non, mais comme ça a l'air d'être des failles sur les protocoles, pas gagné que le firewall intervienne assez tôt… Et sinon il suffirait d'un port ouvert au public et ça passerait.
Selon l'importance du serveur, et de son besoin de disponibilité, ce n'est pas obligatoire de mettre son noyau à jour pour ces failles là. L'indisponibilité cumulée des mises à jours peut largement dépasser celle du redémarrage du serveur après une attaque (mais alors il faudra mettre à jour parce qu'on sait que quelqu'un nous a déjà attaqué sur une faille donnée, il faut la colmater). Sachant qu'il n'y a ici aucun risque de perte ou vol des données.
Ce qui ne signifie pas qu'il te reste plus de connaissances qu'à lui ;)
C'est pas faux.
Mais quand on sort ce genre de tirades, à l'évidence sans fondement précis, la stabilité de l'argumentaire dans la tirade importe assez peu ^ ^
Pour le coup, je pense que justement, fournir une configuration par défaut de qualité (dans l'ordre d'importance: commentée, sécurisée, portable/pseudo-universelle) est une des différences majeures entre les distrib. Parce que, justement, les distrib ne font que «peu» de développement (relativement à l'activité totale).
C'est un des points forts de la Slackware en fait (mais encore une fois, c'est un point fort de la Slack, ça ne veut pas dire qu'elle fait ça mieux que les autres, et que toutes les autres sont à la ramasse !).
Les fichiers de config sont standards, le plus upstream possible, mais paramétrés par défaut pour avoir le moins d'efforts à faire.
Typiquement, je n'ai jamais réussi à entrer dans la configuration de sendmail, c'est trop imbitable et à chaque fois ça m'a rebuté, mais la conf Slackware par défaut fonctionne pour un usage basique et standard, et ça franchement ça m'a toujours impressionné (ouais, ya des logiciels comme ça, je suis imperméable, et des langages, perl je n'y arrive pas typiquement). C'est d'ailleurs pour ça que quand j'ai voulu faire un truc plus avancé, plus complexe, j'ai dégagé sendmail pour des logiciels (dispos en slackbuilds : opensmtpd, dovecot) plus faciles à paramétrer.
En pratique, quand j'installe une slackware neuve, le seul paramétrage indispensable c'est de modifier la langue par défaut du système, dans un fichier de conf. Alors oui, je préférerais nettement avoir ce choix lors de l'install, et pas aller me cogner le fichier de conf à la main, mais c'est le seul.
On choisit lors de l'install les services qui seront démarrés automatiquement (ssh, apache, mysql, nfs par exemple) donc rien à faire de plus de ce côté là.
Tout le reste c'est selon l'usage : changer l'init par défaut pour démarrer X, puis choisir sa session graphique, configurer ses raccourcis claviers et son focus souris…
Et on va retrouver ça dans les slackbuilds quand ça s'avère utile ou pertinent (ce qui n'est très souvent pas le cas, par exemple pour tout les logiciels clients, il n'y a pas de config par défaut, juste des préférences utilisateur, mais cette remarque est encore une fois valable pour toutes les distribs).
Si ça peut te rassurer, on est dans le même passé alternatif
:)
J'ai(me?) le gest[…]
Oui, mal relu…
APT n'est pas le système de gestion de paquet de Debian et ses dérivés. C'est dpkg, qui est bien plus permissif et moins fragile.
Ok, je sais en plus qu'on peut bidouiller assez précisément avec les paquets .deb
A comparaison, pour installer un paquet slackware tu as besoin d'un shell, de tar et de gz/bz2/xz. Si tu as les outils de gestion de paquets de la Slack c'est plus facile (une seule commande), mais les dépendances sont les mêmes (avec dialog pour la gestion en masse).
Donc tu peux installer un paquet slackware sans gestionnaire de paquet slackware !
Après c'est plus chiant pour les gérer, mais si t'as tout pété et que tu dois réparer en plein vol ta glibc flinguée et que t'as juste ton terminal ssh ouvert, ou un disque monté en NFS sur la machine d'à côté, tu peux y arriver (il y a un tar compilé statiquement justement pour ça).
Et ouais, ça m'est arrivé (les deux cas), dans ma folle jeunesse, sur des machines en prod (mais pas professionnelle) quand j'expérimentais vraiment n'importe comment.
Donc même à faire n'importe quoi, tu ne le cassera pas le système de paquets Slackware. Tu ne peux pas. Il ne te refusera jamais d'installer, de supprimer, de mettre à jour un paquet, même si les fichiers sont tout foirés sur le disque, plus là, présents dans un autre paquet, etc.
Évidemment tu peux péter ton système, mais ça c'est facile, et tu peux le faire avec n'importe quelle distrib en une ligne de shell.
Trouver dans quel paquet se trouve tel fichier ? T'as besoin de grep.
Savoir ce que contient tel paquet ? less, cat, n'importe quel lecteur de texte.
Oui, c'est roots, c'est pas forcément user-friendly (…), et si tu es allergique au shell, tu vas mourir douze fois par minute, mais c'est solide, souple, performant.
Je ne suis pas très au courant, mais y'a-t-il des failles kernel exploitables à distance ?
C'est à dire sans accès local, ou sans d'abord exploiter une faille d'un logiciel accessible (web, ssh, etc.) pour avoir l'accès local.
Si ce n'est pas le cas, l'âge du kernel n'a pas tellement d'importance en terme de sécurité.
Il est bien plus important de limiter les services accessibles et de les sécuriser convenablement : pas d'accès local => pas d'attaque locale sur le kernel, donc on se moque des failles exploitables localement.
Un serveur qui fait juste serveur de fichier par exemple, avec un Nginx, Apache, ou autre.
Ou un serveur de base de donnée, firewallé pour limiter les accès uniquement aux serveurs frontends.
On peut aussi restreindre les accès SSH à des adresses IPs données (chez soi, au boulot, depuis un autre serveur).
Aucun accès possible direct depuis l'extérieur, les failles des logiciels ne peuvent pas être exploitées…
Après, bien sûr, si ça fait tourner des dizaines de sites wordpress à la mise à jour inégale, l'accès local est rapide à chopper, et la faille kernel à exploiter. Tout dépend de l'usage.
Ouais, c'est pas comme un four à la maison ce genre de machines, je pense qu'on essaie de les faire travailler au maximum. D'où la revente à des PME, labos et autres.
Donc le calcul donne un coût maximum en électricité, et un ordre d'idée du coût réel.
On sait qu'on va parler en k€/an.
Comme quoi la pointe à 510kW donne quand même quelques infos générales…
Option de base à 15,37c€ le kWh, ça fait :
* 15,37/100/1000 €/Wh ;
* 15,37*24*365.25/100000 €/Wan
-> 1 Watt pendant un an coûte 1€347.
Les tarifs ont augmentés par rapport à vos souvenirs !
Si on fait un calcul avec heures creuses et pleines, sachant qu'il y a 8 heures creuses et 16 heures pleines, avec une consommation de 1W permanent, donc sans optimiser les heures :
(16,62*16+11,89*8)*365.25/100000 €/Wan
-> 1 Watt pendant un an coûte 1€319
A priori l'utilisation heures creuses/pleines est un poil plus rentable pour un serveur branché 24/24, mais ça change pas grand chose…
Sans compter l'abonnement bien sûr, mais comme il faut le répartir sur la consommation totale, on n'a pas assez d'information pour le prendre en compte :)
Ici en mode basique pour le super-calculateur à 510kW, ça ferait à l'année :
510000*(15,37*24*365.25/100000) = 687k€ annuels !
Je suppose que la machine consomme plus quand elle travaille effectivement que quand elle ne fait rien, si il n'y a aucun calcul ça doit baisser, donc on a ici un maximum, au tarif particuliers, qui n'est très certainement pas le tarif UPMC (mais j'avoue n'avoir aucune idée de ce qu'ils peuvent avoir comme tarif).
Concernant les paquets, tu ne comprend même pas ce que j'ai voulu écrire, tu prends le problème par ton petit bout de la lorgnette comme si j'agressais tout ce que tu crois bon dans le monde Linux !
J'ai compté les paquets pour donner une indication de la quantité de logiciels disponibles sous Slackware, et indiqué que les paquets ne sont pas découpés à la façon Debian pour donner une idée pour comparer, tes 3000 paquets doivent valoir grosso-modo les 1300 de la Slack de base.
Mais pour comprendre ça il aurait fallut que tu comprennes que je ne cherche nulle part à dénigrer les autres façon de faire ! Contrairement à toi qui continue à cracher sur une distrib que de toute évidence tu ne connais ni ne comprends…
Oui comme pas mal de chose, apparement dans ton univers statique.
Tsss, j'ai probablement oublié plus de choses en informatique que tu n'en connais, et joué avec plus de logiciels et de technos que tu ne crois qu'il en existe, s'il-te-plaît, ne parle pas de ce que tu ne connais pas…
Non, ça ne s'en passe pas, il y a plus de dérivés de Debian PARCE QUE il y a plus d'utilisateurs, mais si on regarde en proportions, ça donne quoi ?
Dérivés de Debian : 53
Dérivés de Ubuntu : 60
Dérivés de RedHat/Fedora : 44
Dérivés de Slackware : 24
Maintenant pour quelques stats d'utilisation, allons voir sur Linux Counter ici : https://www.linuxcounter.net/statistics/distributions
Et puis on va faire le rapport nombre de machines sur nombre de dérivées, pour faire rapide, sinon il faudrait les classer par famille et comparer, j'ai pas tant de temps que ça à te consacrer.
Ubuntu : 657 machines/dérivés
Debian : 509 machines/dérivés
Fedora/RH : 335 machines/dérivés
Slackware : 406 machines/dérivés
Ça donne une idée de combien d'utilisateurs (sans unité de volume) il faut pour avoir une distribution dérivée.
À l'évidence la plus facile à dériver des 4 est la Fedora, puis la Slackware, puis la Debian, puis Ubuntu en dernier.
Tu vois, les chiffres à la con, on peut leur faire dire ce qu'on veut…
Reste qu'il y aurait 16% de Linuxiens sous Slackware, quand on compte des centaines de distributions Linux. Et selon toi, ils sont tous arriérés mentaux, bravo.
Je n'ai besoin de faire ni l'un, ni l'autre. C'est de base dans la version serveur.
Ah, et il sait déjà à quelle machine te connecter, où se trouvent tes partages, quels sont les accès ?
Putain, ils sont trop forts chez Ubuntu, un vrai truc de malade…
Bref, ils ont fait quoi, packagé le logiciel et fournit une configuration par défaut ? Diantre, ça change vraiment tout ! Je veux dire, par rapport à compiler un logiciel et modifier sa configuration par défaut, c'est terrifiant…
C'est sûr, je vis dans le passé, très très loin dans le passé.
Aucun doute là-dessus, probablement même un passé alternatif, où les gens compilaient leur propre noyau Linux.
Je parle de bidouiller des fichiers de configuration pour des trucs qui auraient dû être réglés par le mainteneur de la distribution.
Mais quelle bidouille ?
Configurer un logiciel ce n'est pas de la bidouille, c'est un métier, et ça s'appelle Admin Système. Comment il fait ton mainteneur pour avoir conçu le fichier de conf dont TU as besoin, c'est un mentaliste ? C'est ton coloc ?
Non, la période pré-mobile par opposition à un environnemnet dynamique et multi-utilisateur qui change: Périph audio/écran/carte graphique usb/pcie/displayPort, audio/clavier/souris/tablet bt/unify, wifi, etc,… Gestion dynamique des interfaces dans une VM et j'en passe.
Bigre, je ne me rappelle franchement plus quand était la dernière fois que j'ai branché un truc dans une de mes machines sans que ça fonctionne directement.
Heureusement, c'est le travail du noyau Linux, qui de façon fort surprenante est commun à environ toutes les distributions GNU/Linux.
Diable, je sens venir les différences fondamentales d'architectures d'une distrib à l'autre, genre chacune doit gérer sa propre pile USB… Eh, non, attends, tout ça ce sont des logiciels libres, et ça s'échange dans tout les sens, et… Oh merde, on utilise les mêmes ! Nan, ton Scribus c'est pas le même que le mien, le tiens est packagé par un mainteneur qui fait un fichier de conf spécialement pour toi, alors que le miens, il est compilé à partir des sources officielles et packagés automagiquement, et configuré par défaut, et… ah ben c'est le même diantre, sans que moi ça s'affiche pas pareil, j'ai pas le même thème dans mon environnement de bureau, ah oui, toute la différence dans le packaging !
Mais c'est dingue ?
Tu imagines qu'elles sont construites comment les distribs ?
Parce que la dépêche écrit qu'on utilise le noyau 4.4, tu crois que c'est tout nouveau et qu'avant on était encore en 2.2 ?
La Slackware fonctionne aussi en rolling-release, des logiciels à jour, des mises à jours régulières, et le passage officiel à la 14.2 pour moi c'était sept paquets mis à jour (et là je t'écris avec Firefox 47, ça a changé par rapport à hier), et rien de fondamental qui change.
La 14.1 c'était en novembre 2013, à ce moment là il y avait wicd, mais ça a changé il y a… j'en sais trop rien en fait, mais ça fait un sacré moment, suffisamment pour que j'oublie.
Ce que tu vois écrit dans « les nouveautés » ce sont les grosses différences par rapport à la 14.1 il y a plus de deux ans et demi, pas comment les gens l'utilisent au quotidien.
C'est un peu comme de critiquer ce qui existe dans la Debian Wheezy (mai 2013) en comparant avec la Jessie (ou la Sid peut-être).
Ça n'a aucun sens au quotidien, si quelqu'un utilise la Wheezy il a de bonnes raisons pour le faire, mais ces raisons n'incluent pas un desktop récent, à jour, avec des logiciels qui n'était pas plus intéressant qu'un autre il y a trois ans, mais qui a évolué bien plus depuis.
Après les logiciels ce sont les mêmes.
La seule vraie différence c'est comment tu aimes administrer ta machine, pour le reste, ça s'utilise ou ça se configure de la même façon. Parce que les distribs ne créent pas les logiciels, elles les empaquettent.
Donc non, tu n'utiliseras pas différemment une Slackware ou une Ubuntu.
Mais tu utiliseras peut-être (sûrement) d'autres logiciels, qui eux vont s'utiliser différemment.
Franchement, je ne sais pas ce que tu t'imagines, mais redescend sur terre, soit plus pragmatique, regarde la réalité.
J'ai le gestionnaire de paquets de la Slackware en partie à cause de son absence de gestion des dépendances, mais aussi parce qu'il permet de réparer des systèmes tout pétés, que lui ne peut pas être cassé, ne peut pas t'interdire d'installer un paquet, ne t'empêche jamais de faire des conneries. Ou c'est POUR ça que je l'apprécie.
Et ça n'enlève rien de l'intérêt ou de la qualité d'APT, c'est différent.
Pourquoi ça te blesse quand je dis qu'Ubuntu offre une expérience utilisateur complète avec le moins de choix possible ? C'est bien ! C'est très bien pour découvrir et comprendre, et utiliser Linux ! C'est ce qu'il faut !
Et évidemment que rien n'empêche de changer les choix par défaut et d'aller plus loin, on parle de Linux ici, de Logiciels Libres, tu fais comme tu veux.
Le point d'accès est différent c'est tout, mais derrière, c'est tout pareil…
Tu es sur un sacré piédestal là, persuadé qu'il y a des univers de Logiciels Libres différents, auxquels un utilisateur de Slackware n'aurait pas accès.
Redescend !
Tu fais exprès de comprendre de travers, c'est agaçant…
lorsque tu as un gestionnaire de paquet performant et automatique.
Tu portes ici un jugement de valeur, en comparant les paquets Slackware et Debian/Ubuntu, et en affirmant que les second valent mieux que les premiers.
Ils sont différents, et je préfère ceux de la Slack pour un certain nombre de raisons, qui n'incluent évidement pas la gestion de dépendances.
Mais jamais je ne m'amuserais à dire que le .deb est à chier parce qu'il gère les dépendances, ça n'aurait aucun sens !
Tu peux plus facilement créer une installation minimaliste, avec strictement le nécessaire en utilisant une Debian. Sur mon dernier serveur ARM, je ne me suis même pas foulé, c'est une Slack complète, avec X/KDE et cie, totalement inutiles.
Mais c'est parce que dans sa situation précise, que l'OS prenne 1Go ou 6Go je m'en moque.
Quand je dis « Ubuntu t'offre une expérience utilisateur complète » je parle tu comportement de base, et de ce que cherchent à te donner les gens qui la maintiennent et la construisent. C'est un point positif pour Ubuntu, dans un segment plutôt large du marché.
T'as vu le nombre de "spin-off" issue de Debian/Ubuntu autant x86 qu'ARM? Ça montre bien la flexibilité de cette dernière.
On peut s'amuser à compter les dérivées de la Slackware aussi, largement plus nombreuses rapportées au nombre d'utilisateur, alors laquelle est la plus flexible ? Difficile à dire hein ? Pour chacun ça sera celle dont il a l'habitude, et c'est tout…
Ma plus vieille machine est de 2006, […] et oui, ça marche en mode serveur
Bah ouais, et la mienne, 2006 aussi, AMD Turion 64 X2 1,8Ghz, un portable, et je l'utilise avec un écran 27" full-HD, et j'utilise firefox 45.2.0 pour t'écrire ce commentaire dessus (sans flash, mais sinon tout est là), un autre brouteur (selon l'humeur, seamonkey, chrome, midori, palemoon) presque toujours à côté pour faire des tests, faire tourner un serveur apache avec une base MySQL de 2,3Go, une base Redis avec quelques millions de clés, des outils de dev, de communication (HipChat bien lourd, psi, etc.), des vidéos le midi quand je pique-nique devant mon écran, et de la musique.
Et c'est tout à fait utilisable, je dois être patient quand je réencode des vidéos 1080p vers du 480p parce que la carte vidéo est incapable de lire même le 720p sans flancher, mais je peux le faire quand même.
Alors quoi, sous prétexte que la machine est vieille je ne devrais plus l'utiliser pleinement encore aujourd'hui ? Pourquoi ça ?
Openstack et autres techno Cloud?
Je ne connais pas du tout OpenStack, comment te répondre alors ?
En « autre techno Cloud », par exemple owncloud a son slackbuild, donc ça ressemble à un problème trivial à résoudre. Il vient de me falloir à l'instant moins de deux minutes pour créer un paquet Slackware et l'installer. Pour le reste, encore une fois, je ne connais pas, mais c'est de l'admin owncloud, ça n'a pas de raison d'être fondamentalement différent d'une distrib à l'autre…
Deux minutes pour trouver cette page : http://www.hansneervoort.nl/projects/2noderac/iscsiinitiator.html qui t'expliquait déjà en 2012 comment configurer de l'ISCSI sous Slackware. Encore une fois je ne connais pas du tout, mais la portion spécifique à la Slackware semble se résumer à « wget les_sources | dé-tare && make && make install » soit rien de bien tuant, le reste c'est de l'admin ISCSI, qui n'a aucune raison d'être fondamentalement différente sous Slackware que sous autre chose…
Il faut peut-être recompiler le module noyau, et l'ajouter dans l'initrd, il faut très certainement savoir ce que l'on fait à un moment. Mais bon, configurer un Apache aussi nécessite de savoir ce que l'on fait à un moment… Ou n'importe quel logiciel serveur d'ailleurs.
Sans avoir à bidouiller?
Ah, est-ce que pour toi télécharger des sources, les compiler et les installer c'est de la bidouille ?
Si oui, on s'est mal compris depuis très très longtemps : un slackbuild c'est exactement ça : télécharger des sources, les compiler, et créer un paquet Slackware qu'on installe. Et ça c'est l'utilisation normale de la Slackware.
Et non, jamais personne n'a prétendu que c'était à la portée de tout le monde ni pensé pour tout le monde. La Slackware c'est ça, tu édites tes fichiers de conf à la main, si pour toi c'est une étape rebutante, il faut t'arrêter bien plus tôt dans la discussion, passe ton chemin, cette distribution ne te parlera jamais !
Mais je crois que ça parle à beaucoup de gens, et pas uniquement aux amateurs de Slackware.
Mais ne prétend à la flexibilité ou robustesse comme avantage de Slackware sur le reste.
Qui a parlé de flexibilité ? J'ai parlé d'une base robuste sur laquelle construire quelque chose. Et dans construire il y a « construire ».
Tu parles de la période « pré-mobiles » c'est quoi pour toi, le passage de l'admin système au clicodrôme ?
Tout se fait avec des grosses icônes ?
Diantre, ce n'est pas d'une époque plus ancienne dont tu parles, mais d'un fork dans les usages…
Et c'est moi qui suis resté dans un coin ? Sous prétexte que tu rejettes tout ce qui ne se fait pas « à-la-mobile-fashion-du-moment » ?
j'aurais vraiment BCP apprécié une réponse de messieurs "je contrôle tout ce qui se passe sur ma bécane"
Je suppose que je dois me sentir visé.
Désolé, je ne contrôle pas tout les bugs, et pas souvent les bugs kernel.
Cela dit j'en ai un avec ma carte AMD, pour le coup bien ancienne, puisque c'est une Radeon RS482M (Mobility Xpress 200).
Il y a pas mal de situations liées au passage en veille de l'écran (blank mode, ou l'éteindre ou qu'importe, tant que ça touche à la carte vidéo), ou au changement de résolution, où l'affichage part en vrille. Pas d'écran noir, mais des lignes blanches, verticales, en bordel, parfois d'autres trucs.
Le reste des symptômes c'est comme toi : tout fonctionne, en ssh depuis une autre machine tout fonctionne à la perfection, tu peux lancer des programmes sous X, lancer une vidéo tu auras le son, et il n'y a rien dans aucun log système.
J'ai une solution pratique : passer l'ordinateur en veille soft, et le rallumer.
Et là tout fonctionne.
Sans ça ? Je suppose que j'aurais changé d'ordinateur, ou peut-être que je l'utiliserais en mode VESA qui n'a pas ce soucis. Ou alors que j'aurais essayer de composer avec un vieux kernel pour avoir un vieux driver Catalyst, mais c'est franchement pas gagné ce genre de bidouilles…
Maintenant tu peux aussi, sous XFCE, essayer de désactiver tout les modes d'économies d'énergie de l'écran, ne jamais l'éteindre, ne jamais le mettre en blank, rien du tout, peut-être que ça annulera le problème, en te forçant à contrôler toi-même la gestion d'énergie, donc penser à passer manuellement en veille à chaque fois.
[^] # Re: Petite question, en parlant de ça...
Posté par Yth (Mastodon) . En réponse au journal un vrai coffre fort numérique. Évalué à 2.
Ah ben moi j'ai exposé la théorie hein…
Après faut être plus malin : utiliser une techno qui ne permet pas de faire de double mot de passe (Luks ne le permet pas ?), et s'assurer de n'utiliser qu'une portion, au début, de la partition cryptée.
Et puis on fait pareil, dans le même fichier, mais avec un offset.
Par exemple tu as une partition cryptée de 2Go, tu en remplis environ 500Mo, et à l'offset 1Go ou 1,5Go, tu recrées une autre partition chiffrée de la même manière.
Faut faire gaffe : tu as un risque de flinguer la seconde partition en utilisant la première. Et puis c'est théorique, ça peut très bien ne pas fonctionner du tout à cause de la façon dont luks chiffre sa partition.
Mais si luks chiffre le fichier entier, tu peux malgré tout peut-être créer ta sous-partition à un offset donné de ton device loop, si luks chiffre le device il chiffrera ce qui est caché dedans, et il te faut donc les deux mots de passe en cascade. Monter et déchiffrer le premier pour avoir accès au second.
Là c'est mieux caché :)
Ou alors de la stéganographie.
Yth.
[^] # Re: Petite question, en parlant de ça...
Posté par Yth (Mastodon) . En réponse au journal un vrai coffre fort numérique. Évalué à 5.
L'idée c'est que sous la contrainte tu donnes le mot de passe numéro 1, qui déchiffre effectivement ton coffre-fort, la contrainte disparaît, tu as cédé, tout donné, mais il en manque en réalité une partie disponible uniquement si on a déchiffré avec le second mot de passe.
Tu es propre de ton côté : tu as cédé, mais le type qui te contraignait n'a pas trouvé ce qu'il cherchait et en conclus que ce n'est pas là que ça se trouve.
Donc tu as cédé, mais pas tout, pas le principal.
Et a priori personne ne le sait, donc la contrainte ne devrait pas reprendre.
Yth.
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 2.
Oui, c'était un abus de langage, valable pour la grande majorité des cas, et tu as raison.
Bon, la solution GoboLinux qui fait des liens dans l'archi classique /usr /lib etc, ça a l'air un poil bourrin, et pas aussi souple puisqu'il faut un outil pour gérer ces liens. Je préfère, à choisir, une approche en filesystem d'union, mélanger des archives, ou des répertoires, dans une arborescence unique.
Plus élégant on va dire.
Yth.
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 3.
D'accord !
C'est super intéressant, ça donne un FS de base bien plus clair, et sans risque d'avoir des fichiers qui traînent.
C'est souvent la question que je me pose sous Linux : j'ai tout mes paquets installés proprement et tout, mais s'il y avait par erreur, hasard, bug, ou autre, des fichiers qui traînent de versions antérieures, comment je les trouverais ?
Sous Haiku cette question ne se pose pas, et basculer de version d'un logiciel se fait en deux secondes si tu as les deux versions du paquet sur ton disque.
De plus ils sont plus difficiles à modifier à ton insu.
Ça donne envie d'essayer Haiku tout ça…
Yth.
[^] # Re: Et ?
Posté par Yth (Mastodon) . En réponse au journal Bienvenue en Musulmanie !. Évalué à 10.
Tu sais, si personne ne t'aime, c'est peut-être un peu de ta faute aussi.
Et même si il existe de nombreux lieux où la bêtise est dressée sur un piédestal et érigée au rang de vertu… Ben pas ici, désolé de te décevoir.
Yth.
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 2.
Ah, c'est pas mal !
Mais du coup, une bibliothèque partagée va être dans un package compressé, ça gère comment les liens ?
Il maintient une liste virtuelle des fichiers, ou alors le chemin de la lib inclus le nom du package ?
Et question à la con, mais si tu veux par exemple utiliser l'icône d'un paquet donné dans un outil à toi, comme au pif un menu de sélection de navigateur web avec les icônes dedans. Tu y accèdes comment ? Il y a une facilité, type montage virtuel du fichier compressé (genre AVFS ou un pseudo-fs à-la-FUSE ?)
Yth.
[^] # Re: Comment ils font ?
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 2.
Bah la compression sert en général à prendre - beaucoup - moins de bande passante, donc à avoir un téléchargement beaucoup plus rapide.
Mais ce que tu veux dire c'est que pour une mise à jour d'un logiciel ça ne récupère que les fichiers modifiés en laissant en place tout ce qui ne bouge pas ? Donc un gain par rapport à télécharger la nouvelle version toute entière, virer toute l'ancienne, mettre la nouvelle à la place, avec 95% des fichiers remplacés par eux-même ?
C'est une approche qui peut être pertinente pour des gros logiciels ou des jeux, mais pas pour des bibliothèques comme presque tout est binaire, presque tout est remplacé à chaque fois.
Et puis tout nettoyer et remettre au propre à aussi un certaine avantage de fiabilité face à une corruption d'un fichier d'un paquet, même si tu le remplaces par lui-même, s'il a été altéré sur ta machine (ça arrive, même sans virus ou fausse manip, on parle d'informatique quand même c'est de la magie et c'est chaotique) il sera remis au propre à la mise à jour.
Ou alors je n'ai pas compris :)
Yth.
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 2.
Et puis c'est censé à terme remplacer Gecko non ?
Comme Blink par rapport à Webkit.
Et c'est la même équipe qui est à la base, donc même si le langage change, la culture restera la même, il devrait y avoir de grosses similitudes comportementales entre Gecko et Servo (ce qui n'est pas un mal, Gecko marche plutôt bien).
Yth.
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 5.
Ah fichtre, c'est la misère à suivre…
Bon, je récapépètte…
Gecko : Firefox, Icecat, Palemoon, Tor-browser, Seamonkey
Webkit/Blink : Arora, Chrome, Chromium, Dwb, Midori, Opera, Otter, Qupzilla, Rekonq, Surf, Vimb, Vivaldi, Xombrero
Netsurf
Dillo
Amaya
texte : elinks/links/lynx/w3m
Ça fait que des moteurs y'en a de moins en moins sur desktop en fait puisque Opera est passé à Webkit.
Et donc en gros il y a Netsurf en plus de Gecko et Webkit (et Trident, d'accord).
Donc une seule alternative non über-bloatée, mais forcément pas encore au niveau.
Webkit bouffe tout, c'est triste un peu :(
Yth.
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 4. Dernière modification le 24 août 2016 à 11:44.
Oui, pardon ^^
Tellement plus l'habitude d'utiliser des Mo de nos jours, c'est « so XXème siècle » le Mo…
Ahem :)
Yth.
[^] # Re: Toutes ces années de dev
Posté par Yth (Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 10.
La réponse tient à 90% en un seul mot : le web.
Plus précisément, le logiciel qui va te pomper tes 4Go de RAM, en cascade parce qu'il génère du travail dans les couches inférieures et par exemple va aussi accroître la RAM pompée par ton serveur X, c'est le navigateur internet.
Sans lui, tes 4Go sont inutiles.
Il peut y avoir des jeux qui pompent autant de ressources aussi, mais là personne ne niera les avancées énormes en terme de rendu et de puissance déployée pour en mettre plein la vue, mais comme c'est l'un des objectifs du jeu vidéo, c'est non critiquable.
Et dans un autre cas d'utilisation il y a les serveurs, qui peuvent utiliser des tonnes de RAM aussi, pour répondre plus vite et mieux. Typiquement un serveur de base de donnée, s'il gère 40Go de data, va répondre plus vite (a priori, dans le cas général bien sûr) avec 16Go de RAM qu'avec 128Mo.
Mais pour l'utilisateur desktop standard, toute ta réponse est à chercher dans le brouteur !
Et si tu veux faire tourner un brouteur modernement bloaté avec ses extensions indispensables, même sur Haiku, il continuera à te pomper des Go de RAM quand tu auras tes faceboucs, goggles mail, twitteur, et trois-cent trente quatre onglet et demi d'ouverts en parallèle dans dix-sept fenêtres différentes.
Maintenant tu as aussi d'autres couches modernement bloatées, inutile de nier qu'un Gnome ou un KDE pompe plus qu'il y a 15 ans, mais rien ne t'oblige à les utiliser pour profiter malgré tout à 100% des capacités de ta machine : l'apport est ergonomique pas fonctionnel (ergo ça unifie et simplifie ton utilisation, mais tu peux faire la même chose sans, avec d'autres moyens, moins intégrés, moins unifiés, en tout cas c'est leur objectif à Gnome et KDE).
Mais le brouteur, c'est devenu le cœur de l'utilisation, le vrai cœur de la machine, et c'est ça qui déglingue tes ressources à grands coups de Go, et de Ghz.
Et après une étude sérieuse digne des méthodes de la RACHE, il n'y a pas de différence significative (20% de ressources en plus ou en moins ne sont pas significatifs quand on parle de l'ordre de grandeur en Go de RAM) entre Firefox, Chrome, ou n'importe quel autre brouteur utilisant l'un des gros moteurs webs (Gecko, webkit, opéra…), pour avoir plus léger il faut taper dans des moteurs alternatifs, genre Vivaldi pour n'en citer qu'un.
Et ça restera malgré tout le gros point lourdeur de ta machine.
Le noyau Linux lui, il tourne toujours au poil avec une quantité de RAM pitoyable, ou même un processeur tout lambin (mon exemple d'utilisation est un ARM à 400Mhz, mono-cœur, avec 128Go de RAM, déjà bien assez gros pour Linux), et tu feras même très bien tourner un serveur X dessus avec un gestionnaire de fenêtre basique (type WindowMaker pour avoir un truc utilisable malgré tout), c'est l'étape d'après qui va tout foutre en l'air : ce que tu fais tourner DANS ton serveur X.
Yth.
[^] # Re: Tiptop le sexisme
Posté par Yth (Mastodon) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 10.
C'est un peu comme pour tout : tu as une part d'inné et une part d'acquis.
Il y a des études qui montrent que les filles et les garçons sont inégaux face à la représentation des choses dans l'espace, du genre concevoir et s'imaginer des formes en 3d dans sa tête par exemple. Qui tendent à prouver qu'il y a dans l'inné des différences.
Après dans l'acquis il y en a incontestablement : ya qu'à voir la gueule des grandes enseignes de ventes de jouets et jeux, c'est rose et c'est bleu, les jeux n'y sont pas les mêmes dans les sections filles et garçons. Il y a donc une pression sociale, que personne ici ne niera, et dont je pense que personne ne niera le sexisme d'ailleurs, qui donnent des préférences différentes entre les deux sexes.
Ces facteurs sociaux engendrent plus que probablement des différences de goût quand plus âgés ils ont accès à tout ce qui se fait en termes de jeux vidéos.
Et un sondage très bien fait et tout à fait représentatif te montrera de fait des différences de goûts et de couleurs selon le sexe.
Tout ça parce que certaines ont deux chromosomes X et certains un chromosome Y et un seul X.
Maintenant, ces différences existantes ont une (certainement) grande part dû au sexisme de notre société. Mais ces différences existent. Est-ce sexiste de les montrer ? D'en présenter le résultat sur une sélection de jeux vidéos ?
On peut dire d'un côté que ça entretient le sexisme, et d'un autre que ça le montre et donc le dénonce, mais ici il n'y a clairement pas de volonté d'essayer de forcer le choix des filles, et de les cadrer, donc on oscillerait entre le constat neutre (tu es une fille, il est plus probable que tu trouves ton bonheur dans cette sélection de jeux) et la dénonciation anti-sexiste (notre société fait en sorte que les filles préfèrent ces jeux).
Yth.
[^] # Re: Client mobile et desktop
Posté par Yth (Mastodon) . En réponse à la dépêche Movim 0.10 - Holmes. Évalué à 3.
Ah bon ?
Ya des gens qui utilisent iOS ?
C'est qui ?
Yth…
[^] # Re: x32
Posté par Yth (Mastodon) . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
Donc sur le même principe que la compatibilité 32bits avec des bibliothèques 32bits compilées sur archi 64 bits, pour faire tourner des soft x86 sur x86_64, il faudrait un jeu de bibliothèques de compatibilité x32, et un soft x32 tournerait sur x86_64.
Bon, étant donné que mes serveurs type embarqué sont en ARM, tout de suite ça sert beaucoup moins, mais peut-être à garder en tête pour certains soft précis sur desktop/laptop.
Genre les logiciels de compression (gzip, bzip2, xz) qui n'ont pas besoin de 4Go de RAM mais font chauffer le CPU à mort, peut-être du ffmpeg aussi, et pourquoi pas un Apache en mode pre-fork, chaque processus n'ayant jamais besoin de quantité démesurée de RAM (ça doit probablement dépendre du site derrière cela-dit).
5 à 8% de gain en vitesse selon la page wikipédia, mine de rien c'est pas mal du tout !
Même X.org ne va pas monter très haut en RAM, 1Go c'est rare, faut sacrément bourriner.
Bref, c'est intéressant.
Yth.
[^] # Re: x32
Posté par Yth (Mastodon) . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
C'est sympa comme idée.
Et dans le détail, il serait possible de compiler un logiciel en x32 et de le faire tourner sur une distrib x86_64 ?
Parce que pour l'ultra-optimisation, on pourrait avoir le meilleur de tout les mondes, avec les applis n'ayant jamais besoin de plus de 4Go, et pouvant profiter pleinement d'une optimisation d'utilisation du CPU, en x32, et les autres en x86_64.
Yth.
[^] # Re: ip over pigeons
Posté par Yth (Mastodon) . En réponse au journal #LaDictatureQuiVient Wi-Fi interdit, Tor bloqué, backdoors… les nouvelles idées au gouvernement. Évalué à 4.
C'est triste ton avis sur les pigeons…
Ils mettent bien moins d'un mois à traverser en long en large et en travers la France entière !
Yth.
[^] # Re: Slackwariens/puristes complètement déconnectés de la réalité
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 4.
cd /var/log/packages/
Voir le contenu d'un paquet :
$ less paquet
Trouver dans quel paquet se trouve un fichier :
$ grep chemin/du/fichier/sans/slash/au/début *
-> Et bien sûr tout ce qu'on peut faire avec grep, genre trouver tout les paquets/fichiers dans tel répertoire, ou qui contiennent telle expression rationnelle, etc.
Plus de détails sur un paquet :
$ less paquet # au début il y a la description du paquet
Savoir ce que fait le script d'installation d'un paquet :
$ less /var/log/scripts/paquet
Savoir quels paquets ont été installés précédemment, avec les mêmes infos :
Tout pareil mais dans /var/log/removed_packages/ et /var/log/removed_scripts/
Le nom du fichier devient paquet-upgraded- si on a mis à jour, on a donc tout l'historique.
Ça peut aussi se faire avec des outils du gestionnaire de paquet, avec slackpkg par exemple et aussi pour trouver un paquet sur un dépôt distant, son contenu, quel paquet non installé contient tel fichier etc.
Là on est dans une utilisation type Debian, mais sans les fonctionnalités supplémentaires liées à dpkg/apt genre gestion des dépendances.
Yth.
[^] # Re: Slackware, oui, mais avec respect pour les autres distributions/logiciels ?
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 2.
CVE-2015-1212 CVE-2015-1211 CVE-2015-1209 ne s'appliquent pas (failles de Google Chrome), or on parle de serveurs ici.
La CVE-2015-4003 est sur le module OZWPAN kernel 4.0.5.
Les suivantes impliquent un serveur CIFS compromis ou l'authentification CEPH, ou l'utilisation de B.A.T.M.A.N.
Les précédentes par contre… Elles permettent toutes de planter le système (DOS puis boum).
L'intérêt de les patcher est donc énorme sur un système à forte visibilité.
A peu près négligeable sur un petit serveur (l'intérêt de faire tomber un serveur dont tout le monde se fout est négligeable, alors qu'en prendre le contrôle est particulièrement utile, mais on n'a pas de failles de ce genre, heureusement).
Mais tu as tout à fait raison, on a ici des failles DOS exploitables à distance, sur du TCP ou de l'UDP, ça en fait 4 sur la période considérée, largement de quoi planter un système. À voir aussi si un firewall protège ou non, mais comme ça a l'air d'être des failles sur les protocoles, pas gagné que le firewall intervienne assez tôt… Et sinon il suffirait d'un port ouvert au public et ça passerait.
Selon l'importance du serveur, et de son besoin de disponibilité, ce n'est pas obligatoire de mettre son noyau à jour pour ces failles là. L'indisponibilité cumulée des mises à jours peut largement dépasser celle du redémarrage du serveur après une attaque (mais alors il faudra mettre à jour parce qu'on sait que quelqu'un nous a déjà attaqué sur une faille donnée, il faut la colmater). Sachant qu'il n'y a ici aucun risque de perte ou vol des données.
Yth.
[^] # Re: Slackwariens/puristes complètement déconnectés de la réalité
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 2.
Je ne vais pas répondre à tout hein :)
C'est pas faux.
Mais quand on sort ce genre de tirades, à l'évidence sans fondement précis, la stabilité de l'argumentaire dans la tirade importe assez peu ^ ^
C'est un des points forts de la Slackware en fait (mais encore une fois, c'est un point fort de la Slack, ça ne veut pas dire qu'elle fait ça mieux que les autres, et que toutes les autres sont à la ramasse !).
Les fichiers de config sont standards, le plus upstream possible, mais paramétrés par défaut pour avoir le moins d'efforts à faire.
Typiquement, je n'ai jamais réussi à entrer dans la configuration de sendmail, c'est trop imbitable et à chaque fois ça m'a rebuté, mais la conf Slackware par défaut fonctionne pour un usage basique et standard, et ça franchement ça m'a toujours impressionné (ouais, ya des logiciels comme ça, je suis imperméable, et des langages, perl je n'y arrive pas typiquement). C'est d'ailleurs pour ça que quand j'ai voulu faire un truc plus avancé, plus complexe, j'ai dégagé sendmail pour des logiciels (dispos en slackbuilds : opensmtpd, dovecot) plus faciles à paramétrer.
En pratique, quand j'installe une slackware neuve, le seul paramétrage indispensable c'est de modifier la langue par défaut du système, dans un fichier de conf. Alors oui, je préférerais nettement avoir ce choix lors de l'install, et pas aller me cogner le fichier de conf à la main, mais c'est le seul.
On choisit lors de l'install les services qui seront démarrés automatiquement (ssh, apache, mysql, nfs par exemple) donc rien à faire de plus de ce côté là.
Tout le reste c'est selon l'usage : changer l'init par défaut pour démarrer X, puis choisir sa session graphique, configurer ses raccourcis claviers et son focus souris…
Et on va retrouver ça dans les slackbuilds quand ça s'avère utile ou pertinent (ce qui n'est très souvent pas le cas, par exemple pour tout les logiciels clients, il n'y a pas de config par défaut, juste des préférences utilisateur, mais cette remarque est encore une fois valable pour toutes les distribs).
:)
Oui, mal relu…
Ok, je sais en plus qu'on peut bidouiller assez précisément avec les paquets .deb
A comparaison, pour installer un paquet slackware tu as besoin d'un shell, de tar et de gz/bz2/xz. Si tu as les outils de gestion de paquets de la Slack c'est plus facile (une seule commande), mais les dépendances sont les mêmes (avec dialog pour la gestion en masse).
Donc tu peux installer un paquet slackware sans gestionnaire de paquet slackware !
Après c'est plus chiant pour les gérer, mais si t'as tout pété et que tu dois réparer en plein vol ta glibc flinguée et que t'as juste ton terminal ssh ouvert, ou un disque monté en NFS sur la machine d'à côté, tu peux y arriver (il y a un tar compilé statiquement justement pour ça).
Et ouais, ça m'est arrivé (les deux cas), dans ma folle jeunesse, sur des machines en prod (mais pas professionnelle) quand j'expérimentais vraiment n'importe comment.
Donc même à faire n'importe quoi, tu ne le cassera pas le système de paquets Slackware. Tu ne peux pas. Il ne te refusera jamais d'installer, de supprimer, de mettre à jour un paquet, même si les fichiers sont tout foirés sur le disque, plus là, présents dans un autre paquet, etc.
Évidemment tu peux péter ton système, mais ça c'est facile, et tu peux le faire avec n'importe quelle distrib en une ligne de shell.
Trouver dans quel paquet se trouve tel fichier ? T'as besoin de grep.
Savoir ce que contient tel paquet ? less, cat, n'importe quel lecteur de texte.
Oui, c'est roots, c'est pas forcément user-friendly (…), et si tu es allergique au shell, tu vas mourir douze fois par minute, mais c'est solide, souple, performant.
Yth.
[^] # Re: Slackware, oui, mais avec respect pour les autres distributions/logiciels ?
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 2.
Je ne suis pas très au courant, mais y'a-t-il des failles kernel exploitables à distance ?
C'est à dire sans accès local, ou sans d'abord exploiter une faille d'un logiciel accessible (web, ssh, etc.) pour avoir l'accès local.
Si ce n'est pas le cas, l'âge du kernel n'a pas tellement d'importance en terme de sécurité.
Il est bien plus important de limiter les services accessibles et de les sécuriser convenablement : pas d'accès local => pas d'attaque locale sur le kernel, donc on se moque des failles exploitables localement.
Un serveur qui fait juste serveur de fichier par exemple, avec un Nginx, Apache, ou autre.
Ou un serveur de base de donnée, firewallé pour limiter les accès uniquement aux serveurs frontends.
On peut aussi restreindre les accès SSH à des adresses IPs données (chez soi, au boulot, depuis un autre serveur).
Aucun accès possible direct depuis l'extérieur, les failles des logiciels ne peuvent pas être exploitées…
Après, bien sûr, si ça fait tourner des dizaines de sites wordpress à la mise à jour inégale, l'accès local est rapide à chopper, et la faille kernel à exploiter. Tout dépend de l'usage.
Yth.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Yth (Mastodon) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
Ouais, c'est pas comme un four à la maison ce genre de machines, je pense qu'on essaie de les faire travailler au maximum. D'où la revente à des PME, labos et autres.
Donc le calcul donne un coût maximum en électricité, et un ordre d'idée du coût réel.
On sait qu'on va parler en k€/an.
Comme quoi la pointe à 510kW donne quand même quelques infos générales…
Yth.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Yth (Mastodon) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 7.
Option de base à 15,37c€ le kWh, ça fait :
* 15,37/100/1000 €/Wh ;
* 15,37*24*365.25/100000 €/Wan
-> 1 Watt pendant un an coûte 1€347.
Les tarifs ont augmentés par rapport à vos souvenirs !
Si on fait un calcul avec heures creuses et pleines, sachant qu'il y a 8 heures creuses et 16 heures pleines, avec une consommation de 1W permanent, donc sans optimiser les heures :
(16,62*16+11,89*8)*365.25/100000 €/Wan
-> 1 Watt pendant un an coûte 1€319
A priori l'utilisation heures creuses/pleines est un poil plus rentable pour un serveur branché 24/24, mais ça change pas grand chose…
Sans compter l'abonnement bien sûr, mais comme il faut le répartir sur la consommation totale, on n'a pas assez d'information pour le prendre en compte :)
Ici en mode basique pour le super-calculateur à 510kW, ça ferait à l'année :
510000*(15,37*24*365.25/100000) = 687k€ annuels !
Je suppose que la machine consomme plus quand elle travaille effectivement que quand elle ne fait rien, si il n'y a aucun calcul ça doit baisser, donc on a ici un maximum, au tarif particuliers, qui n'est très certainement pas le tarif UPMC (mais j'avoue n'avoir aucune idée de ce qu'ils peuvent avoir comme tarif).
Ça fait quand même une sacrée blinde…
Yth.
[^] # Re: Slackwariens/puristes complètement déconnectés de la réalité
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 3.
Concernant les paquets, tu ne comprend même pas ce que j'ai voulu écrire, tu prends le problème par ton petit bout de la lorgnette comme si j'agressais tout ce que tu crois bon dans le monde Linux !
J'ai compté les paquets pour donner une indication de la quantité de logiciels disponibles sous Slackware, et indiqué que les paquets ne sont pas découpés à la façon Debian pour donner une idée pour comparer, tes 3000 paquets doivent valoir grosso-modo les 1300 de la Slack de base.
Mais pour comprendre ça il aurait fallut que tu comprennes que je ne cherche nulle part à dénigrer les autres façon de faire ! Contrairement à toi qui continue à cracher sur une distrib que de toute évidence tu ne connais ni ne comprends…
Tsss, j'ai probablement oublié plus de choses en informatique que tu n'en connais, et joué avec plus de logiciels et de technos que tu ne crois qu'il en existe, s'il-te-plaît, ne parle pas de ce que tu ne connais pas…
Non, ça ne s'en passe pas, il y a plus de dérivés de Debian PARCE QUE il y a plus d'utilisateurs, mais si on regarde en proportions, ça donne quoi ?
Dérivés de Debian : 53
Dérivés de Ubuntu : 60
Dérivés de RedHat/Fedora : 44
Dérivés de Slackware : 24
Maintenant pour quelques stats d'utilisation, allons voir sur Linux Counter ici :
https://www.linuxcounter.net/statistics/distributions
Et puis on va faire le rapport nombre de machines sur nombre de dérivées, pour faire rapide, sinon il faudrait les classer par famille et comparer, j'ai pas tant de temps que ça à te consacrer.
Ubuntu : 657 machines/dérivés
Debian : 509 machines/dérivés
Fedora/RH : 335 machines/dérivés
Slackware : 406 machines/dérivés
Ça donne une idée de combien d'utilisateurs (sans unité de volume) il faut pour avoir une distribution dérivée.
À l'évidence la plus facile à dériver des 4 est la Fedora, puis la Slackware, puis la Debian, puis Ubuntu en dernier.
Tu vois, les chiffres à la con, on peut leur faire dire ce qu'on veut…
Reste qu'il y aurait 16% de Linuxiens sous Slackware, quand on compte des centaines de distributions Linux. Et selon toi, ils sont tous arriérés mentaux, bravo.
Ah, et il sait déjà à quelle machine te connecter, où se trouvent tes partages, quels sont les accès ?
Putain, ils sont trop forts chez Ubuntu, un vrai truc de malade…
Bref, ils ont fait quoi, packagé le logiciel et fournit une configuration par défaut ? Diantre, ça change vraiment tout ! Je veux dire, par rapport à compiler un logiciel et modifier sa configuration par défaut, c'est terrifiant…
C'est sûr, je vis dans le passé, très très loin dans le passé.
Aucun doute là-dessus, probablement même un passé alternatif, où les gens compilaient leur propre noyau Linux.
Mais quelle bidouille ?
Configurer un logiciel ce n'est pas de la bidouille, c'est un métier, et ça s'appelle Admin Système. Comment il fait ton mainteneur pour avoir conçu le fichier de conf dont TU as besoin, c'est un mentaliste ? C'est ton coloc ?
Bigre, je ne me rappelle franchement plus quand était la dernière fois que j'ai branché un truc dans une de mes machines sans que ça fonctionne directement.
Heureusement, c'est le travail du noyau Linux, qui de façon fort surprenante est commun à environ toutes les distributions GNU/Linux.
Diable, je sens venir les différences fondamentales d'architectures d'une distrib à l'autre, genre chacune doit gérer sa propre pile USB… Eh, non, attends, tout ça ce sont des logiciels libres, et ça s'échange dans tout les sens, et… Oh merde, on utilise les mêmes ! Nan, ton Scribus c'est pas le même que le mien, le tiens est packagé par un mainteneur qui fait un fichier de conf spécialement pour toi, alors que le miens, il est compilé à partir des sources officielles et packagés automagiquement, et configuré par défaut, et… ah ben c'est le même diantre, sans que moi ça s'affiche pas pareil, j'ai pas le même thème dans mon environnement de bureau, ah oui, toute la différence dans le packaging !
Mais c'est dingue ?
Tu imagines qu'elles sont construites comment les distribs ?
Parce que la dépêche écrit qu'on utilise le noyau 4.4, tu crois que c'est tout nouveau et qu'avant on était encore en 2.2 ?
La Slackware fonctionne aussi en rolling-release, des logiciels à jour, des mises à jours régulières, et le passage officiel à la 14.2 pour moi c'était sept paquets mis à jour (et là je t'écris avec Firefox 47, ça a changé par rapport à hier), et rien de fondamental qui change.
La 14.1 c'était en novembre 2013, à ce moment là il y avait wicd, mais ça a changé il y a… j'en sais trop rien en fait, mais ça fait un sacré moment, suffisamment pour que j'oublie.
Ce que tu vois écrit dans « les nouveautés » ce sont les grosses différences par rapport à la 14.1 il y a plus de deux ans et demi, pas comment les gens l'utilisent au quotidien.
C'est un peu comme de critiquer ce qui existe dans la Debian Wheezy (mai 2013) en comparant avec la Jessie (ou la Sid peut-être).
Ça n'a aucun sens au quotidien, si quelqu'un utilise la Wheezy il a de bonnes raisons pour le faire, mais ces raisons n'incluent pas un desktop récent, à jour, avec des logiciels qui n'était pas plus intéressant qu'un autre il y a trois ans, mais qui a évolué bien plus depuis.
Après les logiciels ce sont les mêmes.
La seule vraie différence c'est comment tu aimes administrer ta machine, pour le reste, ça s'utilise ou ça se configure de la même façon. Parce que les distribs ne créent pas les logiciels, elles les empaquettent.
Donc non, tu n'utiliseras pas différemment une Slackware ou une Ubuntu.
Mais tu utiliseras peut-être (sûrement) d'autres logiciels, qui eux vont s'utiliser différemment.
Franchement, je ne sais pas ce que tu t'imagines, mais redescend sur terre, soit plus pragmatique, regarde la réalité.
J'ai le gestionnaire de paquets de la Slackware en partie à cause de son absence de gestion des dépendances, mais aussi parce qu'il permet de réparer des systèmes tout pétés, que lui ne peut pas être cassé, ne peut pas t'interdire d'installer un paquet, ne t'empêche jamais de faire des conneries. Ou c'est POUR ça que je l'apprécie.
Et ça n'enlève rien de l'intérêt ou de la qualité d'APT, c'est différent.
Pourquoi ça te blesse quand je dis qu'Ubuntu offre une expérience utilisateur complète avec le moins de choix possible ? C'est bien ! C'est très bien pour découvrir et comprendre, et utiliser Linux ! C'est ce qu'il faut !
Et évidemment que rien n'empêche de changer les choix par défaut et d'aller plus loin, on parle de Linux ici, de Logiciels Libres, tu fais comme tu veux.
Le point d'accès est différent c'est tout, mais derrière, c'est tout pareil…
Tu es sur un sacré piédestal là, persuadé qu'il y a des univers de Logiciels Libres différents, auxquels un utilisateur de Slackware n'aurait pas accès.
Redescend !
Yth.
[^] # Re: Slackwariens/puristes complètement déconnectés de la réalité
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 4.
Tu fais exprès de comprendre de travers, c'est agaçant…
Tu portes ici un jugement de valeur, en comparant les paquets Slackware et Debian/Ubuntu, et en affirmant que les second valent mieux que les premiers.
Ils sont différents, et je préfère ceux de la Slack pour un certain nombre de raisons, qui n'incluent évidement pas la gestion de dépendances.
Mais jamais je ne m'amuserais à dire que le .deb est à chier parce qu'il gère les dépendances, ça n'aurait aucun sens !
Tu peux plus facilement créer une installation minimaliste, avec strictement le nécessaire en utilisant une Debian. Sur mon dernier serveur ARM, je ne me suis même pas foulé, c'est une Slack complète, avec X/KDE et cie, totalement inutiles.
Mais c'est parce que dans sa situation précise, que l'OS prenne 1Go ou 6Go je m'en moque.
Quand je dis « Ubuntu t'offre une expérience utilisateur complète » je parle tu comportement de base, et de ce que cherchent à te donner les gens qui la maintiennent et la construisent. C'est un point positif pour Ubuntu, dans un segment plutôt large du marché.
On peut s'amuser à compter les dérivées de la Slackware aussi, largement plus nombreuses rapportées au nombre d'utilisateur, alors laquelle est la plus flexible ? Difficile à dire hein ? Pour chacun ça sera celle dont il a l'habitude, et c'est tout…
Bah ouais, et la mienne, 2006 aussi, AMD Turion 64 X2 1,8Ghz, un portable, et je l'utilise avec un écran 27" full-HD, et j'utilise firefox 45.2.0 pour t'écrire ce commentaire dessus (sans flash, mais sinon tout est là), un autre brouteur (selon l'humeur, seamonkey, chrome, midori, palemoon) presque toujours à côté pour faire des tests, faire tourner un serveur apache avec une base MySQL de 2,3Go, une base Redis avec quelques millions de clés, des outils de dev, de communication (HipChat bien lourd, psi, etc.), des vidéos le midi quand je pique-nique devant mon écran, et de la musique.
Et c'est tout à fait utilisable, je dois être patient quand je réencode des vidéos 1080p vers du 480p parce que la carte vidéo est incapable de lire même le 720p sans flancher, mais je peux le faire quand même.
Alors quoi, sous prétexte que la machine est vieille je ne devrais plus l'utiliser pleinement encore aujourd'hui ? Pourquoi ça ?
Je ne connais pas du tout OpenStack, comment te répondre alors ?
En « autre techno Cloud », par exemple owncloud a son slackbuild, donc ça ressemble à un problème trivial à résoudre. Il vient de me falloir à l'instant moins de deux minutes pour créer un paquet Slackware et l'installer. Pour le reste, encore une fois, je ne connais pas, mais c'est de l'admin owncloud, ça n'a pas de raison d'être fondamentalement différent d'une distrib à l'autre…
Deux minutes pour trouver cette page : http://www.hansneervoort.nl/projects/2noderac/iscsiinitiator.html qui t'expliquait déjà en 2012 comment configurer de l'ISCSI sous Slackware. Encore une fois je ne connais pas du tout, mais la portion spécifique à la Slackware semble se résumer à « wget les_sources | dé-tare && make && make install » soit rien de bien tuant, le reste c'est de l'admin ISCSI, qui n'a aucune raison d'être fondamentalement différente sous Slackware que sous autre chose…
Il faut peut-être recompiler le module noyau, et l'ajouter dans l'initrd, il faut très certainement savoir ce que l'on fait à un moment. Mais bon, configurer un Apache aussi nécessite de savoir ce que l'on fait à un moment… Ou n'importe quel logiciel serveur d'ailleurs.
Ah, est-ce que pour toi télécharger des sources, les compiler et les installer c'est de la bidouille ?
Si oui, on s'est mal compris depuis très très longtemps : un slackbuild c'est exactement ça : télécharger des sources, les compiler, et créer un paquet Slackware qu'on installe. Et ça c'est l'utilisation normale de la Slackware.
Et non, jamais personne n'a prétendu que c'était à la portée de tout le monde ni pensé pour tout le monde. La Slackware c'est ça, tu édites tes fichiers de conf à la main, si pour toi c'est une étape rebutante, il faut t'arrêter bien plus tôt dans la discussion, passe ton chemin, cette distribution ne te parlera jamais !
Mais je crois que ça parle à beaucoup de gens, et pas uniquement aux amateurs de Slackware.
Qui a parlé de flexibilité ? J'ai parlé d'une base robuste sur laquelle construire quelque chose. Et dans construire il y a « construire ».
Tu parles de la période « pré-mobiles » c'est quoi pour toi, le passage de l'admin système au clicodrôme ?
Tout se fait avec des grosses icônes ?
Diantre, ce n'est pas d'une époque plus ancienne dont tu parles, mais d'un fork dans les usages…
Et c'est moi qui suis resté dans un coin ? Sous prétexte que tu rejettes tout ce qui ne se fait pas « à-la-mobile-fashion-du-moment » ?
Wouhouhou !
On ne vit en effet pas dans le même monde ^
Yth.
[^] # Re: Slackwariens/puristes complètement déconnectés de la réalité
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 3.
Je suppose que je dois me sentir visé.
Désolé, je ne contrôle pas tout les bugs, et pas souvent les bugs kernel.
Cela dit j'en ai un avec ma carte AMD, pour le coup bien ancienne, puisque c'est une Radeon RS482M (Mobility Xpress 200).
Il y a pas mal de situations liées au passage en veille de l'écran (blank mode, ou l'éteindre ou qu'importe, tant que ça touche à la carte vidéo), ou au changement de résolution, où l'affichage part en vrille. Pas d'écran noir, mais des lignes blanches, verticales, en bordel, parfois d'autres trucs.
Le reste des symptômes c'est comme toi : tout fonctionne, en ssh depuis une autre machine tout fonctionne à la perfection, tu peux lancer des programmes sous X, lancer une vidéo tu auras le son, et il n'y a rien dans aucun log système.
J'ai une solution pratique : passer l'ordinateur en veille soft, et le rallumer.
Et là tout fonctionne.
Sans ça ? Je suppose que j'aurais changé d'ordinateur, ou peut-être que je l'utiliserais en mode VESA qui n'a pas ce soucis. Ou alors que j'aurais essayer de composer avec un vieux kernel pour avoir un vieux driver Catalyst, mais c'est franchement pas gagné ce genre de bidouilles…
Maintenant tu peux aussi, sous XFCE, essayer de désactiver tout les modes d'économies d'énergie de l'écran, ne jamais l'éteindre, ne jamais le mettre en blank, rien du tout, peut-être que ça annulera le problème, en te forçant à contrôler toi-même la gestion d'énergie, donc penser à passer manuellement en veille à chaque fois.
Yth.