Il faut bien voir que 99% des services n'ont absolument pas besoin d haute disponibilité à la minute.
Merci, il faudrait le dire tellement haut et fort : il y a plein de pseudo-« génies » qui se tripotent la nouille en montant des setup haute-dispo blah blah (que ça soit du proprio ou du libre, hein), qui nécessitent des machines et des softs titanesques, qui passent des semaines à le configurer, et qu'il ne faut surtout pas toucher après sinon tout pète… et ça finit toujours par péter un jour, sans personne d'assez compétent pour le réparer (ou alors des consultants payés une blinde). Alors on passe à la prochaine techno à la mode…
Mais c'est un moyen d'attirer les financements, et comme de toutes façons aujourd'hui les financements humain et fournitures sont séparés (je parle toujours du public), bah au lieu d'embaucher quelqu'un qui se démerde un peu avec une Debian et du matos basique, t'es obligé d'acheter des bouses gigantesques et gérer la merde après.
Exemple, dans l'embarqué on génère très souvent des images entiers à base de buildroot et Yocto. Pour faire les choses bien on a une intégration continue sur le système avec nos changements. Résultat l'image doit être régénérée à chaque fois de 0 (cela signifie refaire le configure de centaines / milliers de paquets à chaque nouveau commit ou nouvelle livraison).
C'est marrant que tu me parles de Yocto, je me le tape tous les jours et je peux te le dire : Yocto n'a pas du tout la bonne approche. Rebuilder depuis les sources à chaque fois, sans reproductibilité binaire, ça n'est pas la bonne manière de faire. C'est même idiot. Voir comment font les distros classique pour comprendre pourquoi.
C'est comme ce que j'ai dit au-dessus à propos de ne pas avoir à relancer le configure à chaque make : ça serait débile.
C'est toujours facile de dire « faut pas faire ça » sans ne serait-ce que citer une solution. Et en l'occurrence sans dire « ok il n'y a pas de solution mais la moins pire serait… ».
Bah je sais pas, on nous balance le cloud comme si c'était une techno révolutionnaire qui changerait tout… comme dit Sytoka plus haut, s'héberger soi-même ça se fait depuis toujours. Certes, pas avec toutes les fonctionnalités avancées du could d'aujourd'hui, mais je ne vois pas en quoi ça serait un truc tellement difficile qu'on en serait obligé à passer uniquement par des américains. D'où le fait qu'Albert n'ait pas à citer de solution pour qu'on comprenne que quand même, ça n'est pas impossible de faire sans les US.
Ce qui me fait peur, c'est que justement on trouve ça aujourd'hui impossible de s'héberger, alors que c'était la norme avant ! Cela sous-entend que les mentalités ont bien été manipulées par les vendeurs de cloud pour qu'on ait oublié cette époque. (encore une fois, je comprends que c'est moins pratique que du cloud, mais de là à trouver ça impossible…)
La rhétorique c'est bien dire « il ne faut pas faire ça » sans proposer aucune solution, auquel cas je réponds « y a une solution c'est l'âge de pierre en gros ».
Donc c'était de l'ironie ? Désolé de pas t'avoir compris alors.
Et la non-rhétorique ça serait de dire par exemple « pourquoi pas OVH même si VMware ».
Je savais pas qu'OVH c'était vu VMWare… c'est triste.
Si je peux me permettre de dévier un peu, je trouve ça triste à quel point aujourd'hui on trouve qu'héberger et administrer des machines ça soit vu comme une tâche insurmontable partout : je vois effectivement que beaucoup de monde le constate, alors qu'on avait pas mal de connaissance avant.
Mon expérience perso dans un établissement public (anecdotique, certes) montre qu'une Debian bien configurée avec du libvirt/kvm plus quelques scripts maisons, avec un ingé qui se démerde un peu, ça tient tout seul, même sur du long terme (mon travail a survécu à l'arrivée et la fin d'un Openstack, qui devait être la panacée…).
Je trouve dommage que tu plonges dans la fausse dichotomie qui oblige à « tout accepter » à moins de vouloir revenir à l'âge de pierre. C'est un piège rhétorique classique il me semble. Ça a toujours été utilisé pour décrédibiliser le projet GNU, alors que le seul moyen à long terme d'y arriver est d'effectivement de refuser tout logiciel privateur.
Par contre, ceux qui sont étonnés de la migration vers Azure des administrations… comment s'en étonner quand ça fait 30 ans que MS pilonne les écoles et les administrations, qui le lui rendent bien financièrement parlant ? Ce n'est que la suite logique. L'ennemi n'a pas changé de camp…
Ce que nous disent benoar et d'autres c'est qu'ils aiment les autotools en tant que gestionnaire de paquet (en lieu et place de dpkg, rpm ou flatpack). Je veux signifier que c'est un usage totalement à la marge et que les gains apportés pour les usages conventionnels sont bien plus grands que l'inconvénient qu'ils voient sur l'usage qu'ils en font.
Je ne suis pas d'accord que ça soit un usage « totalement à la marge » : le projet GNU a établit des standards https://www.gnu.org/prep/standards/standards.html qui, lorsqu'ils sont suivis (en utilisant les autotools) permettent de correctement distribuer un travail (on parle de « distribution » dans la terminologie autotools pour désigner un tarball d'une version donnée d'un logiciel). Ça n'est pas non plus un gestionnaire de paquet complet : c'est un entre deux, mais c'est bien plus que simplement un système de build. Je l'avais décrit comme permettant de faire bien plus que juste compiler dans une présentation que j'avais faite http://dolka.fr/bazar/atelier_empaquetage_facon_GNU/atelier_empaquetage_facon_GNU.pres.html : ça permet de distribuer, d'informer de la licence, de faciliter la reproductibilité et la disponibilité des sources. Des choses qui sont plutôt l'apanage des système de gestion de paquet d'habitude (comme celui de Debian, qui couvre tous ces aspects également).
L'inconvénient que tu citais plus haut sur les perfs, je ne comprends pas : le configure n'est fait qu'une fois, après tu "make" quand tu changes un fichier et c'est très rapide.
Bien sûr, comme tout système qui se veut être le seul standard, d'autres sont venus le contredire, et les « distributions » au sens classique du terme (ensemble de logiciels intégrés avec un noyau) sont venu « uniformiser » ça ; bien sûr, on a eu plusieurs distributions…
Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
make ? le compilateur ? la bibliothèque standard du C ou C++ ? Ce n'est pas dans les outils de base de ma distribution.
Ça l'était à une époque. Et ma remarque était pour dire qu'en gros, si tu veux compiler un outil depuis les sources, bien sûr qu'il faut un compilateur, mais tu n'auras pas besoin de télécharger le dernier outil de build à la mode : tout ce qui est hors des outils que tu cites et qui sont historiquement considérés comme « standards » est superflu.
Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
Comme dit Matthieu, le cas « utilisateur qui compile et modifie éventuellement » peut paraître étrange par rapport au dev qui veut modifier la procédure de build et plus, mais c'est une dichotomie qui valait à une certaine époque et que je trouve toujours bonne pour un paquet de projets aujourd'hui. La preuve par cette news elle-même : c'est encore un nouveau standard nécessaire pour compiler X projets. Autotools ne sera jamais nécessaire pour un développeur qui fait des modifications minimes.
Oui, c'est là que je l'ai vu. C'était juste pour présenter l'information directement ici, pour éviter à ceux qui ne cherchent pas en région parisienne d'avoir l'info direct (il me semble que c'est une des informations essentielles d'une annonce).
les autotools doivent être installés sur la machine…
sinon ./configure ne fonctionnera pas!
Où alors j'ai rien compris :(
Tu n'as effectivement pas compris. Les prérequis d'un configure sont très simples : un shell et les outils Unix de base. C'est d'ailleurs la raison de sa « lourdeur » : il fait tout avec ces prérequis très minimaux, ce qui est assez contraignant, et oblige à plein de contournements lourds en ressources.
De même, tu n'auras pas besoin des autotools tant que tu ne fais pas de modification du système de build lui-même : tu peux modifier les fichiers source et recompiler sans avoir les autotools. Un ajout de fichier ou de dépendance de bibliothèque, par contre, t'obligera à les avoir, et faire un coup d'autoreconf.
Mouarf, comment tu choisis tes passages ; à peu près l'ensemble de l'article critique le résultat qui contient un nombre assez énorme d'erreurs. La conclusion que tu cites est le début, sous forme d'encouragement, mais la suite dit :
Unfortunately, there are too many holes in the xhtml+CSS export at this time to make it really usable unless your document has almost unstyled paragraphs only. Some generated styles (overline?!?) are not present in the original document, it generates only paragraphs and tables losing the header or list semantics, the LibreOffice styles are not serialized in a CSS stylesheet (bug?) and more. This will help some individuals but I am not sure it will help EPUB publication chains, at least for now.
En gros, ça marche si ton document n'a pas de style.
Oui, le combat est politique : sans cette feature, il est difficile de s'héberger correctement (complexité de la gestion de TLS, complexité sur failover sans CDN, etc) avec des moyens raisonnables, sans être un « gros ». Étrangement, parmi ceux qui s'opposent dans ce rapport de bug à la résolution de ce problème par des entrées SRV avec des arguments plus ou moins valable, on trouve des ingénieurs de chez Google. Et Google finance Mozilla. Forcément, ça doit donner envie de laisser traîner la résolution…
Ah, je n'avais pas capté que tu trouvais ce log confus : il indique que le client se connectant à machine1, donc ton premier client SSH depuis ton poste au boulot, s'est déconnecté volontairement car la commande qu'il a lancé à l'intérieur (qui n'est pas un shell), c-à-d le ssh sur machine2, a quitté, pour quelque raison que ce soit. Dans ton cas, ce second SSH a dû faire un timeout et tu n'as pas de trace, mais du point de vue de machine1 ta session a été fermée volontairement parce que la commande à l'intérieur s'est terminée, c'est tout.
En ce qui concerne l'aide que ça pourra apporter à la police, si tu as un horodatage précis, ça pourra éventuellement aider à retracer en croisant avec d'autres sources précises comme des caméras de surveillance (expérience perso).
Tu peux regarder si tu trouve la durée du timeout dans sshd_config de machines.
ClientAliveInterval
Effectivement, mais pour ce paramètre il faudrait la conf de machine2… Pour le client, il faudrait voir la conf de machine1, en particulier ServerAliveInterval, qui n'est pas active par défaut.
De plus, si ce sont les paramètre du kernel uniquement qui sont concernés, ça dépend de plusieurs paramètres : tcp_keepalive_time qui est de 2h (début du test de transmission d'une connexion inactive), ou tcp_retries2 qui indique qu'une connexion « perdue » mettra environ 1000 s minimum avant d'être cassée de force. Du coup ça dépend de l'activité de cette connexion ; je suppose qu'une session X active dessus fait qu'elle était plutôt occupée, et que le keepalive ne compte donc pas vraiment.
Bon courage pour la suite des affaires en tous cas.
Oui, c'est clair que le monde du FPGA c'est pas la joie niveau ouverture. Je ne suis pas convaincu que l'arrivée d'un nouveau concurrent change quoi que ce soit, mais on peut toujours rêver.
Voyons voir avec 2a01:cb19:XXXX:c001::2/64 (qui est dans le sous-réseau suivant) : paf, ça répond plus.
La livebox a un /56, mais ça ne de dit pas comment elle le route. Visiblement, :c001::/64 n'est pas un préfixe sur le lien Ethernet directement branché dessus. C'est classique, un seul préfixe — en l'occurrence :c000::/64 — est utilisé sur ce lien, et c'est suffisant. Comment crois-tu que sinon ta livebox saurait où aller chercher tous les périphériques dans ton /56 si elle devait au préalable interroger les machines branchées directement sur l'Ethernet ? (hint : il faut le temps du timeout NDP, qui n'est pas négligeable)
Alors je suis peut-être une quiche, j'ai raté un truc, je ne sais pas, mais la Livebox envoie des RA comme ça :
Non tu n'es pas une quiche, tu semble même plutôt bien informé. Regardons :
interface eth_livebox
{
[…]
AdvManagedFlag off;
Aïe ça commence mal, elle indique qu'il n'y a à priori pas de DHCPv6 sur ce réseau.
AdvOtherConfigFlag on;
Mais elle a un setup typique pour faire plaisir aux machines Windows qui n'impélementent(-aient ?) pas le RDNSS ; on sent les mecs qui veulent faire plaisir aux particularités pas très standards de MS.
Bon, du coup on sent que faire « standard » avec ce routeur va être peut-être un peu difficile.
Et j'ai essayé un client DHCPv6 : pas de réponse.
Aïe : tu as suivi la bonne piste, DHCPv6-PD étant la manière standard de déléguer un préfixe à un autre routeur, mais malheureusement les implémentations des FAI ne suivent pas.
Donc on en est là, toujours à faire du routage complexe pour rien, juste parce qu'il n'y a pas une case à cocher pour faire mieux qu'un simple /64 annoncé par la « box » elle-même, soit à peu près aussi utile que le NAT en IPv4. Oui c'est mieux, mais c'est tout aussi utile.
Effectivement. Et c'est exactement ce genre de problème qui fait partie des choses à changer pour rendre IPv6 praticable : changer la mentalité des opérateurs et leur faire comprendre qu'il faut suivre les standards. Ça n'est pas un problème technique, c'est quelque-chose de complètement politique, mais c'est indispensable pour qu'IPv6 marche bien.
Pour revenir sur l'intelligence dans le réseau je suis partagé. D'un côté, j'aime bien quand les routeurs n'en font pas trop, et de l'autre, beeeen, j'aimerais bien pouvoir choisir moi-même ce qui passe par où, sans avoir à le configurer sur toutes mes machines terminales. Du coup, en IPv4, vu qu'il y a un SNAT, c'est pas trop dur : certains paquets sont marqués par iptables, et les paquets marqués passent via la règle de SNAT différente.
Oui, l'opposition management centralisé vs. réparti aux extrémités est une question qui n'a pas de bonne réponse, et il existera toujours une tension entre les deux. Les organismes de standardisation tels que l'IETF sont remplis de gens qui ont des avis opposés là-dessus, et essayent de trouver un consensus. Néanmoins, les constatations empiriques font qu'en général, selon moi, il est plus pertinent de faire du décentralisé. Il est connu que les infrastructures réseau ont tendance à se scléroser, et que du coup toute configuration faite « au cœur » du réseau aura tendance à ne plus jamais bouger avec le temps. C'est d'après cette constatation qu'a été conçu IPv6 : il faut le protocole qui codifie le moins de choses possibles (on a dégagé la fragmentation des routeurs car ça fout la merde, encore énormément aujourd'hui en IPv4 avec la prolifération des tunnels de tunnels de tunnels et la frénésie du blackholing ICMP). Mais oui, centraliser la configuration est quelque-chose de désirable quand on administre beaucoup de machines : c'est alors qu'on invente des protocoles de configuration qui vont chercher la configuration (standardisée) de manière standard sur le réseau : c'est DHCPv6. Ainsi, tu propages ta configuration à tous les éléments de ton réseau depuis le cœur, mais sans dépendre d'un mécanisme qui va faire un truc intelligent au milieu. Pour moi, c'est le meilleur des deux mondes.
Sans parler après des problématique politiques de la volonté du réseau de contrôler ceux qui l'utilisent, quand ceux-ci sont issus d'autorités différentes : on tombe dans le débat sur la neutralité du Net. Je note en particulier que beaucoup d'admin réseau qui se bâtent pour la neutralité de leur FAI le sont beaucoup moins en ce qui concerne « leur » réseau à la maison, où leurs utilisateurs sont parfois sous la férule d'une non-neutralité imposée…
Le but, c'est bien d'éviter d'envoyer des paquets forgés via une machine potentiellement infectée.
Franchement, je suis sceptique sur l'utilité de se prémunir de ça : ton FAI filtrera de toutes façons, et si c'est comme tu dis du trafic illégitime, pas la peine d'essayer de le « traiter bien ».
Je ne pense pas qu'une telle règle filtre quoi que ce soit pour les paquets qui arrivent de l'extérieur.
On a dû mal se comprendre, je ne pense pas avoir dit ça.
La conclusion, c'est qu'il y a des centaines de personnes très qualifiées qui ont pondu un écosystème très perfectionné, et répondant parfaitement à quasiment tous les problèmes de IPv4, qui était quand même déjà bien conçu pour son époque.
C'est clair qu'IPv4 était déjà très bien foutu et est assez flexible pour s'adapter à un nombre de situations assez phénoménal. C'est le problème classique d'un protocole « assez bon » pour 80% des usages, qui fait qu'on a du mal à se motiver pour vouloir corriger les 20% restant (mais qui dans notre cas augmente de plus en plus).
Mais on se retrouve avec des tas de gens qui n'ont rien compris, ou ne veulent pas comprendre, et qui cassent tout ce beau travail.
Voilà, tu as bien compris le problème d'IPv6 : arriver à le faire comprendre. Malheureusement, avec la tendance actuelle à la pseudo-« sécurité » à tout prix, qui à tendance à favoriser le NAT pour de mauvaises raison, j'ai peur pour l'avenir d'IPv6. Mais oui, l'éducation reste la seule solution.
L’argument présenté du CDN et du CNAME est peut-être un des rares cas qui se tient vite-fait, mais à vrai dire le concept de CDN vient pallier l’absence de protocole adapté à ce besoin (par exemple des fonctionnalités de multicast, de P2P etc. changerait sérieusement la donne et serait beaucoup plus propre).
La bonne solution sans réinventer un protocole c'est de pousser à l'adoption des enregistrements SRV, qui peuvent servir aux usages pour lequel on fait habituellement du CDN tout comme d'autres choses (failover, serveur de backup, etc) : https://bugzilla.mozilla.org/show_bug.cgi?id=14328
Mais pour ça il va falloir se battre avec le code source de Firefox et la bureaucratie de Mozilla, appuyée par Google.
Et comme ça, on n'aura plus besoin de www tout en ayant bien mieux niveau fonctionnalités que ce palliatif.
Est-ce que la carte d'extension que tu présente ici est aussi ouverte que le CPU ? Ça n'a pas l'air d'être vraiment le cas : gros FPGA utilisable avec uniquement des outils proprios, IP fermées avec licences, etc. Je dis pas que c'est mal dans l'absolu, mais vu que le but du projet HiFive est de faire du matos libre, de ce que je comprends, ça fait un peu bizarre que tout ce qui permette d'en faire un desktop, qui est dans cette carte, soit fermé.
Merci d'avance pour les infos que tu pourras nous donner dessus.
Bien sûr je suis allé un peu vite, et ça n'est pas exactement cette option : celle-ci parle de la préférence d'une route qu'on annonce en particulier. La préférence du routeur en tant que routeur par défaut se fait avec :
AdvDefaultPreference low;
Bref, il y a encore quelques trucs auxquels faire attention en IPv6, mais ça avance !
Dans un monde « idéal », en IPv6, tu n'aurais pas forcément besoin de routeur intermédiaire, et tu aurais directement branché tes machinbox sur ton switch Ethernet, en précisant à ta box ADSL qu'elle est moins préférée (RFC 4191 https://tools.ietf.org/html/rfc4191), par exemple en syntaxe radvd.conf :
AdvRoutePreference low;
Et c'est tout.
Voilà, plutôt que de perdre du temps à continuer à bidouiller pour faire marcher IPv4, on pourrait se dire qu'il vaudrait mieux passer son temps à essayer de voir comment on pourrait faire mieux avec IPv6, et aider à corriger les problèmes de migration et les quelques défauts restants de ce « nouveau protocole », car oui IPv6 n'est pas parfait. À chaque fois que je dis ça on trouve mille excuses et on continue à « perdre » des millions d'heures d'ingénieur à essayer de trouver des rustines à IPv4, sans jamais s'arrêter, et sans jamais arriver à stopper l'érosion de ce protocole : on commence à ne vraiment plus avoir d'IP publique pour tout le monde, même sur les boxs, et bientôt le peer-to-peer sera tout simplement impossible. Plus personne ne pourra s'héberger, et la fiabilité du réseau sera exécrable, excepté pour ceux qui auront payé la bonne « qualité de service » (aussi bien pour les internautes que pour les fournisseurs de contenus ; notez la dichotomie, vous ne pourrez pas vous-même fournir de contenu) et seront capables de mettre les ressources serveurs adéquates en face pour mitiger le partage d'identifiant gigantesque qui arrivera, et de faire le tracking de connexion nécessaire. On arrivera bien sûr un jour à la limite du partage IP + port (ça n'ajoute que 16 bits en plus), et ça sera encore plus drôle à ce moment-là (j'imagine qu'on essayera de faire du multiplexage à l'intérieur de connexion TCP, voire UDP ; oups pardon https://en.wikipedia.org/wiki/Quic certains ont déjà prévu ce beau futur…).
Le multihoming — connecter son réseau à plusieurs fournisseurs d'accès — n'est pas un problème simple, et IPv6 n'a pas forcément de solution idéale à ce problème, mais le setup que je décrie respecte les principes de base de l'architecture d'Internet : l'intelligence n'est pas dans le réseau, et les décisions sur quelle liaison utiliser reviendraient aux machines utilisateur. Ça permet également de déporter la décision d'utiliser l'ADSL pour une raison particulière directement aux applications qui tournes sur les « extrémités » du réseau, sans avoir à toucher à un élément soit-disant intelligent au milieu (ton routeur). On ne fait également pas de routage source-specific (ton mangle + rule), qui est en général prompt aux erreurs de routage, cf. ton rp_filter qui est mignon, mais on voit bien que c'est chiant à gérer.
Note que si tu voulais un routeur intermédiaire — qui annoncerait deux préfixes issus de chacun des préfixe délégués plus larges alloués par chacun de tes opérateurs —, tu aurais toute de même à faire du routage source-specific avec un petit "ip rule" pour éviter le filtrage des opérateurs sur la source (BCP 38 https://tools.ietf.org/html/rfc2827 ; un peu comme ton rp_filter, en fait), mais ça se ferait sans marquage ni rien de compliqué, juste avec une sélection sur le préfixe utilisé en source qui détermine le next-hop adéquat :
ip -6 rule add from 2001:db8:1::/64 table isp1
ip -6 rule add from 2001:db8:2::/64 table isp2
ip -6 route add default table isp1 via fe80::XXX dev eth_livebox
ip -6 route add default table isp2 via fe80::XXX dev eth_adsl
Voilà. Pas d'état, pas de tracking, ça ne prend pas de mémoire, pas de resource, ça scale jusqu'à des Tbps, etc.
Bref, merci quand même pour ton journal, c'est marrant le « routage avancé » en IPv4, mais ça ne résoudra jamais le problème existentiel de l'Internet de l'ancien monde qui est en train de se dégrader : ça permettra juste à « ceux qui connaissent » de tenir encore un peu mieux que les autres, mais c'est tout. La seule solution universelle et durable s'appelle IPv6.
La critique du « besoin de défiscaliser » vient du fait que souvent, les personnes qui le font aiment bien critiquer en passant « l'État qui nous taxe tant », tout en grévant du budget de l'État la partie qui sera non-prélevée du fait du don. C'est en quelques sortes une manière d'orienter personnellement la politique d'investissement de l'État, tout en le critiquant, et tout ça au détriment de ce que l'État a désigné comme relevant du bien commun.
Donc non, ça n'est pas un fantasme, c'est une manière de promouvoir la liberté individuelle face au bien collectif, et de se faire mousser au passage avec de l'argent qui aurait sinon profité à tous.
Posté par benoar .
En réponse à la dépêche Firefox 61 & 62.
Évalué à 5.
Dernière modification le 21 septembre 2018 à 16:50.
Commentaire de Marco Bonardio, de Mozilla il semble, à propos du fait que la suppression de cette feature risque de faire perdre les descriptions précédemment stockées par ceux qui l'utilisaient :
I can't trust Mozilla with my data.)
FWIW, you can't trust anything regarding dataloss, that's why backup systems exist. Your hard drive could break tomorrow, or your OS may corrupt yesterday. You can't even trust your NAS unless it's enterprise grade (and still). I don't think this is a problem with Mozilla as it is not with any other company in the world.
Déjà depuis début 2016. Bon, je suppose que MS était en discussion depuis quelques temps avec GitHub avant de les acheter, donc ils auraient peut-être pu influencer les choix avant cette année, mais là ça commence à faire loin. Je ne sais pas trop quoi en penser.
Mais c'est sûr que maintenant, je pense que tu auras tout le mal du monde à essayer de faire accepter les od* en plus…
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 9. Dernière modification le 15 octobre 2018 à 09:59.
Merci, il faudrait le dire tellement haut et fort : il y a plein de pseudo-« génies » qui se tripotent la nouille en montant des setup haute-dispo blah blah (que ça soit du proprio ou du libre, hein), qui nécessitent des machines et des softs titanesques, qui passent des semaines à le configurer, et qu'il ne faut surtout pas toucher après sinon tout pète… et ça finit toujours par péter un jour, sans personne d'assez compétent pour le réparer (ou alors des consultants payés une blinde). Alors on passe à la prochaine techno à la mode…
Mais c'est un moyen d'attirer les financements, et comme de toutes façons aujourd'hui les financements humain et fournitures sont séparés (je parle toujours du public), bah au lieu d'embaucher quelqu'un qui se démerde un peu avec une Debian et du matos basique, t'es obligé d'acheter des bouses gigantesques et gérer la merde après.
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
C'est marrant que tu me parles de Yocto, je me le tape tous les jours et je peux te le dire : Yocto n'a pas du tout la bonne approche. Rebuilder depuis les sources à chaque fois, sans reproductibilité binaire, ça n'est pas la bonne manière de faire. C'est même idiot. Voir comment font les distros classique pour comprendre pourquoi.
C'est comme ce que j'ai dit au-dessus à propos de ne pas avoir à relancer le configure à chaque make : ça serait débile.
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 7.
Bah je sais pas, on nous balance le cloud comme si c'était une techno révolutionnaire qui changerait tout… comme dit Sytoka plus haut, s'héberger soi-même ça se fait depuis toujours. Certes, pas avec toutes les fonctionnalités avancées du could d'aujourd'hui, mais je ne vois pas en quoi ça serait un truc tellement difficile qu'on en serait obligé à passer uniquement par des américains. D'où le fait qu'Albert n'ait pas à citer de solution pour qu'on comprenne que quand même, ça n'est pas impossible de faire sans les US.
Ce qui me fait peur, c'est que justement on trouve ça aujourd'hui impossible de s'héberger, alors que c'était la norme avant ! Cela sous-entend que les mentalités ont bien été manipulées par les vendeurs de cloud pour qu'on ait oublié cette époque. (encore une fois, je comprends que c'est moins pratique que du cloud, mais de là à trouver ça impossible…)
Donc c'était de l'ironie ? Désolé de pas t'avoir compris alors.
Je savais pas qu'OVH c'était vu VMWare… c'est triste.
Si je peux me permettre de dévier un peu, je trouve ça triste à quel point aujourd'hui on trouve qu'héberger et administrer des machines ça soit vu comme une tâche insurmontable partout : je vois effectivement que beaucoup de monde le constate, alors qu'on avait pas mal de connaissance avant.
Mon expérience perso dans un établissement public (anecdotique, certes) montre qu'une Debian bien configurée avec du libvirt/kvm plus quelques scripts maisons, avec un ingé qui se démerde un peu, ça tient tout seul, même sur du long terme (mon travail a survécu à l'arrivée et la fin d'un Openstack, qui devait être la panacée…).
# Réaction liée
Posté par benoar . En réponse au journal Un développeur qui dénonce. Évalué à 2.
Une autre réaction d'un développeur français un peu connu, qui acquiesce :
http://fabiensanglard.net/bloated/index.php
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 8.
Je trouve dommage que tu plonges dans la fausse dichotomie qui oblige à « tout accepter » à moins de vouloir revenir à l'âge de pierre. C'est un piège rhétorique classique il me semble. Ça a toujours été utilisé pour décrédibiliser le projet GNU, alors que le seul moyen à long terme d'y arriver est d'effectivement de refuser tout logiciel privateur.
Par contre, ceux qui sont étonnés de la migration vers Azure des administrations… comment s'en étonner quand ça fait 30 ans que MS pilonne les écoles et les administrations, qui le lui rendent bien financièrement parlant ? Ce n'est que la suite logique. L'ennemi n'a pas changé de camp…
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 5.
Je ne suis pas d'accord que ça soit un usage « totalement à la marge » : le projet GNU a établit des standards https://www.gnu.org/prep/standards/standards.html qui, lorsqu'ils sont suivis (en utilisant les autotools) permettent de correctement distribuer un travail (on parle de « distribution » dans la terminologie autotools pour désigner un tarball d'une version donnée d'un logiciel). Ça n'est pas non plus un gestionnaire de paquet complet : c'est un entre deux, mais c'est bien plus que simplement un système de build. Je l'avais décrit comme permettant de faire bien plus que juste compiler dans une présentation que j'avais faite http://dolka.fr/bazar/atelier_empaquetage_facon_GNU/atelier_empaquetage_facon_GNU.pres.html : ça permet de distribuer, d'informer de la licence, de faciliter la reproductibilité et la disponibilité des sources. Des choses qui sont plutôt l'apanage des système de gestion de paquet d'habitude (comme celui de Debian, qui couvre tous ces aspects également).
Voir également https://www.gnu.org/software/automake/manual/automake.html#Introducing-the-GNU-Build-System
L'inconvénient que tu citais plus haut sur les perfs, je ne comprends pas : le configure n'est fait qu'une fois, après tu "make" quand tu changes un fichier et c'est très rapide.
Bien sûr, comme tout système qui se veut être le seul standard, d'autres sont venus le contredire, et les « distributions » au sens classique du terme (ensemble de logiciels intégrés avec un noyau) sont venu « uniformiser » ça ; bien sûr, on a eu plusieurs distributions…
Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 6.
Ça l'était à une époque. Et ma remarque était pour dire qu'en gros, si tu veux compiler un outil depuis les sources, bien sûr qu'il faut un compilateur, mais tu n'auras pas besoin de télécharger le dernier outil de build à la mode : tout ce qui est hors des outils que tu cites et qui sont historiquement considérés comme « standards » est superflu.
Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
Comme dit Matthieu, le cas « utilisateur qui compile et modifie éventuellement » peut paraître étrange par rapport au dev qui veut modifier la procédure de build et plus, mais c'est une dichotomie qui valait à une certaine époque et que je trouve toujours bonne pour un paquet de projets aujourd'hui. La preuve par cette news elle-même : c'est encore un nouveau standard nécessaire pour compiler X projets. Autotools ne sera jamais nécessaire pour un développeur qui fait des modifications minimes.
[^] # Re: C'est à Paris Saclay
Posté par benoar . En réponse au journal (relais) Poste à la fondation Inria pour travailler sur scikit-learn. Évalué à 10.
Oui, c'est là que je l'ai vu. C'était juste pour présenter l'information directement ici, pour éviter à ceux qui ne cherchent pas en région parisienne d'avoir l'info direct (il me semble que c'est une des informations essentielles d'une annonce).
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 5.
Tu n'as effectivement pas compris. Les prérequis d'un configure sont très simples : un shell et les outils Unix de base. C'est d'ailleurs la raison de sa « lourdeur » : il fait tout avec ces prérequis très minimaux, ce qui est assez contraignant, et oblige à plein de contournements lourds en ressources.
De même, tu n'auras pas besoin des autotools tant que tu ne fais pas de modification du système de build lui-même : tu peux modifier les fichiers source et recompiler sans avoir les autotools. Un ajout de fichier ou de dépendance de bibliothèque, par contre, t'obligera à les avoir, et faire un coup d'autoreconf.
# C'est à Paris Saclay
Posté par benoar . En réponse au journal (relais) Poste à la fondation Inria pour travailler sur scikit-learn. Évalué à 10.
Pour ceux qui ne s'en doutaient pas, quand une annonce omet le lieu, c'est sous-entendu Paris (ici Saclay plus précisément).
Merci. Un provincial.
[^] # Re: Pourquoi réinventer la roue ?
Posté par benoar . En réponse à la dépêche Des fichiers EPUB avec LibreOffice 6.1 sans extension. Évalué à 3.
Mouarf, comment tu choisis tes passages ; à peu près l'ensemble de l'article critique le résultat qui contient un nombre assez énorme d'erreurs. La conclusion que tu cites est le début, sous forme d'encouragement, mais la suite dit :
En gros, ça marche si ton document n'a pas de style.
[^] # Re: www ou non
Posté par benoar . En réponse à la dépêche Évolution des hyperliens sur LinuxFr.org. Évalué à 4.
Oui, le combat est politique : sans cette feature, il est difficile de s'héberger correctement (complexité de la gestion de TLS, complexité sur failover sans CDN, etc) avec des moyens raisonnables, sans être un « gros ». Étrangement, parmi ceux qui s'opposent dans ce rapport de bug à la résolution de ce problème par des entrées SRV avec des arguments plus ou moins valable, on trouve des ingénieurs de chez Google. Et Google finance Mozilla. Forcément, ça doit donner envie de laisser traîner la résolution…
[^] # Re: Timeout
Posté par benoar . En réponse au journal Horodater un cambriolage avec des logs. Évalué à 4.
Ah, je n'avais pas capté que tu trouvais ce log confus : il indique que le client se connectant à machine1, donc ton premier client SSH depuis ton poste au boulot, s'est déconnecté volontairement car la commande qu'il a lancé à l'intérieur (qui n'est pas un shell), c-à-d le ssh sur machine2, a quitté, pour quelque raison que ce soit. Dans ton cas, ce second SSH a dû faire un timeout et tu n'as pas de trace, mais du point de vue de machine1 ta session a été fermée volontairement parce que la commande à l'intérieur s'est terminée, c'est tout.
En ce qui concerne l'aide que ça pourra apporter à la police, si tu as un horodatage précis, ça pourra éventuellement aider à retracer en croisant avec d'autres sources précises comme des caméras de surveillance (expérience perso).
[^] # Re: Timeout
Posté par benoar . En réponse au journal Horodater un cambriolage avec des logs. Évalué à 3.
Effectivement, mais pour ce paramètre il faudrait la conf de machine2… Pour le client, il faudrait voir la conf de machine1, en particulier ServerAliveInterval, qui n'est pas active par défaut.
De plus, si ce sont les paramètre du kernel uniquement qui sont concernés, ça dépend de plusieurs paramètres : tcp_keepalive_time qui est de 2h (début du test de transmission d'une connexion inactive), ou tcp_retries2 qui indique qu'une connexion « perdue » mettra environ 1000 s minimum avant d'être cassée de force. Du coup ça dépend de l'activité de cette connexion ; je suppose qu'une session X active dessus fait qu'elle était plutôt occupée, et que le keepalive ne compte donc pas vraiment.
Bon courage pour la suite des affaires en tous cas.
[^] # Re: Ouverture de la carte d'extension ?
Posté par benoar . En réponse au journal Risc-V est prêt pour le desktop™ !. Évalué à 4.
Oui, c'est clair que le monde du FPGA c'est pas la joie niveau ouverture. Je ne suis pas convaincu que l'arrivée d'un nouveau concurrent change quoi que ce soit, mais on peut toujours rêver.
Merci pour la confirmation en tous cas.
[^] # Re: Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. Évalué à 4.
La livebox a un /56, mais ça ne de dit pas comment elle le route. Visiblement, :c001::/64 n'est pas un préfixe sur le lien Ethernet directement branché dessus. C'est classique, un seul préfixe — en l'occurrence :c000::/64 — est utilisé sur ce lien, et c'est suffisant. Comment crois-tu que sinon ta livebox saurait où aller chercher tous les périphériques dans ton /56 si elle devait au préalable interroger les machines branchées directement sur l'Ethernet ? (hint : il faut le temps du timeout NDP, qui n'est pas négligeable)
Non tu n'es pas une quiche, tu semble même plutôt bien informé. Regardons :
Aïe ça commence mal, elle indique qu'il n'y a à priori pas de DHCPv6 sur ce réseau.
Mais elle a un setup typique pour faire plaisir aux machines Windows qui n'impélementent(-aient ?) pas le RDNSS ; on sent les mecs qui veulent faire plaisir aux particularités pas très standards de MS.
Et qui est du genre neuneu-proof.
Donc, le préfixe que tu utilises normalement.
Une jolie configuration DNS par IPv6, bien.
Ils n'ont pas l'air d'aimer suivre les standard http://www.bortzmeyer.org/7788.html même si la pratique « de fait » de ce genre de réservation sauvage à conduit à laisser faire ce genre de truc http://www.bortzmeyer.org/8244.html.
Bon, du coup on sent que faire « standard » avec ce routeur va être peut-être un peu difficile.
Aïe : tu as suivi la bonne piste, DHCPv6-PD étant la manière standard de déléguer un préfixe à un autre routeur, mais malheureusement les implémentations des FAI ne suivent pas.
Effectivement. Et c'est exactement ce genre de problème qui fait partie des choses à changer pour rendre IPv6 praticable : changer la mentalité des opérateurs et leur faire comprendre qu'il faut suivre les standards. Ça n'est pas un problème technique, c'est quelque-chose de complètement politique, mais c'est indispensable pour qu'IPv6 marche bien.
Oui, l'opposition management centralisé vs. réparti aux extrémités est une question qui n'a pas de bonne réponse, et il existera toujours une tension entre les deux. Les organismes de standardisation tels que l'IETF sont remplis de gens qui ont des avis opposés là-dessus, et essayent de trouver un consensus. Néanmoins, les constatations empiriques font qu'en général, selon moi, il est plus pertinent de faire du décentralisé. Il est connu que les infrastructures réseau ont tendance à se scléroser, et que du coup toute configuration faite « au cœur » du réseau aura tendance à ne plus jamais bouger avec le temps. C'est d'après cette constatation qu'a été conçu IPv6 : il faut le protocole qui codifie le moins de choses possibles (on a dégagé la fragmentation des routeurs car ça fout la merde, encore énormément aujourd'hui en IPv4 avec la prolifération des tunnels de tunnels de tunnels et la frénésie du blackholing ICMP). Mais oui, centraliser la configuration est quelque-chose de désirable quand on administre beaucoup de machines : c'est alors qu'on invente des protocoles de configuration qui vont chercher la configuration (standardisée) de manière standard sur le réseau : c'est DHCPv6. Ainsi, tu propages ta configuration à tous les éléments de ton réseau depuis le cœur, mais sans dépendre d'un mécanisme qui va faire un truc intelligent au milieu. Pour moi, c'est le meilleur des deux mondes.
Sans parler après des problématique politiques de la volonté du réseau de contrôler ceux qui l'utilisent, quand ceux-ci sont issus d'autorités différentes : on tombe dans le débat sur la neutralité du Net. Je note en particulier que beaucoup d'admin réseau qui se bâtent pour la neutralité de leur FAI le sont beaucoup moins en ce qui concerne « leur » réseau à la maison, où leurs utilisateurs sont parfois sous la férule d'une non-neutralité imposée…
Franchement, je suis sceptique sur l'utilité de se prémunir de ça : ton FAI filtrera de toutes façons, et si c'est comme tu dis du trafic illégitime, pas la peine d'essayer de le « traiter bien ».
On a dû mal se comprendre, je ne pense pas avoir dit ça.
C'est clair qu'IPv4 était déjà très bien foutu et est assez flexible pour s'adapter à un nombre de situations assez phénoménal. C'est le problème classique d'un protocole « assez bon » pour 80% des usages, qui fait qu'on a du mal à se motiver pour vouloir corriger les 20% restant (mais qui dans notre cas augmente de plus en plus).
Voilà, tu as bien compris le problème d'IPv6 : arriver à le faire comprendre. Malheureusement, avec la tendance actuelle à la pseudo-« sécurité » à tout prix, qui à tendance à favoriser le NAT pour de mauvaises raison, j'ai peur pour l'avenir d'IPv6. Mais oui, l'éducation reste la seule solution.
[^] # Re: www ou non
Posté par benoar . En réponse à la dépêche Évolution des hyperliens sur LinuxFr.org. Évalué à 4.
La bonne solution sans réinventer un protocole c'est de pousser à l'adoption des enregistrements SRV, qui peuvent servir aux usages pour lequel on fait habituellement du CDN tout comme d'autres choses (failover, serveur de backup, etc) : https://bugzilla.mozilla.org/show_bug.cgi?id=14328
Mais pour ça il va falloir se battre avec le code source de Firefox et la bureaucratie de Mozilla, appuyée par Google.
Et comme ça, on n'aura plus besoin de www tout en ayant bien mieux niveau fonctionnalités que ce palliatif.
# Ouverture de la carte d'extension ?
Posté par benoar . En réponse au journal Risc-V est prêt pour le desktop™ !. Évalué à 2.
Est-ce que la carte d'extension que tu présente ici est aussi ouverte que le CPU ? Ça n'a pas l'air d'être vraiment le cas : gros FPGA utilisable avec uniquement des outils proprios, IP fermées avec licences, etc. Je dis pas que c'est mal dans l'absolu, mais vu que le but du projet HiFive est de faire du matos libre, de ce que je comprends, ça fait un peu bizarre que tout ce qui permette d'en faire un desktop, qui est dans cette carte, soit fermé.
Merci d'avance pour les infos que tu pourras nous donner dessus.
[^] # Re: Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. Évalué à 4.
Bien sûr je suis allé un peu vite, et ça n'est pas exactement cette option : celle-ci parle de la préférence d'une route qu'on annonce en particulier. La préférence du routeur en tant que routeur par défaut se fait avec :
Bref, il y a encore quelques trucs auxquels faire attention en IPv6, mais ça avance !
# Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. Évalué à 10.
Dans un monde « idéal », en IPv6, tu n'aurais pas forcément besoin de routeur intermédiaire, et tu aurais directement branché tes machinbox sur ton switch Ethernet, en précisant à ta box ADSL qu'elle est moins préférée (RFC 4191 https://tools.ietf.org/html/rfc4191), par exemple en syntaxe radvd.conf :
Et c'est tout.
Voilà, plutôt que de perdre du temps à continuer à bidouiller pour faire marcher IPv4, on pourrait se dire qu'il vaudrait mieux passer son temps à essayer de voir comment on pourrait faire mieux avec IPv6, et aider à corriger les problèmes de migration et les quelques défauts restants de ce « nouveau protocole », car oui IPv6 n'est pas parfait. À chaque fois que je dis ça on trouve mille excuses et on continue à « perdre » des millions d'heures d'ingénieur à essayer de trouver des rustines à IPv4, sans jamais s'arrêter, et sans jamais arriver à stopper l'érosion de ce protocole : on commence à ne vraiment plus avoir d'IP publique pour tout le monde, même sur les boxs, et bientôt le peer-to-peer sera tout simplement impossible. Plus personne ne pourra s'héberger, et la fiabilité du réseau sera exécrable, excepté pour ceux qui auront payé la bonne « qualité de service » (aussi bien pour les internautes que pour les fournisseurs de contenus ; notez la dichotomie, vous ne pourrez pas vous-même fournir de contenu) et seront capables de mettre les ressources serveurs adéquates en face pour mitiger le partage d'identifiant gigantesque qui arrivera, et de faire le tracking de connexion nécessaire. On arrivera bien sûr un jour à la limite du partage IP + port (ça n'ajoute que 16 bits en plus), et ça sera encore plus drôle à ce moment-là (j'imagine qu'on essayera de faire du multiplexage à l'intérieur de connexion TCP, voire UDP ; oups pardon https://en.wikipedia.org/wiki/Quic certains ont déjà prévu ce beau futur…).
Le multihoming — connecter son réseau à plusieurs fournisseurs d'accès — n'est pas un problème simple, et IPv6 n'a pas forcément de solution idéale à ce problème, mais le setup que je décrie respecte les principes de base de l'architecture d'Internet : l'intelligence n'est pas dans le réseau, et les décisions sur quelle liaison utiliser reviendraient aux machines utilisateur. Ça permet également de déporter la décision d'utiliser l'ADSL pour une raison particulière directement aux applications qui tournes sur les « extrémités » du réseau, sans avoir à toucher à un élément soit-disant intelligent au milieu (ton routeur). On ne fait également pas de routage source-specific (ton mangle + rule), qui est en général prompt aux erreurs de routage, cf. ton rp_filter qui est mignon, mais on voit bien que c'est chiant à gérer.
Note que si tu voulais un routeur intermédiaire — qui annoncerait deux préfixes issus de chacun des préfixe délégués plus larges alloués par chacun de tes opérateurs —, tu aurais toute de même à faire du routage source-specific avec un petit "ip rule" pour éviter le filtrage des opérateurs sur la source (BCP 38 https://tools.ietf.org/html/rfc2827 ; un peu comme ton rp_filter, en fait), mais ça se ferait sans marquage ni rien de compliqué, juste avec une sélection sur le préfixe utilisé en source qui détermine le next-hop adéquat :
Voilà. Pas d'état, pas de tracking, ça ne prend pas de mémoire, pas de resource, ça scale jusqu'à des Tbps, etc.
Bref, merci quand même pour ton journal, c'est marrant le « routage avancé » en IPv4, mais ça ne résoudra jamais le problème existentiel de l'Internet de l'ancien monde qui est en train de se dégrader : ça permettra juste à « ceux qui connaissent » de tenir encore un peu mieux que les autres, mais c'est tout. La seule solution universelle et durable s'appelle IPv6.
[^] # Re: [HS] "besoin de défiscaliser "
Posté par benoar . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 7.
La critique du « besoin de défiscaliser » vient du fait que souvent, les personnes qui le font aiment bien critiquer en passant « l'État qui nous taxe tant », tout en grévant du budget de l'État la partie qui sera non-prélevée du fait du don. C'est en quelques sortes une manière d'orienter personnellement la politique d'investissement de l'État, tout en le critiquant, et tout ça au détriment de ce que l'État a désigné comme relevant du bien commun.
Donc non, ça n'est pas un fantasme, c'est une manière de promouvoir la liberté individuelle face au bien collectif, et de se faire mousser au passage avec de l'argent qui aurait sinon profité à tous.
[^] # Re: Mes descriptions...
Posté par benoar . En réponse à la dépêche Firefox 61 & 62. Évalué à 5. Dernière modification le 21 septembre 2018 à 16:50.
Commentaire de Marco Bonardio, de Mozilla il semble, à propos du fait que la suppression de cette feature risque de faire perdre les descriptions précédemment stockées par ceux qui l'utilisaient :
Avec cette mentalité, forcément…
[^] # Re: C'est vieux apparemment
Posté par benoar . En réponse au message Github ne supporte pas (les fichiers) libreoffice (en pièces jointes des tickets) ?. Évalué à 3.
Et je pourrais dire « LOL », dans une annonce vaguement liée à ce sujet, Google vient d'investir 100 M$ dans GitLab : https://www.latribune.fr/technos-medias/internet/logiciel-libre-gitlab-leve-100-millions-de-dollars-et-devient-une-licorne-791109.html
Bref, si vous voulez un peu plus de contrôle sur votre hébergement de projet, hébergez-le vous-même.
# C'est vieux apparemment
Posté par benoar . En réponse au message Github ne supporte pas (les fichiers) libreoffice (en pièces jointes des tickets) ?. Évalué à 3.
Je me demandais si c'était arrivé après le rachat par MS. Ça ne semble pas le cas :
http://web.archive.org/web/20160316000110/https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/
Déjà depuis début 2016. Bon, je suppose que MS était en discussion depuis quelques temps avec GitHub avant de les acheter, donc ils auraient peut-être pu influencer les choix avant cette année, mais là ça commence à faire loin. Je ne sais pas trop quoi en penser.
Mais c'est sûr que maintenant, je pense que tu auras tout le mal du monde à essayer de faire accepter les od* en plus…
[^] # Re: Chez la concurrence
Posté par benoar . En réponse au journal Btrfs restore à la rescousse. Évalué à 2.
man qemu-system :
Mais tu ne vas pas aller très loin avec ton système qui ne pourra rien écrire sur le disque.