Mais qu'est ce que vient foutre un outil de Virtualisation dans tout les OS si la version d'après plus rien n'est supporté, sérieusement c'est quoi cette organisation ?
OpenVZ se souciait surtout de RedHat6 / CentOS6 d'où le choix du kernel 2.6.32.
/etc/rc.conf bha oui uniquement les services de l'OS encore heureux que la configuration de nginx se fait dans son fichier !! Honnêtement pour répondre à ceux qui demandent si ça répond à tout mes besoins, mais bien sur que voulez-vous de plus simple bon sang ?!!
Avec NixOS le fichier /etc/nixos/configuration.nix contient toute la conf du système et des logiciels. Rien qu'avec ce fichier tu peux dupliquer/reconstruire ton serveur en quelques commandes (faut juste penser à copier les données persistantes, s'il y en a). Moi j'adore.
Après attention je ne dis pas que FreeBSD est le super OS qui est avance sur tout qui répond à tout (toute la gestion Clustering H/A, virtu c'est bien à la ramasse, on est d'accord, mais ça bouge et plutôt que d'aller vite, ça avance de façon réfléchit et maitrisé et cohérente ).
Ben le titre de ton article laisse penser que Debian c'est de la merde quand même, d'où l'hostilité récoltée.
Concernant l'environnement Pro, FreeBSD ça existe, mais plutôt dans l'embarqué j'ai l'impression : FreeNAS, pfSense, et probablement d'autres appliances plus ou moins connues. C'est probablement du à l'aisance avec laquelle on peut construire un système minimaliste (NanoBSD) et ça marche plutôt bien.
Mais il faut voir que Red Hat a un poids énorme en terme de contribution et de parts de marché, ça donne une crédibilité importante à Linux sur les serveurs.
C'est pas vendredi. Pour avoir longuement utilisé les deux, je propose d'apporter les précisions suivantes :
OpenVZ n'est pas upstream, c'est de leur faute s'ils n'ont longtemps supporté que le kernel 2.6.32, pas celle de Debian. Après des années et des années de "oui, on réécrit ça en upstream dans le kernel, c'est pour bientôt" je ne sais pas si ça a fini par évoluer. C'est dommage car oui c'est probablement le meilleur truc pour faire des vps bien isolés et pilotables.
La documentation de FreeBSD est bien mais : elle reste légère (pour les jails c'est pas très clair je trouve), elle ne couvre que le système de base (alors que dans la vraie vie tu va avoir besoin des ports/packages sinon tu fais pas grand chose). Tu va me dire qu'il y a les manpage, mais pour moi rien ne vaut des exemples pratiques pour comprendre une techno. Pour debian tu as une énorme communauté d'utilisateurs (blogs, stackoverflow, collègues…) qui n'est pas négligeable. J'accorde cependant que les logiciels de base de FreeBSD ont tous une conf humainement lisible et compréhensible.
Oui LXC c'est bancal, c'est un autre point que j'accorde. Je rajoute que sous Wheezy il y avait un bug qui faisait que certains templates ne marchait pas et le mainteneur était de mauvaise foi ("oui mais sous Sid ça marche"), les utilisateurs ont du monter un mini scandale pour que ce soit corrigé. Sous Linux on ne sait jamais quel système de container/virtualisation sera mature ou upstream l'année prochaine. Mais basiquement aujourd'hui tout le monde a les yeux rivés sur Docker pour les containers et KVM pour la virtualisation.
Iptables ça se discute, perso je suis habitué à leur syntaxe. Par contre je regrette qu'il n'y ait pas de daemon officiel pour charger les règles au démarrage, tout le monde y va de sa sauce (édition du /etc/rc.local, unit systemd…).
La base n'est pas mélangée avec les packets : bouais là encore l'intérêt se discute. Sur debian le même soin est apporté au système de base ou aux logiciels tiers (qui n'ont même pas de distinction). Sur FreeBSD, par expérience j'ai toujours fini par avoir des problèmes avec pkg upgrade à cause des logiciels tiers en rolling release. Le dernier en date c'était deluge (dépendance python ou liboost pétée je crois). Sous debian c'est figé il n'y a pas de surprise (ou rarement, et le mainteneur corrige). Ou encore cet aspect rolling release fait que les fichiers de conf peuvent changer, moi j'avais tout automatisé avec Ansible, et suite à une maj mon playbook ne fonctionnait plus (unbound qui intégrait deux lignes "listen" au lieu d'une, soudainement).
Le /etc/rc.conf : mouais, ça ne concerne que les logiciels de base de FreeBSD, par exemple si tu installe nginx à partir des ports tu aura toujours un /usr/local/etc/nginx/nginx.conf à gérer hein. Faut penser à tout l'écosystème qui va avec.
Point que je rajoute : FreeBSD n'a pas systemd. Si vous mettez de côté tout le FUD qu'on a fait sur cette techno et essayez d'écrire un service ou un container (systemd-nspawn) vous verrez que c'est génial, unifié, et qu'on gagne un temps fou. Jetez un oeil à l'init de nginx et à son unit systemd, le second est tellement plus simple et lisible. Chaque fois que j'ai du bidouiller un init pour FreeBSD je me suis dit "putain, j'y ai passé des heures alors qu'avec systemd j'aurais juste mis ma commande, mon user et hop".
Après c'est sûr que FreeBSD est un super OS, de part son support natif de ZFS, son développement rapide, sa grande compatibilité hardware, ses jails, ses services réseau. Mais perso par expérience j'en reviens toujours à Debian qui est plus universel, qui est figé (pas de rolling release), mais c'est un choix.
sous GNU/Linux, il fallait taper la touche backspace 27 fois d’affilée pour bypasser la sécurité,
Si tu fais référence au "bug" du prompt de chiffrement qui te renvoie en root, ce n'est pas du tout un bypass de sécurité, les volumes restent chiffrés et heureusement (si on pouvait péter un chiffrement AES rien qu'avec des appuis sur une touche, ça se saurait et on pourrait abandonner les ordinateurs quantiques).
Mais après tu as raison sur le fait qu'aucun système n'est sûr. Là aussi ça se saurait.
Hum il y a quand même une différence entre "travailler" et "passer du temps au travail". Je suis physiquement présent au bureau 42,5h / semaine mais en enlevant les pauses je descend à 35h. Mais c'est bien ça permet de se rendre compte à quel point on passe nos vies au bureau (et encore je suis chanceux).
Nous n'avons jamais eu de split brain.
C'est arrivé qu'un serveur tombe, quand il remonte il se reconstruit. Et nous n'avons jamais eu de peer offline.
Mais oui dans l'idéal ce serai sûrement plus sûr d'en avoir 3.
On ne bosse qu'avec deux serveurs donc en replica 2, et en LAN. Pas de souci de reconnexion.
Par contre dans les dossiers contenant de très nombreux fichiers il y a quelques latences, notamment pour ls.
Cette confusion entre les journaux et les dépêches est favorisée par la terminologie elle‐même ! Journaux et dépêches, c’est quand même très similaires.
En effet… je n'ai jamais compris la différence entre les deux et je ne comprends pas pourquoi ils existent. Pourquoi n'y aurait-il pas une seule page "news" ou "articles" ?
On bosse avec de vielles versions de gluster et on en est plutôt contents. C'est très résilient, on a jamais perdu de données. C'est pas trop lourd pour les serveurs, ils peuvent même faire office de brick+client "croisés" (pas besoin d'un nas dédié, même si c'est quand même plus propre). On a juste eu des problèmes la fois où on a voulu connecter un client récent à un vieux serveur: tout le cluster est tombé, moralité il faut utiliser les mêmes versions partout. Mais sinon c'est solide.
On utilise Ceph pour stocker des VMs sur une ferme d'hyperviseurs Xen. Ça nécessite du lourd, minimum 3 serveurs avec beaucoup de RAM (8GB mini) et des SSD pour le journal. L'architecture Ceph est beaucoup plus complexe que Gluster et en cas de pépin il faut savoir s'en sortir. Au niveau intégrité des données nous n'avons jamais eu de soucis, par contre nous avons déjà eu 2 incidents qui ont fait tomber le cluster alors qu'un gluster aurait tenu. Nous avons aussi un bug qui fait gonfler les nodes en ram, c'est visiblement un souci upstream et nous attendons un correctif (bon c'est pas trop critique, il y a 1 petite commande à faire pour vider la ram sans devoir redémarrer).
Sinon comme on l'a déjà dit, Gluster c'est pour du stockage fichiers alors que Ceph c'est block (bien qu'il existe CephFS, mais je n'ai jamais testé).
Hm, Gluster fait de la répli niveau block ? Il me semble que c'est au niveau fichiers uniquement.
Sinon ouais Ceph, mais il faut une grosse infra (3 serveurs bien dimensionnés) et il faut savoir faire face en cas d'incident car dans mon expérience c'est très résilient (on a jamais perdu de données) mais au niveau continuité de service c'est pas trop ça (des petits incidents qui n'auraient pas du avoir d'impact mais qui font tomber le cluster).
En terme de performances brutes je ne sais pas car je n'ai jamais fais de comparaison, mais en terme de fiabilité c'est le jour et la nuit d'après mon expérience à la fois sur du sparc64 (plus depuis 2014 comme du Power (jusqu'en 2016).
Heu… quel genre de soucis recontres-tu sur des serveurs x86_64 exactement ? Perso j'ai pas à m'en plaindre. Ou alors tu parles des workstations ?
Posté par MTux .
En réponse à la dépêche Haiku a 16 ans.
Évalué à 4.
Dernière modification le 27 août 2017 à 23:16.
$ wget https://download.haiku-os.org/nightly-images/x86_64/current-anyboot
--2017-08-27 23:00:56-- https://download.haiku-os.org/nightly-images/x86_64/current-anyboot
Résolution de download.haiku-os.org (download.haiku-os.org)… 2a01:4f8:190:64c3::2, 78.46.189.196
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:443… connecté.
requête HTTP transmise, en attente de la réponse… 302 Moved Temporarily
Emplacement : http://download.haiku-os.org:8081/nightly-images/x86_64/haiku-nightly-hrev51382-x86_64-anyboot.zip [suivant]
--2017-08-27 23:00:56-- http://download.haiku-os.org:8081/nightly-images/x86_64/haiku-nightly-hrev51382-x86_64-anyboot.zip
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:8081… échec : Connexion terminée par expiration du délai d'attente.
Connexion à download.haiku-os.org (download.haiku-os.org)|78.46.189.196|:8081… échec : Connexion terminée par expiration du délai d'attente.
Résolution de download.haiku-os.org (download.haiku-os.org)… 2a01:4f8:190:64c3::2, 78.46.189.196
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:8081… échec : Connexion terminée par expiration du délai d'attente.
Connexion à download.haiku-os.org (download.haiku-os.org)|78.46.189.196|:8081… échec : Connexion terminée par expiration du délai d'attente.
Nouvel essai.
Ou alors tu fais un UPDATE table SET row1='value' WHERE row1 LIKE '%pattern%', c'est tout l'intérêt d'une base de données (manipuler des données), c'est pour ça que je postais le commentaire (tu dump ta bdd pour faire un grep dedans au lieu de faire directement un SELECT * FROM table WHERE row1 LIKE '%pattern%'). En l’occurrence il semble que le problème soit que MySQL n'a pas de moyen simple de faire une recherche dans l'intégralité des tables.
La machine virtuelle Java OpenJDK et le projet OpenSSH rejoignent les politiques de sécurité de GnuTLS, NSS et OpenSSL en utilisant la même politique de sécurité de mots de passe qu’eux. En effet, depuis quelques versions de Fedora, les utilitaires pouvant avoir une politique de mots de passe, par exemple de huit caractères avec au moins un chiffre et deux majuscules, bénéficient peu à peu de l’unification de cette politique. En définissant la politique une fois via l’utilitaire update-crypto-policies, elle sera disponible pour l’ensemble des applications compatibles.
Et ce genre de chose est infernale à travers une connexion vnc ou sur un layout keyboard mal reconnu, merci Fedora…
Posté par MTux .
En réponse à la dépêche GNOME fête ses 20 ans !.
Évalué à 10.
Dernière modification le 24 mai 2017 à 17:42.
J'aimerais qu'on puisse dire au revoir une bonne fois pour toutes au "system tray", c'est une relique des années 2000 dont on a du mal à se défaire.
En une phrase tout mon problème avec l'ergonomie de GNOME3…
Je suis moi aussi une relique des années 90/2000 et je peux pas me passer d'un systray qui permet de voir en 1 coup d’œil si j'ai des messages non lus sur pidgin / telegram / skype.
Merci captain obvious. Entre enfoncer des portes ouvertes ou encourager les gens à fabriquer eux-mêmes leurs propres périphériques, tu n'as rien de pertinent à dire ?
Bonne nouvelle, c'est du logiciel libre, tu peux aider !
C'est stérile ce genre de remarque.
Essaie de te la faire à toi-même le jour où ta voiture ne démarre pas : "bonne nouvelle, j'ai une boite à outils, j'ai plus qu'à démonter le moteur et réparer ça ! Facile !"
[^] # Re: C'est pas vendredi
Posté par MTux . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 5.
OpenVZ se souciait surtout de RedHat6 / CentOS6 d'où le choix du kernel 2.6.32.
Avec NixOS le fichier /etc/nixos/configuration.nix contient toute la conf du système et des logiciels. Rien qu'avec ce fichier tu peux dupliquer/reconstruire ton serveur en quelques commandes (faut juste penser à copier les données persistantes, s'il y en a). Moi j'adore.
Ben le titre de ton article laisse penser que Debian c'est de la merde quand même, d'où l'hostilité récoltée.
Concernant l'environnement Pro, FreeBSD ça existe, mais plutôt dans l'embarqué j'ai l'impression : FreeNAS, pfSense, et probablement d'autres appliances plus ou moins connues. C'est probablement du à l'aisance avec laquelle on peut construire un système minimaliste (NanoBSD) et ça marche plutôt bien.
Mais il faut voir que Red Hat a un poids énorme en terme de contribution et de parts de marché, ça donne une crédibilité importante à Linux sur les serveurs.
# C'est pas vendredi
Posté par MTux . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 10. Dernière modification le 14 décembre 2017 à 12:19.
C'est pas vendredi. Pour avoir longuement utilisé les deux, je propose d'apporter les précisions suivantes :
OpenVZ n'est pas upstream, c'est de leur faute s'ils n'ont longtemps supporté que le kernel 2.6.32, pas celle de Debian. Après des années et des années de "oui, on réécrit ça en upstream dans le kernel, c'est pour bientôt" je ne sais pas si ça a fini par évoluer. C'est dommage car oui c'est probablement le meilleur truc pour faire des vps bien isolés et pilotables.
La documentation de FreeBSD est bien mais : elle reste légère (pour les jails c'est pas très clair je trouve), elle ne couvre que le système de base (alors que dans la vraie vie tu va avoir besoin des ports/packages sinon tu fais pas grand chose). Tu va me dire qu'il y a les manpage, mais pour moi rien ne vaut des exemples pratiques pour comprendre une techno. Pour debian tu as une énorme communauté d'utilisateurs (blogs, stackoverflow, collègues…) qui n'est pas négligeable. J'accorde cependant que les logiciels de base de FreeBSD ont tous une conf humainement lisible et compréhensible.
Oui LXC c'est bancal, c'est un autre point que j'accorde. Je rajoute que sous Wheezy il y avait un bug qui faisait que certains templates ne marchait pas et le mainteneur était de mauvaise foi ("oui mais sous Sid ça marche"), les utilisateurs ont du monter un mini scandale pour que ce soit corrigé. Sous Linux on ne sait jamais quel système de container/virtualisation sera mature ou upstream l'année prochaine. Mais basiquement aujourd'hui tout le monde a les yeux rivés sur Docker pour les containers et KVM pour la virtualisation.
Iptables ça se discute, perso je suis habitué à leur syntaxe. Par contre je regrette qu'il n'y ait pas de daemon officiel pour charger les règles au démarrage, tout le monde y va de sa sauce (édition du /etc/rc.local, unit systemd…).
La base n'est pas mélangée avec les packets : bouais là encore l'intérêt se discute. Sur debian le même soin est apporté au système de base ou aux logiciels tiers (qui n'ont même pas de distinction). Sur FreeBSD, par expérience j'ai toujours fini par avoir des problèmes avec pkg upgrade à cause des logiciels tiers en rolling release. Le dernier en date c'était deluge (dépendance python ou liboost pétée je crois). Sous debian c'est figé il n'y a pas de surprise (ou rarement, et le mainteneur corrige). Ou encore cet aspect rolling release fait que les fichiers de conf peuvent changer, moi j'avais tout automatisé avec Ansible, et suite à une maj mon playbook ne fonctionnait plus (unbound qui intégrait deux lignes "listen" au lieu d'une, soudainement).
Le /etc/rc.conf : mouais, ça ne concerne que les logiciels de base de FreeBSD, par exemple si tu installe nginx à partir des ports tu aura toujours un /usr/local/etc/nginx/nginx.conf à gérer hein. Faut penser à tout l'écosystème qui va avec.
Point que je rajoute : FreeBSD n'a pas systemd. Si vous mettez de côté tout le FUD qu'on a fait sur cette techno et essayez d'écrire un service ou un container (systemd-nspawn) vous verrez que c'est génial, unifié, et qu'on gagne un temps fou. Jetez un oeil à l'init de nginx et à son unit systemd, le second est tellement plus simple et lisible. Chaque fois que j'ai du bidouiller un init pour FreeBSD je me suis dit "putain, j'y ai passé des heures alors qu'avec systemd j'aurais juste mis ma commande, mon user et hop".
Après c'est sûr que FreeBSD est un super OS, de part son support natif de ZFS, son développement rapide, sa grande compatibilité hardware, ses jails, ses services réseau. Mais perso par expérience j'en reviens toujours à Debian qui est plus universel, qui est figé (pas de rolling release), mais c'est un choix.
[^] # Re: User-friendliness
Posté par MTux . En réponse au journal Parceque l'on peut aussi rigoler de la pomme. Évalué à 6.
Si tu fais référence au "bug" du prompt de chiffrement qui te renvoie en root, ce n'est pas du tout un bypass de sécurité, les volumes restent chiffrés et heureusement (si on pouvait péter un chiffrement AES rien qu'avec des appuis sur une touche, ça se saurait et on pourrait abandonner les ordinateurs quantiques).
Mais après tu as raison sur le fait qu'aucun système n'est sûr. Là aussi ça se saurait.
# Installer son resolveur
Posté par MTux . En réponse au journal Quad9, résolveur DNS public, et sécurisé par TLS. Évalué à 6.
apt-get install unbound
echo "nameserver 127.0.0.1" > /etc/resolv.conf
de rien.
# Travaille / passe du temps au travail
Posté par MTux . En réponse au sondage Je travaille/passe du temps au travail, en moyenne et par semaine. Évalué à 10.
Hum il y a quand même une différence entre "travailler" et "passer du temps au travail". Je suis physiquement présent au bureau 42,5h / semaine mais en enlevant les pauses je descend à 35h. Mais c'est bien ça permet de se rendre compte à quel point on passe nos vies au bureau (et encore je suis chanceux).
# Dispo dans Yunohost
Posté par MTux . En réponse à la dépêche Movim 0.12 — Lovejoy. Évalué à 5.
0.12 dispo pour Yunohost: https://github.com/movim/movim_ynh
[^] # Re: VM obligatoire ?
Posté par MTux . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
Nous n'avons jamais eu de split brain.
C'est arrivé qu'un serveur tombe, quand il remonte il se reconstruit. Et nous n'avons jamais eu de peer offline.
Mais oui dans l'idéal ce serai sûrement plus sûr d'en avoir 3.
[^] # Re: VM obligatoire ?
Posté par MTux . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
On ne bosse qu'avec deux serveurs donc en replica 2, et en LAN. Pas de souci de reconnexion.
Par contre dans les dossiers contenant de très nombreux fichiers il y a quelques latences, notamment pour ls.
# Journal VS depeche
Posté par MTux . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.
En effet… je n'ai jamais compris la différence entre les deux et je ne comprends pas pourquoi ils existent. Pourquoi n'y aurait-il pas une seule page "news" ou "articles" ?
[^] # Re: VM obligatoire ?
Posté par MTux . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 3.
On bosse avec de vielles versions de gluster et on en est plutôt contents. C'est très résilient, on a jamais perdu de données. C'est pas trop lourd pour les serveurs, ils peuvent même faire office de brick+client "croisés" (pas besoin d'un nas dédié, même si c'est quand même plus propre). On a juste eu des problèmes la fois où on a voulu connecter un client récent à un vieux serveur: tout le cluster est tombé, moralité il faut utiliser les mêmes versions partout. Mais sinon c'est solide.
On utilise Ceph pour stocker des VMs sur une ferme d'hyperviseurs Xen. Ça nécessite du lourd, minimum 3 serveurs avec beaucoup de RAM (8GB mini) et des SSD pour le journal. L'architecture Ceph est beaucoup plus complexe que Gluster et en cas de pépin il faut savoir s'en sortir. Au niveau intégrité des données nous n'avons jamais eu de soucis, par contre nous avons déjà eu 2 incidents qui ont fait tomber le cluster alors qu'un gluster aurait tenu. Nous avons aussi un bug qui fait gonfler les nodes en ram, c'est visiblement un souci upstream et nous attendons un correctif (bon c'est pas trop critique, il y a 1 petite commande à faire pour vider la ram sans devoir redémarrer).
Sinon comme on l'a déjà dit, Gluster c'est pour du stockage fichiers alors que Ceph c'est block (bien qu'il existe CephFS, mais je n'ai jamais testé).
[^] # Re: VM obligatoire ?
Posté par MTux . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2. Dernière modification le 24 octobre 2017 à 17:18.
Testé les 2
Utilisés actuellement en prod même
[^] # Re: Glusterfs / Proxmox
Posté par MTux . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 5.
Hm, Gluster fait de la répli niveau block ? Il me semble que c'est au niveau fichiers uniquement.
Sinon ouais Ceph, mais il faut une grosse infra (3 serveurs bien dimensionnés) et il faut savoir faire face en cas d'incident car dans mon expérience c'est très résilient (on a jamais perdu de données) mais au niveau continuité de service c'est pas trop ça (des petits incidents qui n'auraient pas du avoir d'impact mais qui font tomber le cluster).
[^] # Re: engagement de Bouygues
Posté par MTux . En réponse au journal Bouygues et IP fixe... qui change (où l'on parle aussi de fake MX). Évalué à 3. Dernière modification le 04 octobre 2017 à 13:44.
C'était mon cas quand j'avais le FTTLa Bouygues, aucune indication mais en pratique c'était fixe, j'ai changé 1 fois en 2 ans.
[^] # Re: Performances SPARC ?
Posté par MTux . En réponse au journal La mort de Solaris et de SPARC. Évalué à 9.
Heu… quel genre de soucis recontres-tu sur des serveurs x86_64 exactement ? Perso j'ai pas à m'en plaindre. Ou alors tu parles des workstations ?
# Serveur down ?
Posté par MTux . En réponse à la dépêche Haiku a 16 ans. Évalué à 4. Dernière modification le 27 août 2017 à 23:16.
$ wget https://download.haiku-os.org/nightly-images/x86_64/current-anyboot
--2017-08-27 23:00:56-- https://download.haiku-os.org/nightly-images/x86_64/current-anyboot
Résolution de download.haiku-os.org (download.haiku-os.org)… 2a01:4f8:190:64c3::2, 78.46.189.196
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:443… connecté.
requête HTTP transmise, en attente de la réponse… 302 Moved Temporarily
Emplacement : http://download.haiku-os.org:8081/nightly-images/x86_64/haiku-nightly-hrev51382-x86_64-anyboot.zip [suivant]
--2017-08-27 23:00:56-- http://download.haiku-os.org:8081/nightly-images/x86_64/haiku-nightly-hrev51382-x86_64-anyboot.zip
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:8081… échec : Connexion terminée par expiration du délai d'attente.
Connexion à download.haiku-os.org (download.haiku-os.org)|78.46.189.196|:8081… échec : Connexion terminée par expiration du délai d'attente.
Résolution de download.haiku-os.org (download.haiku-os.org)… 2a01:4f8:190:64c3::2, 78.46.189.196
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:8081… échec : Connexion terminée par expiration du délai d'attente.
Connexion à download.haiku-os.org (download.haiku-os.org)|78.46.189.196|:8081… échec : Connexion terminée par expiration du délai d'attente.
Nouvel essai.
Le serveur ne répond pas en ipv4/ipv6
[^] # Re: Partage
Posté par MTux . En réponse au journal Les BSD sont‐ils tous égaux devant les bugs ?. Évalué à 4.
Ce sont des systèmes d'exploitation différents donc userspace et noyau différents, il n'y a que le nom "BSD" qui est commun.
[^] # Re: C'est fort
Posté par MTux . En réponse au journal Let's Encrypt, Nginx et Wordpress. Évalué à 3. Dernière modification le 25 juillet 2017 à 11:35.
Ou alors tu fais un UPDATE table SET row1='value' WHERE row1 LIKE '%pattern%', c'est tout l'intérêt d'une base de données (manipuler des données), c'est pour ça que je postais le commentaire (tu dump ta bdd pour faire un grep dedans au lieu de faire directement un SELECT * FROM table WHERE row1 LIKE '%pattern%'). En l’occurrence il semble que le problème soit que MySQL n'a pas de moyen simple de faire une recherche dans l'intégralité des tables.
[^] # Re: mots de passe pénible
Posté par MTux . En réponse à la dépêche Fedora 26 est sortie !. Évalué à 3.
Merci, c'est exactement cela.
[^] # Re: C'est fort
Posté par MTux . En réponse au journal Let's Encrypt, Nginx et Wordpress. Évalué à 4.
Non en revanche j'imagine que c'est plus pratique pour rechercher dans l'intégralité des tables d'une base mysql.
# C'est fort
Posté par MTux . En réponse au journal Let's Encrypt, Nginx et Wordpress. Évalué à 3.
La partie où tu fais un dump de la bdd pour ensuite faire un grep sur le fichier obtenu, c'est quand même balèze xD
# mots de passe pénible
Posté par MTux . En réponse à la dépêche Fedora 26 est sortie !. Évalué à 5.
Et ce genre de chose est infernale à travers une connexion vnc ou sur un layout keyboard mal reconnu, merci Fedora…
[^] # Re: 4 ans que pas grand monde n'est impacté
Posté par MTux . En réponse au journal Vulnérabilité majeure dans Kmail. Évalué à 9.
Ou personne n'utilise KMail…
# On va pas être copain
Posté par MTux . En réponse à la dépêche GNOME fête ses 20 ans !. Évalué à 10. Dernière modification le 24 mai 2017 à 17:42.
En une phrase tout mon problème avec l'ergonomie de GNOME3…
Je suis moi aussi une relique des années 90/2000 et je peux pas me passer d'un systray qui permet de voir en 1 coup d’œil si j'ai des messages non lus sur pidgin / telegram / skype.
[^] # Re: Petit pas
Posté par MTux . En réponse au journal Gnome et Logitech collaborent pour vous proposer des mises à jour de leur solution Unify. Évalué à 7.
Merci captain obvious. Entre enfoncer des portes ouvertes ou encourager les gens à fabriquer eux-mêmes leurs propres périphériques, tu n'as rien de pertinent à dire ?
[^] # Re: Activités
Posté par MTux . En réponse au journal Sortie de Replicant 6.0. Évalué à 4.
C'est stérile ce genre de remarque.
Essaie de te la faire à toi-même le jour où ta voiture ne démarre pas : "bonne nouvelle, j'ai une boite à outils, j'ai plus qu'à démonter le moteur et réparer ça ! Facile !"