N'étant pas Debianiste, je pose peut-être une question idiote…
Mais est-ce qu'utiliser une Debian stable pour jouer à des jeux, en espérant profiter des dernières avancées des drivers OpenGL est réellement pertinent ?
A priori, l'idée, c'est de fournir une API proche du matériel, mais standardisée malgré tout.
C'est à dire qu'un logiciel qui exploite Vulkan Vx.y va fonctionner sur tout matériel supportant Vulkan Vx.y ou supérieure.
Il ne s'agit pas de fournir des fonctionnalités spécifiques aux cartes, mais au contraire de donner un accès standardisé aux capacités des cartes en général. Un truc générique, mais bien plus bas niveau qu'OpenGL.
Après je ne connais pas les détails, je ne sais pas s'il y aura des extensions que toutes les cartes ne supporteront pas, et donc derrière des logiciels incapables de se passer de ces extensions, donc restreignant le matériel accessible.
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…
[^] # Re: Retour d'expérience sur la première session
Posté par Yth (Mastodon) . En réponse à la dépêche Apprendre la programmation fonctionnelle avec le MOOC OCaml. Évalué à 4.
Les étudiants non francophones.
Yth.
[^] # Re: Et pour l'utilisateur?
Posté par Yth (Mastodon) . En réponse au journal Mesa: OpenGL 4.5 et OpenGL ES 3.2 pris en charge. Évalué à 10.
N'étant pas Debianiste, je pose peut-être une question idiote…
Mais est-ce qu'utiliser une Debian stable pour jouer à des jeux, en espérant profiter des dernières avancées des drivers OpenGL est réellement pertinent ?
Yth.
[^] # Re: Vulkan?
Posté par Yth (Mastodon) . En réponse au journal Mesa: OpenGL 4.5 et OpenGL ES 3.2 pris en charge. Évalué à 10.
A priori, l'idée, c'est de fournir une API proche du matériel, mais standardisée malgré tout.
C'est à dire qu'un logiciel qui exploite Vulkan Vx.y va fonctionner sur tout matériel supportant Vulkan Vx.y ou supérieure.
Il ne s'agit pas de fournir des fonctionnalités spécifiques aux cartes, mais au contraire de donner un accès standardisé aux capacités des cartes en général. Un truc générique, mais bien plus bas niveau qu'OpenGL.
Après je ne connais pas les détails, je ne sais pas s'il y aura des extensions que toutes les cartes ne supporteront pas, et donc derrière des logiciels incapables de se passer de ces extensions, donc restreignant le matériel accessible.
Yth.
[^] # Re: Le téléphone est vraiment IP67 ?
Posté par Yth (Mastodon) . En réponse au journal Tout simplement E P I Q U E. Évalué à 10.
Franchement, tout leurs produits se ressemblent :
Un truc plat, aux bords arrondis, vide, avec une pomme lumineuse au milieu.
On peut apprécier autre chose comme design sans pour autant manquer de goût ou de sensibilité esthétique…
Yth.
[^] # 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.