Oui, il n'y a rien à ajouter, mais comme indiqué plus haut, il peut valoir le coup de remplacer la pâte thermique, voire le radiateur/ventilo.
Selon l'endroit où tu le mets, si le bruit gêne, si tu veux le faire malgré tout tourner à 2Ghz, etc.
Oui, j'ai le CPU ondemand.
Apparemment la pâte thermique utilisée est assez bas de gamme, et on peut clairement faire mieux en terme de radiateur et même ventilo, donc on peut le refroidir.
S'il est à la cave la température ambiante sera plus basse donc ça dissipera mieux la chaleur aussi.
Je ne sais pas si un eMMC est moins fragile qu'une carte SD, j'ai flingué ma microSD 64Go assez rapidement (qui me servait de disquette), alors que mon eMMC tourne depuis plus d'un an sans montrer de signe de faiblesse.
De ce que j'ai pu lire en ligne l'eMMC serait plus durable et performant que les cartes SD, mais moins qu'un disque SSD…
Je n'ai pas de RPi, donc je ne peux pas comparer avec icelui.
De plus je l'utilise exclusivement comme serveur, pas d'interface graphique, pas de retro-gaming, pas de lecture de vidéos, désolé :(
Mais comme machine de salon, le ventilateur est assez rebutant, trop de bruit, ça gâche un espace de vie qui gagne à être silencieux, ça s'arrange avec les manips que j'explique plus bas, mais ça reste présent.
Sinon voici ce que je peux dire :
Les huit cœurs sont séparés en deux fois 4 cœurs : les 4 premiers sont cadencés à 1,4Ghz maximum, les 4 autres à 2Ghz.
-> Si tu lances une compilation en -j 9 pour bourriner au maximum, la machine va surchauffer et s'arrêter quand une des zones thermique va atteindre les 120°C, assez rapidement, quelques minutes maxi.
De plus selon le choix de régulateur que tu fais, quand les cœurs à 2Ghz tournent à fond, le ventilo se déclenche bien rapidement et ta machine décolle. Ce qui peut arriver n'importe quand quand un processus travaille et est envoyé sur un de ceux-là.
Mais il y a une solution simple à ce problème, qui consiste à limiter les 4 cœurs de 2Ghz à 1,4Ghz comme les autres ainsi (les 4 cœurs n°1 à 4 sont liés, donc changer sur l'un d'eux le change sur tous, idem pour les cœurs 0, 5, 6 et 7 mais eux sont déjà à 1,4Ghz) :
echo 1400000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
Depuis que j'ai mis ça en place, je n'ai jamais eu de soucis d'instabilité, le ventilateur se déclenche moins souvent et moins bruyamment, et une compilation de goret ne fait pas dépasser les 80°, sachant qu'il tourne à environ 50° de base.
À 80° tout va très bien, on est très loin des 120° qui arrêtent le système, on a toujours huit cœurs à 1,4Ghz, ce qui doit le rendre nettement plus rapide que le RPi.
Il s'agit bien de huit cœurs, sans hyperthreading ou truc du genre
À titre de comparaison avec mon PC portable du travail qui est un Core i3-4160 à 3,6Ghz, donc 2 cœurs (4 threads), sur la compilation de qemu (en utilisant le slackbuild, les deux machines sont sous slackware) on a ça avec « time qemu.slackbuild », en gardant en tête que je ne sais pas si la compilation ARM est plus ou moins complexe que la compilation x86, donc que la puissance requise n'est pas forcément équivalente :
XU4 8@1,4Ghz | -j9 :
real 11m22.265s
user 57m13.670s
sys 4m36.115s
core i3-4160 2x2@3,6Ghz | -j3 :
real 3m44,110s
user 9m12,843s
sys 0m32,804s
La réactivité de la machine est très bonne, je m'en sers comme firewall, serveur DHCP et DNHS (dnsmasq), serveur mail (opensmtpd, dovecot), synchro de fichiers avec syncthing, Apache/MySQL, passage de protocoles en SSL avec stunnel (du web genre la GUI de syncthing).
Mon uptime n'est que de deux semaines parce que ça fait deux semaines que je me suis attaqué au problème de la surchauffe, mais sans le faire je n'ai jamais eu de plantage, sauf en compilant des trucs en -j9, j'avais résolu en faisant -j1 histoire que ça ne chauffe pas du tout, mais c'est beaucoup plus long :)
J'ai eu plusieurs mois de fonctionnement sans me poser de questions.
Côté connectique rien à déclarer, ça suit les specs.
Je n'ai pas mesuré la consommation électrique avec un appareil, je fais confiance aux valeurs trouvées en ligne, et il n'utilise qu'un stockage eMMC de 64Go, pas de DD branché à côté (mais ça va sûrement changer parce que 64Go ça fait juste et que je voudrais bien économiser l'eMMC).
En espérant que ça puisse répondre aux questions que toi et Nicolas R. vous posez !
Chais pas, je fais tourner une Slackware current dessus alors les trucs officiellement supportés, je sais pas trop.
La communauté autour est certes moins grosse que celle du RPi, mais bien active, il y a des dizaines de distribs différentes, y compris une Debian récentes avec un kernel vanilla.
Ce qui est sûr c'est qu'il tournera aussi bien dans 15 ans (sauf panne matérielle), et que sa sécurité ne va pas dépendre des derniers patchs kernel, mais plus des services installés dessus, et de la configuration de son firewall.
Maintenant, est-ce que dans 15 ans j'aurais un kernel à jour ou pas ?
C'est possible puisqu'on peut faire tourner un kernel non modifié dessus aujourd'hui, mais je doute très fort que le GPU ait un driver libre et à jour par contre.
Cela dit comme je ne l'utilise pas (le GPU), c'pas si grave.
D'ici là bien des choses auront changées, et je ne serai pas mortifié de remplacer mon XU4 dans 15 ans par quelque chose de dix fois plus puissant et qui consommera trois fois moins, avec des connectiques post-modernes (adaptateur 220V révolutionnaire, USB 4.2, 5G, fibre optique, HDVGAMI, MediaPlayPort 2.0, ElectroMagnetic GreenFang Field, un QSD de 10To, etc…).
C'est très rare qu'un outil se limite à un cas d'usage ultra spécifique
C'est vrai.
Mais c'est déjà bien.
On parle de Google Play, la plupart des applis n'ont aucune utilité pratique sans aucun cas d'usage même ultra-spécifique.
Ça remonte le niveau quoi !
Tu le branches derrière une prise pare-foudre et tu as en plus une UPS intégré, pas besoin d'ajouter un onduleur pour protéger le matériel, ça reste disponible (et surtout ça ne se prend pas une coupure sauvage et brutale) en cas de coupure de courant.
Clavier, souris et écrans intégrés sans fils supplémentaires, et optimisé (un minimum) pour consommer le moins possible quand tu ne les utilise pas. Donc tu n'as besoin de rien pour intervenir directement dessus : si le faire via le réseau n'est pas une solution à un moment donné, ce recours est disponible.
Selon le matériel (faut quand même avoir de la chance et un truc pas trop ancestral), ça peut servir de point d'accès wifi.
Je confirme, le vieux portable c'est une bonne solution de serveur maison :)
Le principal point négatif c'est que selon le modèle il peut surchauffer s'il est mal aéré, donc impossible de l'entreposer planqué dans ton tiroir à chaussettes.
À la cave c'est le top (j'ai habité un endroit où l'accès ADSL était à la cave, avec du RJ-45 tiré vers les étages, j'avais mis un vieux portable juste à côté, ça reste bien frais !), sinon faut qu'il soit aéré donc potentiellement bien visible.
Et un téléphone ça tourne 24h/24, même si ça ne pompe du jus que sur de courtes périodes pour recharger la batterie, ça dépense de l'énergie en permanence.
Mais on parlait de serveurs ici, pas de machines utilisateur.
Hmm, es-tu sûr qu'il est meilleur pour la planète de récupérer des vieux 486 et de les faire tourner en batterie, par paquets de 100, pour obtenir la puissance d'au hasard un Odroid XU4 (75$), soit écologique pour la planète ?
J'ai un vieux 486 DX4-100 16Mo 1Go, une très belle machine, mais 100Mhz avec toute sa consommation et sa connectique réseau limitée au 10Mbit (oui, bus ISA pas PCI).
Je le compare à mon XU4 octo-processeur (4 à 1,4Ghz, et 4 à 2Ghz, 2Go RAM, eMMC 64Go), certes pas utilisé en permanence à 100% loin de là, mais réellement utilisable au quotidien.
Et je ne suis pas sûr que de remplir ma cave de vieux 486 pour obtenir une puissance suffisante pour utiliser les services présents sur mon XU4 soit écologiquement viable.
En combien de temps la surconsommation électrique, (sans compter la filerie nécessaire), va avoir plus puisé dans les réserves de la terre que la fabrication de mon minuscule XU4 produit à la chaîne ?
Je l'ai fait tourner bien au delà de ce qu'on était en mesure d'attendre de lui, crois-moi, mais aujourd'hui, à part servir de support de table basse (pas de pollution, recyclage pratique effectif à 100%), je ne le rallumerais que pour faire briller les yeux de mes gamins (ou les déprimer, on verra bien :p).
Avec mon XU4 (mais avec un RPi, ou un BBB, ou autre c'est grosso modo pareil) c'est à la planète ET à mon portefeuille que j'ai pensé.
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).
[^] # Re: Planète ?
Posté par Yth (Mastodon) . En réponse au sondage Les serveurs des geeks : écolos ?. Évalué à 2.
Oui, il n'y a rien à ajouter, mais comme indiqué plus haut, il peut valoir le coup de remplacer la pâte thermique, voire le radiateur/ventilo.
Selon l'endroit où tu le mets, si le bruit gêne, si tu veux le faire malgré tout tourner à 2Ghz, etc.
Yth.
[^] # Re: Planète ?
Posté par Yth (Mastodon) . En réponse au sondage Les serveurs des geeks : écolos ?. Évalué à 2.
Oui, j'ai le CPU ondemand.
Apparemment la pâte thermique utilisée est assez bas de gamme, et on peut clairement faire mieux en terme de radiateur et même ventilo, donc on peut le refroidir.
S'il est à la cave la température ambiante sera plus basse donc ça dissipera mieux la chaleur aussi.
Je ne sais pas si un eMMC est moins fragile qu'une carte SD, j'ai flingué ma microSD 64Go assez rapidement (qui me servait de disquette), alors que mon eMMC tourne depuis plus d'un an sans montrer de signe de faiblesse.
De ce que j'ai pu lire en ligne l'eMMC serait plus durable et performant que les cartes SD, mais moins qu'un disque SSD…
Yth.
[^] # Re: Planète ?
Posté par Yth (Mastodon) . En réponse au sondage Les serveurs des geeks : écolos ?. Évalué à 4.
Je n'ai pas de RPi, donc je ne peux pas comparer avec icelui.
De plus je l'utilise exclusivement comme serveur, pas d'interface graphique, pas de retro-gaming, pas de lecture de vidéos, désolé :(
Mais comme machine de salon, le ventilateur est assez rebutant, trop de bruit, ça gâche un espace de vie qui gagne à être silencieux, ça s'arrange avec les manips que j'explique plus bas, mais ça reste présent.
Sinon voici ce que je peux dire :
Les huit cœurs sont séparés en deux fois 4 cœurs : les 4 premiers sont cadencés à 1,4Ghz maximum, les 4 autres à 2Ghz.
-> Si tu lances une compilation en -j 9 pour bourriner au maximum, la machine va surchauffer et s'arrêter quand une des zones thermique va atteindre les 120°C, assez rapidement, quelques minutes maxi.
De plus selon le choix de régulateur que tu fais, quand les cœurs à 2Ghz tournent à fond, le ventilo se déclenche bien rapidement et ta machine décolle. Ce qui peut arriver n'importe quand quand un processus travaille et est envoyé sur un de ceux-là.
Mais il y a une solution simple à ce problème, qui consiste à limiter les 4 cœurs de 2Ghz à 1,4Ghz comme les autres ainsi (les 4 cœurs n°1 à 4 sont liés, donc changer sur l'un d'eux le change sur tous, idem pour les cœurs 0, 5, 6 et 7 mais eux sont déjà à 1,4Ghz) :
echo 1400000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
Depuis que j'ai mis ça en place, je n'ai jamais eu de soucis d'instabilité, le ventilateur se déclenche moins souvent et moins bruyamment, et une compilation de goret ne fait pas dépasser les 80°, sachant qu'il tourne à environ 50° de base.
À 80° tout va très bien, on est très loin des 120° qui arrêtent le système, on a toujours huit cœurs à 1,4Ghz, ce qui doit le rendre nettement plus rapide que le RPi.
Il s'agit bien de huit cœurs, sans hyperthreading ou truc du genre
À titre de comparaison avec mon PC portable du travail qui est un Core i3-4160 à 3,6Ghz, donc 2 cœurs (4 threads), sur la compilation de qemu (en utilisant le slackbuild, les deux machines sont sous slackware) on a ça avec « time qemu.slackbuild », en gardant en tête que je ne sais pas si la compilation ARM est plus ou moins complexe que la compilation x86, donc que la puissance requise n'est pas forcément équivalente :
XU4 8@1,4Ghz | -j9 :
real 11m22.265s
user 57m13.670s
sys 4m36.115s
core i3-4160 2x2@3,6Ghz | -j3 :
real 3m44,110s
user 9m12,843s
sys 0m32,804s
La réactivité de la machine est très bonne, je m'en sers comme firewall, serveur DHCP et DNHS (dnsmasq), serveur mail (opensmtpd, dovecot), synchro de fichiers avec syncthing, Apache/MySQL, passage de protocoles en SSL avec stunnel (du web genre la GUI de syncthing).
Mon uptime n'est que de deux semaines parce que ça fait deux semaines que je me suis attaqué au problème de la surchauffe, mais sans le faire je n'ai jamais eu de plantage, sauf en compilant des trucs en -j9, j'avais résolu en faisant -j1 histoire que ça ne chauffe pas du tout, mais c'est beaucoup plus long :)
J'ai eu plusieurs mois de fonctionnement sans me poser de questions.
Côté connectique rien à déclarer, ça suit les specs.
Je n'ai pas mesuré la consommation électrique avec un appareil, je fais confiance aux valeurs trouvées en ligne, et il n'utilise qu'un stockage eMMC de 64Go, pas de DD branché à côté (mais ça va sûrement changer parce que 64Go ça fait juste et que je voudrais bien économiser l'eMMC).
En espérant que ça puisse répondre aux questions que toi et Nicolas R. vous posez !
Yth.
[^] # Re: Planète ?
Posté par Yth (Mastodon) . En réponse au sondage Les serveurs des geeks : écolos ?. Évalué à 3. Dernière modification le 23 septembre 2016 à 09:11.
Chais pas, je fais tourner une Slackware current dessus alors les trucs officiellement supportés, je sais pas trop.
La communauté autour est certes moins grosse que celle du RPi, mais bien active, il y a des dizaines de distribs différentes, y compris une Debian récentes avec un kernel vanilla.
Ce qui est sûr c'est qu'il tournera aussi bien dans 15 ans (sauf panne matérielle), et que sa sécurité ne va pas dépendre des derniers patchs kernel, mais plus des services installés dessus, et de la configuration de son firewall.
Maintenant, est-ce que dans 15 ans j'aurais un kernel à jour ou pas ?
C'est possible puisqu'on peut faire tourner un kernel non modifié dessus aujourd'hui, mais je doute très fort que le GPU ait un driver libre et à jour par contre.
Cela dit comme je ne l'utilise pas (le GPU), c'pas si grave.
D'ici là bien des choses auront changées, et je ne serai pas mortifié de remplacer mon XU4 dans 15 ans par quelque chose de dix fois plus puissant et qui consommera trois fois moins, avec des connectiques post-modernes (adaptateur 220V révolutionnaire, USB 4.2, 5G, fibre optique, HDVGAMI, MediaPlayPort 2.0, ElectroMagnetic GreenFang Field, un QSD de 10To, etc…).
Yth.
[^] # Re: mouais
Posté par Yth (Mastodon) . En réponse au journal Un peu de méca : mesurer un module de Young avec son smartphone. Évalué à 4.
C'est vrai.
Mais c'est déjà bien.
On parle de Google Play, la plupart des applis n'ont aucune utilité pratique sans aucun cas d'usage même ultra-spécifique.
Ça remonte le niveau quoi !
Yth, pfff…
[^] # Re: Ordi portable
Posté par Yth (Mastodon) . En réponse au sondage Les serveurs des geeks : écolos ?. Évalué à 7.
Tu le branches derrière une prise pare-foudre et tu as en plus une UPS intégré, pas besoin d'ajouter un onduleur pour protéger le matériel, ça reste disponible (et surtout ça ne se prend pas une coupure sauvage et brutale) en cas de coupure de courant.
Clavier, souris et écrans intégrés sans fils supplémentaires, et optimisé (un minimum) pour consommer le moins possible quand tu ne les utilise pas. Donc tu n'as besoin de rien pour intervenir directement dessus : si le faire via le réseau n'est pas une solution à un moment donné, ce recours est disponible.
Selon le matériel (faut quand même avoir de la chance et un truc pas trop ancestral), ça peut servir de point d'accès wifi.
Je confirme, le vieux portable c'est une bonne solution de serveur maison :)
Le principal point négatif c'est que selon le modèle il peut surchauffer s'il est mal aéré, donc impossible de l'entreposer planqué dans ton tiroir à chaussettes.
À la cave c'est le top (j'ai habité un endroit où l'accès ADSL était à la cave, avec du RJ-45 tiré vers les étages, j'avais mis un vieux portable juste à côté, ça reste bien frais !), sinon faut qu'il soit aéré donc potentiellement bien visible.
Yth.
[^] # Re: Et sinon, pourquoi se limiter au serveur ?
Posté par Yth (Mastodon) . En réponse au sondage Les serveurs des geeks : écolos ?. Évalué à 3.
Et un téléphone ça tourne 24h/24, même si ça ne pompe du jus que sur de courtes périodes pour recharger la batterie, ça dépense de l'énergie en permanence.
Mais on parlait de serveurs ici, pas de machines utilisateur.
Yth.
[^] # Re: Planète ?
Posté par Yth (Mastodon) . En réponse au sondage Les serveurs des geeks : écolos ?. Évalué à 8.
Hmm, es-tu sûr qu'il est meilleur pour la planète de récupérer des vieux 486 et de les faire tourner en batterie, par paquets de 100, pour obtenir la puissance d'au hasard un Odroid XU4 (75$), soit écologique pour la planète ?
J'ai un vieux 486 DX4-100 16Mo 1Go, une très belle machine, mais 100Mhz avec toute sa consommation et sa connectique réseau limitée au 10Mbit (oui, bus ISA pas PCI).
Je le compare à mon XU4 octo-processeur (4 à 1,4Ghz, et 4 à 2Ghz, 2Go RAM, eMMC 64Go), certes pas utilisé en permanence à 100% loin de là, mais réellement utilisable au quotidien.
Et je ne suis pas sûr que de remplir ma cave de vieux 486 pour obtenir une puissance suffisante pour utiliser les services présents sur mon XU4 soit écologiquement viable.
En combien de temps la surconsommation électrique, (sans compter la filerie nécessaire), va avoir plus puisé dans les réserves de la terre que la fabrication de mon minuscule XU4 produit à la chaîne ?
Je l'ai fait tourner bien au delà de ce qu'on était en mesure d'attendre de lui, crois-moi, mais aujourd'hui, à part servir de support de table basse (pas de pollution, recyclage pratique effectif à 100%), je ne le rallumerais que pour faire briller les yeux de mes gamins (ou les déprimer, on verra bien :p).
Avec mon XU4 (mais avec un RPi, ou un BBB, ou autre c'est grosso modo pareil) c'est à la planète ET à mon portefeuille que j'ai pensé.
Yth (j'ai un 386 aussi à la cave).
[^] # Re: Chiffres de ventes publics
Posté par Yth (Mastodon) . En réponse à la dépêche Angular 2 est en version finale, Ninja Squad vous met le pied à l’étrier. Évalué à 4.
Et « Freund » ça veut dire « ami » en allemand (strict équivalent de « Friend » en anglais).
Mais c'est pas le papa des psique à nalise…
Yth.
[^] # 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.