De quel utilisateur on parle ? D'un admin sys ou de Mme Michu ?
car il faut maintenir soi-même, et qu'on ne trouve pas ces dépots maintenus par d'autre fréquemment.
Je ne crois pas que Microsoft fournisse un dépôt de déploiement logiciels (même pour ses propres produits). La mode des magasins d'applications risque de changer cela, mais ce n'est pas encore pensé pour l'entreprise.
Un admin sys qui veut faire du déploiement en entreprise va devoir se taper le packaging et la maintenance/suivi qui va avec pour TOUS les logiciels qu'il va devoir déployer sous Windows (et avec des subtilités pour chacun d'entre eux, pour pas dire une méthode de packaging spécifique à chacun, et en prenant en compte l'hétérogénéité du parc Windows).
Installer et mettre à jour à la main chaque logiciels sous Windows, ça n'a rien à voir. C'est l'usage classique. Les dépôts de logiciels maintenus par d'autres bonnes âmes pour Windows se comptent sur les doigts de la main et sont loin d'avoir le niveau des dépôts Debian tant en qualité qu'en quantité d'applications fournies. Et je ne parle pas du niveau d'intégration à l'OS.
De la même manière, les logiciels qui ne sont pas intégrés aux dépôts officiels Debian et qui n'ont pas de dépôts du tout, restent une exception.
Il est oû ce PPA pour […] Adobe Acrobat ?
Ah, parce que la licence d'Adobe l'autoriserait ? Faut pas être de mauvaise fois, ce n'est pas la faute de Debian.
Ouh la belle attaque facile… "Utiliser une version de test", mais ça vous fait pas mal parfois ? Tu es conscient que "testing" est une classification de niveau d'intégration de la distribution et que ça n'a pas le même sens qu'une beta pour un logiciel ?
Testing et sid sont largement utilisables en desktop au quotidien sans aucune instabilité particulière (c'est ce que je fais d'ailleurs, et je suis loin d'être le seul). Je rappelle également que sid sert (servait ?) de base à Ubuntu… qui n'est pas considéré à ma connaissance comme une distribution en test permanent ou complètement instable.
Par contre, ce que Debian propose, c'est de pousser les tests, l'intégration et la correction de bug des paquets qu'ils distribuent au point de fournir une distribution qui n'aura pas de risque de péter à chaque mise à jour et qui sera sûre (au niveau failles de sécurité). La contrepartie, c'est que les versions de logiciels sont figées à un moment précis afin de travailler sur une base stable (parce que c'est logiquement plus facile).
Là encore, l'utilisateur est prévenu et fait ses choix en fonction de ses besoins. J'utilise testing/sid en desktop et stable sur les serveurs.
Moi ça me convient mais je conçois que certains utilisateurs n'y trouvent pas leur compte. Il existe d'ailleurs d'autres distributions avec un fonctionnement différent (Arch par exemple).
Faut pas exagérer quand même.
La version packagée dans testing a 2 mineures de retard et date de septembre 2014. C'est pas ce que j'appelle une "vieille" version.
Experimental est à jour.
on ne te laisse pas le choix de la version
Les choses sont claires dès le début. L'utilisateur sait à quoi il doit s'attendre. Si ça ne lui convient pas, rien ne l'empêche d'installer manuellement le paquet que tu fournis ou d'utiliser une autre distribution.
Microsoft fournit des outils pour le déploiement, si si, et ceux la acceptent bien plus de logiciels
A ma connaissance, dans la majorité des cas (soit dès que tu n'utilises pas les GPO) cela nécessite de mettre en place une infra destinée à répondre à ce besoin (et je ne crois pas que le déploiement par GPO puisse gérer les dépendances aussi finement).
Dans tous les cas, cela nécessite un gros boulot de packaging (il y a encore une grande quantité de logiciels qui ne sont pas en msi).
Si je me trompe, je suis tout à fait curieux d'en apprendre plus sur le sujet (ça me servira grandement pour le boulot). ;)
donc en pratique l'admin Linux doit souvent aller taper dans un repo ailleurs
Et il continue à bénéficier de la méthode de travail (pour reprendre Thomas) définie par Debian, ainsi que des outils de déploiement fournis et du confort qu'ils apportent.
Sur quoi tu te bases pour le "souvent" ?
(et Debian, c'est rigolo, mais ils te disent quand même "1 an puis crève"
Wheezy aura bientôt 2 ans, Squeeze en a 4, reçoit toujours des mises à jour et en recevra jusqu'en 2016, soit un support de 5 ans.
Microsoft fait durer ses OS 10 ans, eux
Et on voit ce que ça a donné avec XP. Un an après l'arrêt du support, encore plus de 15 % de parts de marché et un Windows 8 qui ne convainc pas (malgré toutes les qualités qu'il a probablement). On peut dire que ça a plutôt jouer contre eux et qu'ils ne semblent pas prêt à refaire la même erreur (vu le rythme qu'ils tiennent depuis Vista).
While nothing would prevent someone from integrating lxd with libvirt by
writting a libvirt driver for it, I don't personally thing this is a
good idea.
The reason behind this is that libvirt is an abstraction layer for
virtual machines and it does a very good job at that. But containers, as
much as we try to prentend that they are, are not virtual machines.
So there will always be things that containers can do such as passing
network interfaces, directories, character and block devices or just
running code directly inside them from the outside which virtualization
will not provide you. The same is also true the other way around. A
container cannot boot an arbitrary ISO image, it can't be passed a
random PCI or USB device (at least not in the same sense as for a VM)
and doesn't have a virtual graphic card, keyboard and mouse for you to
interact with.
Pour ceux qui ne comprennent pas l'anglais, pour résumer, il dit que bien que rien ne s'oppose au développement d'un driver LXD pour libvirt, il pense que ce n'est pas une bonne idée dans la mesure où les conteneurs et les VM classiques se gèrent de façon trop différentes pour qu'une couche d'abstraction comme libvirt (orientée gestion de VM classiques) soit valable pour les conteneurs. Par exemple, tout ce qui concerne la gestion du matériel émulé pour les VM n'a pas lieu d'être pour les conteneurs. Il y aurait donc une grosse partie de l'API et par conséquent de la GUI associée (virt-manager par exemple) qui ne servirait à rien dans le cas des conteneurs. A l'inverse, il y a des choses spécifiques aux conteneurs (comme transférer une interface réseau, ou n'importe quel périphérique de l'hôte) qui n'existeraient pas ou qui seraient spécifiques et inutiles pour les VM.
Le but du projet LXD est justement de fournir une API pour la gestion des conteneurs (et de leurs hôtes) équivalente à ce que fait libvirt pour les VM.
Du coup, même si c'est effectivement plutôt Canonical qui pousse au cul pour LXC/LXD, cet abandon de support par Red Hat ne me fait pas pour autant penser qu'ils se désintéressent de LXC.
ça fait quelques temps que je suis les annonces de ton projet (du temps où ça s'appellait encore Brebis) et que je me dis que je devrais mettre en place une solution de ce type au boulot.
J'utilise Backuppc pour faire les sauvegardes de mes serveurs, mais ça ne produit pas des archives tar.gz. Backuppc stocke directement dans un dossier dans /var/… en conservant l'arborescence d'origine (qui doit être indexée quelque part je pense, car les fichiers sont renommés). Il fait aussi de la déduplication, donc des liens dans l'arborescence.
Est-ce que Backup Checker s'en tirerait ou est-ce qu'il est uniquement capable de vérifier des archives ?
Jessie en effet. Mais comme tu le dis, c'est du pinaillage, on est en plein gel donc à part les corrections de bug et les mises à jour de sécurité, elle est telle qu'elle sera lors de la sortie officielle. ;)
Que sortir que Linux va mourir sur le HPC à cause de systemd
Mais ! Il ne dit pas ça ! Il dit que systemd ne remplacera pas l'init et les outils de base sur les HPC de son boulot avant longtemps.
Avec la phrase qui suit, j'en comprends que les admins qui gèrent ces HPC n'y sont pas favorables, probablement parce que le changement implique de faire confiance à une techno jeune qui leur est encore inconnue et qui nécessiterait un travail important d'apprentissage avant d'être prêt à se lancer en prod. Ce qui est plutôt compréhensible vu l'infrastructure et les conséquences potentielles d'une panne…
C'est un composant comme un autre, mais c'est un composant plutôt important et à la base du système dont tu te sers (indirectement) potentiellement tous les jours en tant qu'admin sys. Il y a toute la gestion des logs à réapprendre derrière par exemple, c'est par rien non plus.
Linux bouge mais les changements sont nettement moins radicaux qu'un passage à systemd. De plus avec le LTS, tu as tout le temps pour préparer ta migration, rester sur une version agée n'impacte que très peu le fonctionnement, surtout si le matériel n'évolue pas.
Toi tu sous-entends que tes admins sont pas chauds pour changer de version de noyau car il a trop changé et que Linux va mourir à cause de ça
Elle le faisait bien à l'époque de Windows 95 et 98, pourquoi pas aujourd'hui ? C'est bien plus simple qu'à l'époque. Le seul problème c'est qu'il est préinstallé et vendu sans média d'installation, donc la question ne se pose même plus.
Note que systemd n'est pas un blob binaire unique, tu peux remplacer chaque sous composant mais tu dois respecter une certaine API ce qui est le cas pour tout projet logiciel qui collabore avec un autre.
Oui, sauf que pour reprendre un cas concret : je ne pourrais pas remplacer le module de gestion du réseau de systemd (j'ignore son nom) par celui que j'utilise aujourd'hui (iproute2).
Pourtant, je le répète, iproute2 est maintenu et le développeur n'a, à priori, pas l'intention de l'abandonner au profit du module de systemd… (mais dans quelle mesure y sera t'il obligé ?)
Et moi dans tout ça, en tant qu'utilisateur non-esclavagiste d'un outil que quelqu'un choisi de développer et qui me convient, je n'ai rien demandé ! Je n'ai pas demandé à Lennart (ou ses collaborateurs) de venir me révolutionner cet outil qui fonctionne très bien et est maintenu.
A ma connaissance, une grosse partie des éléments qui composent le projet Gnu sont remplaçable à volonté. Bien qu'étant interdépendant, ils restent inter-opérables comme ça a été dit plus bas.
A priori, les éléments qui composent le projet systemd ne sont pas remplaçables par des éléments du projet Gnu faisant le même boulot (le postulat inverse est également valable), à cause du fait que ces éléments sont intrinsèquement liés les uns aux autres.
Et en ce qui me concerne, sans m'empêcher de dormir, je trouve ça préoccupant.
systemd ou Linux, c'est déjà le même combat : des râleurs qui se plaignent de son hégémonie mais incapables de proposer une alternative qui plait plus.
Il y a des alternatives pré-packagées aux distributions linux (Debian GNU/kFreeBSD par exemple).
Autant je peux comprendre la proposition et la nécessité d'un nouvel init, autant je ne comprends pas le besoin de proposer (voir imposer) et réimplémenter tous les outils de base dans le projet systemd. Par exemple, concernant le réseau, iproute2 faisait déjà très bien son boulot et est maintenu. Quel était l'intérêt de développer une alternative ? (Si ce n'est pour ses liens avec l'init)
Et encore, ce n'est même pas le fait qu'une alternative soit proposée qui me gène (c'est même le principe de l'open source en général après tout), mais le fait qu'elle semble liée intrinsèquement à l'init systemd et de fait ne soit plus "proposée" mais "imposée" à travers l'adoption de cet init.
Tu dis souvent que ceux qui ne sont pas content n'ont qu'à se sortir les doigts et assurer la pérennité et la maintenance d'un projet ou d'un outil à tes yeux désuet (SysV) si ils veulent continuer à l'utiliser, les autres développeurs ayant choisi une autre solution plus moderne (systemd).
Pourquoi pas, mais en quoi est-ce recevable pour des outils comme iproute2 par exemple ? De la même manière, Grub2 est maintenu, moderne et convient à beaucoup de gens tout en laissant la possibilité d'utiliser lilo par exemple. Si l'outil proposé par systemd ne me convient pas, aurais-je toujours la possibilité de préférer et utiliser Grub2 ? Ou sera t'il tellement lié à l'init qu'aucune alternative ne sera possible ? Et pourtant, dans ces deux cas (iproute2 et grub2) il y a du monde pour maintenir.
Je pense que c'est aussi ça qui gène pas mal de monde, et c'est en tout cas ce qui me gène moi, quelles que soient les qualités de l'init systemd (que je reconnais bien volontier).
c'est très intéressant effectivement. Merci du retour.
J'ai mis en place à peu près la même architecture sur mon home serveur, mais avec des conteneurs LXC.
Mais autant j'ai bien pigé LXC qui s'apparente à une VM dont le noyau n'est pas virtualisé mais issu de celui de l'hôte et soumis aux restrictions des cgroups, et donc fournissant une arborescence système linux classique ainsi qu'une gestion des daemon comme on en a l'habitude ; autant Docker, j'arrive vraiment pas à comprendre la subtilité par rapport à ça (et donc pas trop l'intérêt non plus dans un cas d'usage comme celui-ci - même si visiblement ça fait très bien le boulot ! :D)
Il me semble que j'avais déjà posé la question dans un précédent journal causant de Docker, je m'en vais de ce pas essayer de retrouver ça, mais malgré tout, si quelqu'un pouvait m'expliquer la nuance dans ce cas précis, j'apprécierais. ;)
Et en quoi ça empêche FB ou G+ de croiser les IP avec les différents comptes/pseudo/mails que tu utilises ?
A moins que tu ne changes d'IP en même temps que de compte pour chaque site que tu visites, finalement, ça ne sert pas à grand chose, ils peuvent facilement déduire de ces croisements que tout (ou grande partie) de tes comptes/pseudos/mails se rapportent à la même personne.
Une nouvelle commande list-machines a été ajoutée à systemctl. Elle liste tous les systèmes d’exploitation dans un conteneur ainsi que leurs états (voir le point ci-dessus), si systemd est utilisé dans ces conteneurs.
Je ne connais pas encore suffisamment systemd pour avoir un avis tranché, je le découvre en ce moment sur ma Debian et à travers les récentes dépêches sur systemd pour les administrateurs (merci à leurs auteurs), mais, même si après tout pourquoi pas, je me demande quand même pourquoi systemd prend en charge cette fonctionnalité ?
Quel est l'intérêt ? Pourquoi ré-inventer une partie de quelque chose qui existe déjà (les outils fournis par lxc, l'api libvirt…) et l'intégrer à un projet qui de mon point de vue n'a pas grand chose à voir ? Je ne trouve pas logique de faire appel à un utilitaire de systemd pour gérer mes conteneurs (même si systemd gère les cgroup en arrière-plan et donc par extension, les-dits conteneurs).
Je lis beaucoup les commentaires sur les nombreuses discussions à propos de systemd et même si - je le répète - mon avis n'est pas fait, force est de constater que l'argument qui revient souvent à propos du fait que systemd cherche à tout faire (un futur remplaçant d'emacs peut-être ? :D) semble justifié.
Je ne dis pas que c'est une mauvaise chose pour autant, mais j'imagine que ça doit au moins faire plus de code à maintenir, plus de bug potentiels et donc plus de boulot.
Au final, même si du peu que j'en ai vu, j'aime bien ce qu'apporte systemd - la rapidité du boot notamment - j'ai l'impression de perdre aussi un peu de cette philosophie d'Unix qui disait que les programmes faisaient peu de choses mais le faisaient bien et que leurs combinaisons permettaient de faire des choses plus complexes.
encore quelques soucis avec le multi-écrans, entre autre le coin haut gauche de l'écran principal, si on a un écran secondaire sur la gauche,
Tu peux choisir lequel des deux sera le principal (et recevra donc la barre principale) dans les paramètres des écrans, et ce indépendamment de leur position (celui qui est à gauche reste à gauche et la souris passe bien à celui de droite quand elle arrive sur le bord droit de celui de gauche et lycée d'Versailles).
Reste FDN ?
OVH aussi. Très bon service client, très bons techniciens.
SFR, j'ai tenté comme opérateur mobile, mais ils ont la fâcheuse tendance de traiter le flux http via leurs proxy (ils retouchent le code, mettent en cache les images des pages après les avoir recompressées de façon dégueulasse)… Sauf que les liens des photos mes pages auto-hébergées n'étaient plus bons après modification.
C'est pour améliorer l'expérience utilisateur et le confort de navigation.
Les Chinois aussi c'est pour améliorer l'expérience utilisateur.
En https, je n'avais plus de problèmes et je regagnais un peu de vie privée, mais pour le principe, je suis quand même retourner chez Free. Ça fonctionne clairement moins bien, mais au moins, ils n'ont pas l'air de toucher aux données qui transitent sur leur réseau (ou celui d'Orange).
J'ai un retour similaire à faire pour le Lenovo Thinkpad Yoga (en Core i3) que je viens de commander récemment. La dalle tactile est gérée correctement.
Au niveau logiciel, Gnome et ses applications s'en sortent mieux que Firefox en effet, notamment sur tout ce qui est défilement de page ou de liste. Pour Firefox, il y a une extension qui permet d'améliorer le comportement : https://addons.mozilla.org/en-us/firefox/addon/grab-and-drag/
C'est pas parfait, mais en attendant mieux…
En plus du capacitif, le Yoga peut être équipé en option d'un système tactile Wacom (avec stylet comme sur le Galaxy Note 3). Là encore, ça marche out-of-the-box (et Gimp le prend bien en charge).
Le seul truc qui ne fonctionne pas, c'est les capteurs pour repérer l'orientation de l'appareil. Or comme c'est un hybride ultrabook/tablette, l'écran ne pivote pas quand il est en mode portrait.
J'ai vu que les sondes étaient prises en charge sur le noyau 3.14, mais l'utilisation des valeurs renvoyées pour faire pivoter l'affichage est encore dans la todo list des dév Gnome.
Au delà de ça, 5h30 d'autonomie constatée (en bureautique avec le wifi et le bt), mise en veille, hibernation, pavé tactile multitouch, retro-éclairage du clavier, gestion de la luminosité, webcam, tout ça fonctionne bien.
Je précise que je suis sous Debian Jessie (avec un noyau 3.14.2 donc)
[^] # Re: De l'openwashing
Posté par madhatter (site web personnel) . En réponse au journal Windows éventuellement en open source?. Évalué à 5.
De quel utilisateur on parle ? D'un admin sys ou de Mme Michu ?
Je ne crois pas que Microsoft fournisse un dépôt de déploiement logiciels (même pour ses propres produits). La mode des magasins d'applications risque de changer cela, mais ce n'est pas encore pensé pour l'entreprise.
Un admin sys qui veut faire du déploiement en entreprise va devoir se taper le packaging et la maintenance/suivi qui va avec pour TOUS les logiciels qu'il va devoir déployer sous Windows (et avec des subtilités pour chacun d'entre eux, pour pas dire une méthode de packaging spécifique à chacun, et en prenant en compte l'hétérogénéité du parc Windows).
Installer et mettre à jour à la main chaque logiciels sous Windows, ça n'a rien à voir. C'est l'usage classique. Les dépôts de logiciels maintenus par d'autres bonnes âmes pour Windows se comptent sur les doigts de la main et sont loin d'avoir le niveau des dépôts Debian tant en qualité qu'en quantité d'applications fournies. Et je ne parle pas du niveau d'intégration à l'OS.
De la même manière, les logiciels qui ne sont pas intégrés aux dépôts officiels Debian et qui n'ont pas de dépôts du tout, restent une exception.
Ah, parce que la licence d'Adobe l'autoriserait ? Faut pas être de mauvaise fois, ce n'est pas la faute de Debian.
Là ?
There is no spoon...
[^] # Re: De l'openwashing
Posté par madhatter (site web personnel) . En réponse au journal Windows éventuellement en open source?. Évalué à 5.
Ouh la belle attaque facile… "Utiliser une version de test", mais ça vous fait pas mal parfois ? Tu es conscient que "testing" est une classification de niveau d'intégration de la distribution et que ça n'a pas le même sens qu'une beta pour un logiciel ?
Testing et sid sont largement utilisables en desktop au quotidien sans aucune instabilité particulière (c'est ce que je fais d'ailleurs, et je suis loin d'être le seul). Je rappelle également que sid sert (servait ?) de base à Ubuntu… qui n'est pas considéré à ma connaissance comme une distribution en test permanent ou complètement instable.
Par contre, ce que Debian propose, c'est de pousser les tests, l'intégration et la correction de bug des paquets qu'ils distribuent au point de fournir une distribution qui n'aura pas de risque de péter à chaque mise à jour et qui sera sûre (au niveau failles de sécurité). La contrepartie, c'est que les versions de logiciels sont figées à un moment précis afin de travailler sur une base stable (parce que c'est logiquement plus facile).
Là encore, l'utilisateur est prévenu et fait ses choix en fonction de ses besoins. J'utilise testing/sid en desktop et stable sur les serveurs.
Moi ça me convient mais je conçois que certains utilisateurs n'y trouvent pas leur compte. Il existe d'ailleurs d'autres distributions avec un fonctionnement différent (Arch par exemple).
There is no spoon...
[^] # Re: De l'openwashing
Posté par madhatter (site web personnel) . En réponse au journal Windows éventuellement en open source?. Évalué à 4.
Faut pas exagérer quand même.
La version packagée dans testing a 2 mineures de retard et date de septembre 2014. C'est pas ce que j'appelle une "vieille" version.
Experimental est à jour.
Les choses sont claires dès le début. L'utilisateur sait à quoi il doit s'attendre. Si ça ne lui convient pas, rien ne l'empêche d'installer manuellement le paquet que tu fournis ou d'utiliser une autre distribution.
A ma connaissance, dans la majorité des cas (soit dès que tu n'utilises pas les GPO) cela nécessite de mettre en place une infra destinée à répondre à ce besoin (et je ne crois pas que le déploiement par GPO puisse gérer les dépendances aussi finement).
Dans tous les cas, cela nécessite un gros boulot de packaging (il y a encore une grande quantité de logiciels qui ne sont pas en msi).
Si je me trompe, je suis tout à fait curieux d'en apprendre plus sur le sujet (ça me servira grandement pour le boulot). ;)
Et il continue à bénéficier de la méthode de travail (pour reprendre Thomas) définie par Debian, ainsi que des outils de déploiement fournis et du confort qu'ils apportent.
Sur quoi tu te bases pour le "souvent" ?
Wheezy aura bientôt 2 ans, Squeeze en a 4, reçoit toujours des mises à jour et en recevra jusqu'en 2016, soit un support de 5 ans.
Et on voit ce que ça a donné avec XP. Un an après l'arrêt du support, encore plus de 15 % de parts de marché et un Windows 8 qui ne convainc pas (malgré toutes les qualités qu'il a probablement). On peut dire que ça a plutôt jouer contre eux et qu'ils ne semblent pas prêt à refaire la même erreur (vu le rythme qu'ils tiennent depuis Vista).
There is no spoon...
[^] # Re: LXC ?
Posté par madhatter (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7.1. Évalué à 1.
Je ne crois pas que Red Hat se désintéresse de LXC.
Suite à une recherche sur le sujet, j'ai lu il y a quelques jours un message de Stephane Graber au sujet du support de LXD dans libvirt :
Pour ceux qui ne comprennent pas l'anglais, pour résumer, il dit que bien que rien ne s'oppose au développement d'un driver LXD pour libvirt, il pense que ce n'est pas une bonne idée dans la mesure où les conteneurs et les VM classiques se gèrent de façon trop différentes pour qu'une couche d'abstraction comme libvirt (orientée gestion de VM classiques) soit valable pour les conteneurs. Par exemple, tout ce qui concerne la gestion du matériel émulé pour les VM n'a pas lieu d'être pour les conteneurs. Il y aurait donc une grosse partie de l'API et par conséquent de la GUI associée (virt-manager par exemple) qui ne servirait à rien dans le cas des conteneurs. A l'inverse, il y a des choses spécifiques aux conteneurs (comme transférer une interface réseau, ou n'importe quel périphérique de l'hôte) qui n'existeraient pas ou qui seraient spécifiques et inutiles pour les VM.
Le but du projet LXD est justement de fournir une API pour la gestion des conteneurs (et de leurs hôtes) équivalente à ce que fait libvirt pour les VM.
Du coup, même si c'est effectivement plutôt Canonical qui pousse au cul pour LXC/LXD, cet abandon de support par Red Hat ne me fait pas pour autant penser qu'ils se désintéressent de LXC.
There is no spoon...
[^] # Re: Déduplication
Posté par madhatter (site web personnel) . En réponse au journal Les sauvegardes, et les logiciels de sauvegarde. Évalué à 1.
Je ne connais pas rsnapshot, mais ce que tu décris est très ressemblant à ce que fait backuppc. ;)
There is no spoon...
# Compatibilité avec backuppc
Posté par madhatter (site web personnel) . En réponse au journal Backup Checker 1.2 : vérification d'archives distantes. Évalué à 2.
Salut,
ça fait quelques temps que je suis les annonces de ton projet (du temps où ça s'appellait encore Brebis) et que je me dis que je devrais mettre en place une solution de ce type au boulot.
J'utilise Backuppc pour faire les sauvegardes de mes serveurs, mais ça ne produit pas des archives tar.gz. Backuppc stocke directement dans un dossier dans /var/… en conservant l'arborescence d'origine (qui doit être indexée quelque part je pense, car les fichiers sont renommés). Il fait aussi de la déduplication, donc des liens dans l'arborescence.
Est-ce que Backup Checker s'en tirerait ou est-ce qu'il est uniquement capable de vérifier des archives ?
There is no spoon...
[^] # Re: version démo en ligne - Idées de sites par défaut
Posté par madhatter (site web personnel) . En réponse au journal Cyca: gestionnaire de signets et de flux open-source. Évalué à 1.
Quelle question ! DLFP évidemment !
There is no spoon...
[^] # Re: Solution ultime contre la censure ?
Posté par madhatter (site web personnel) . En réponse à la dépêche IPFS : Un protocole révolutionnaire pour un hébergement P2P, résilient à la censure. Évalué à 5.
Que bien que l'idée soit bonne, ça ne fonctionnerait que dans des zones suffisamment denses en population.
There is no spoon...
[^] # Re: Hem
Posté par madhatter (site web personnel) . En réponse à la dépêche IPFS : Un protocole révolutionnaire pour un hébergement P2P, résilient à la censure. Évalué à 10.
Déjà, ça fait quelques mois que ce n'est plus PC Inpact, mais Next Inpact.
Et ensuite, en quoi ils produisent du bullshit ?
There is no spoon...
[^] # Re: j'adore
Posté par madhatter (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 3.
Jessie en effet. Mais comme tu le dis, c'est du pinaillage, on est en plein gel donc à part les corrections de bug et les mises à jour de sécurité, elle est telle qu'elle sera lors de la sortie officielle. ;)
There is no spoon...
[^] # Re: j'adore
Posté par madhatter (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 2.
Mais ! Il ne dit pas ça ! Il dit que systemd ne remplacera pas l'init et les outils de base sur les HPC de son boulot avant longtemps.
Avec la phrase qui suit, j'en comprends que les admins qui gèrent ces HPC n'y sont pas favorables, probablement parce que le changement implique de faire confiance à une techno jeune qui leur est encore inconnue et qui nécessiterait un travail important d'apprentissage avant d'être prêt à se lancer en prod. Ce qui est plutôt compréhensible vu l'infrastructure et les conséquences potentielles d'une panne…
C'est un composant comme un autre, mais c'est un composant plutôt important et à la base du système dont tu te sers (indirectement) potentiellement tous les jours en tant qu'admin sys. Il y a toute la gestion des logs à réapprendre derrière par exemple, c'est par rien non plus.
Linux bouge mais les changements sont nettement moins radicaux qu'un passage à systemd. De plus avec le LTS, tu as tout le temps pour préparer ta migration, rester sur une version agée n'impacte que très peu le fonctionnement, surtout si le matériel n'évolue pas.
Je pense que t'es un ouf toi. Un ouf malade.
Tu prends de gros raccourcis quand même !
There is no spoon...
[^] # Re: j'adore
Posté par madhatter (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 3.
Ah bon ?
root@hal:/# ps -p 1 && uname -a
PID TTY TIME CMD
1 ? 00:02:58 systemd
Linux hal 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU/Linux
There is no spoon...
[^] # Re: Du bon et du mauvais
Posté par madhatter (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 4.
Elle le faisait bien à l'époque de Windows 95 et 98, pourquoi pas aujourd'hui ? C'est bien plus simple qu'à l'époque. Le seul problème c'est qu'il est préinstallé et vendu sans média d'installation, donc la question ne se pose même plus.
There is no spoon...
[^] # Re: Du bon et du mauvais
Posté par madhatter (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 0.
Oui, sauf que pour reprendre un cas concret : je ne pourrais pas remplacer le module de gestion du réseau de systemd (j'ignore son nom) par celui que j'utilise aujourd'hui (iproute2).
Pourtant, je le répète, iproute2 est maintenu et le développeur n'a, à priori, pas l'intention de l'abandonner au profit du module de systemd… (mais dans quelle mesure y sera t'il obligé ?)
Et moi dans tout ça, en tant qu'utilisateur non-esclavagiste d'un outil que quelqu'un choisi de développer et qui me convient, je n'ai rien demandé ! Je n'ai pas demandé à Lennart (ou ses collaborateurs) de venir me révolutionner cet outil qui fonctionne très bien et est maintenu.
There is no spoon...
[^] # Re: Du bon et du mauvais
Posté par madhatter (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 4.
A ma connaissance, une grosse partie des éléments qui composent le projet Gnu sont remplaçable à volonté. Bien qu'étant interdépendant, ils restent inter-opérables comme ça a été dit plus bas.
A priori, les éléments qui composent le projet systemd ne sont pas remplaçables par des éléments du projet Gnu faisant le même boulot (le postulat inverse est également valable), à cause du fait que ces éléments sont intrinsèquement liés les uns aux autres.
Et en ce qui me concerne, sans m'empêcher de dormir, je trouve ça préoccupant.
There is no spoon...
[^] # Re: Du bon et du mauvais
Posté par madhatter (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 10.
Il y a des alternatives pré-packagées aux distributions linux (Debian GNU/kFreeBSD par exemple).
Autant je peux comprendre la proposition et la nécessité d'un nouvel init, autant je ne comprends pas le besoin de proposer (voir imposer) et réimplémenter tous les outils de base dans le projet systemd. Par exemple, concernant le réseau, iproute2 faisait déjà très bien son boulot et est maintenu. Quel était l'intérêt de développer une alternative ? (Si ce n'est pour ses liens avec l'init)
Et encore, ce n'est même pas le fait qu'une alternative soit proposée qui me gène (c'est même le principe de l'open source en général après tout), mais le fait qu'elle semble liée intrinsèquement à l'init systemd et de fait ne soit plus "proposée" mais "imposée" à travers l'adoption de cet init.
Tu dis souvent que ceux qui ne sont pas content n'ont qu'à se sortir les doigts et assurer la pérennité et la maintenance d'un projet ou d'un outil à tes yeux désuet (SysV) si ils veulent continuer à l'utiliser, les autres développeurs ayant choisi une autre solution plus moderne (systemd).
Pourquoi pas, mais en quoi est-ce recevable pour des outils comme iproute2 par exemple ? De la même manière, Grub2 est maintenu, moderne et convient à beaucoup de gens tout en laissant la possibilité d'utiliser lilo par exemple. Si l'outil proposé par systemd ne me convient pas, aurais-je toujours la possibilité de préférer et utiliser Grub2 ? Ou sera t'il tellement lié à l'init qu'aucune alternative ne sera possible ? Et pourtant, dans ces deux cas (iproute2 et grub2) il y a du monde pour maintenir.
Je pense que c'est aussi ça qui gène pas mal de monde, et c'est en tout cas ce qui me gène moi, quelles que soient les qualités de l'init systemd (que je reconnais bien volontier).
There is no spoon...
# Par rapport à LXC
Posté par madhatter (site web personnel) . En réponse au journal Migration d'une infra lamp vers docker. Évalué à 2.
Salut,
c'est très intéressant effectivement. Merci du retour.
J'ai mis en place à peu près la même architecture sur mon home serveur, mais avec des conteneurs LXC.
Mais autant j'ai bien pigé LXC qui s'apparente à une VM dont le noyau n'est pas virtualisé mais issu de celui de l'hôte et soumis aux restrictions des cgroups, et donc fournissant une arborescence système linux classique ainsi qu'une gestion des daemon comme on en a l'habitude ; autant Docker, j'arrive vraiment pas à comprendre la subtilité par rapport à ça (et donc pas trop l'intérêt non plus dans un cas d'usage comme celui-ci - même si visiblement ça fait très bien le boulot ! :D)
Il me semble que j'avais déjà posé la question dans un précédent journal causant de Docker, je m'en vais de ce pas essayer de retrouver ça, mais malgré tout, si quelqu'un pouvait m'expliquer la nuance dans ce cas précis, j'apprécierais. ;)
There is no spoon...
[^] # Re: Mais ?
Posté par madhatter (site web personnel) . En réponse au journal Roger Hanin a été bronsonisé. Évalué à 3.
Oui, on l'a assassiné. Il en est mort. C'était après qu'il ait frimé en faisant justicier dans la ville.
There is no spoon...
[^] # Re: FreeBSD
Posté par madhatter (site web personnel) . En réponse à la dépêche Enlightenment DR 0.19 et autres nouveautés éclairées. Évalué à 3.
Et en quoi ça empêche FB ou G+ de croiser les IP avec les différents comptes/pseudo/mails que tu utilises ?
A moins que tu ne changes d'IP en même temps que de compte pour chaque site que tu visites, finalement, ça ne sert pas à grand chose, ils peuvent facilement déduire de ces croisements que tout (ou grande partie) de tes comptes/pseudos/mails se rapportent à la même personne.
There is no spoon...
# list-machines ?
Posté par madhatter (site web personnel) . En réponse à la dépêche systemd versions 212 à 215. Évalué à 6.
Salut,
Je ne connais pas encore suffisamment systemd pour avoir un avis tranché, je le découvre en ce moment sur ma Debian et à travers les récentes dépêches sur systemd pour les administrateurs (merci à leurs auteurs), mais, même si après tout pourquoi pas, je me demande quand même pourquoi systemd prend en charge cette fonctionnalité ?
Quel est l'intérêt ? Pourquoi ré-inventer une partie de quelque chose qui existe déjà (les outils fournis par lxc, l'api libvirt…) et l'intégrer à un projet qui de mon point de vue n'a pas grand chose à voir ? Je ne trouve pas logique de faire appel à un utilitaire de systemd pour gérer mes conteneurs (même si systemd gère les cgroup en arrière-plan et donc par extension, les-dits conteneurs).
Je lis beaucoup les commentaires sur les nombreuses discussions à propos de systemd et même si - je le répète - mon avis n'est pas fait, force est de constater que l'argument qui revient souvent à propos du fait que systemd cherche à tout faire (un futur remplaçant d'emacs peut-être ? :D) semble justifié.
Je ne dis pas que c'est une mauvaise chose pour autant, mais j'imagine que ça doit au moins faire plus de code à maintenir, plus de bug potentiels et donc plus de boulot.
Au final, même si du peu que j'en ai vu, j'aime bien ce qu'apporte systemd - la rapidité du boot notamment - j'ai l'impression de perdre aussi un peu de cette philosophie d'Unix qui disait que les programmes faisaient peu de choses mais le faisaient bien et que leurs combinaisons permettaient de faire des choses plus complexes.
There is no spoon...
[^] # Re: Gnome, la propreté gérée d'une main de faire
Posté par madhatter (site web personnel) . En réponse à la dépêche GNOME 3.14 rebat les cartes. Évalué à 1.
Tu peux choisir lequel des deux sera le principal (et recevra donc la barre principale) dans les paramètres des écrans, et ce indépendamment de leur position (celui qui est à gauche reste à gauche et la souris passe bien à celui de droite quand elle arrive sur le bord droit de celui de gauche et lycée d'Versailles).
There is no spoon...
[^] # Re: aide toi toi même
Posté par madhatter (site web personnel) . En réponse au journal SFR et la censure du Forum. Évalué à 1.
Ah ? J'ai une Wii u et une 3DS et je n'ai pas de soucis (au moins pour me connecter aux services en ligne)
There is no spoon...
[^] # Re: Gnome...oui mais lequel ?
Posté par madhatter (site web personnel) . En réponse au journal cotisation pour calendrier. Évalué à 7.
Quelle nouvelle interface polémique ? Gnome-shell ?
Il me semble pourtant que c'est déjà l'interface par défaut de Wheezy.
There is no spoon...
[^] # Re: aide toi toi même
Posté par madhatter (site web personnel) . En réponse au journal SFR et la censure du Forum. Évalué à 5.
SFR, j'ai tenté comme opérateur mobile, mais ils ont la fâcheuse tendance de traiter le flux http via leurs proxy (ils retouchent le code, mettent en cache les images des pages après les avoir recompressées de façon dégueulasse)… Sauf que les liens des photos mes pages auto-hébergées n'étaient plus bons après modification.
C'est pour améliorer l'expérience utilisateur et le confort de navigation.
Les Chinois aussi c'est pour améliorer l'expérience utilisateur.
En https, je n'avais plus de problèmes et je regagnais un peu de vie privée, mais pour le principe, je suis quand même retourner chez Free. Ça fonctionne clairement moins bien, mais au moins, ils n'ont pas l'air de toucher aux données qui transitent sur leur réseau (ou celui d'Orange).
There is no spoon...
# Thinkpad Yoga
Posté par madhatter (site web personnel) . En réponse au journal Linux, c'est déjà demain - écran tactile. Évalué à 3.
J'ai un retour similaire à faire pour le Lenovo Thinkpad Yoga (en Core i3) que je viens de commander récemment. La dalle tactile est gérée correctement.
Au niveau logiciel, Gnome et ses applications s'en sortent mieux que Firefox en effet, notamment sur tout ce qui est défilement de page ou de liste. Pour Firefox, il y a une extension qui permet d'améliorer le comportement : https://addons.mozilla.org/en-us/firefox/addon/grab-and-drag/
C'est pas parfait, mais en attendant mieux…
En plus du capacitif, le Yoga peut être équipé en option d'un système tactile Wacom (avec stylet comme sur le Galaxy Note 3). Là encore, ça marche out-of-the-box (et Gimp le prend bien en charge).
Le seul truc qui ne fonctionne pas, c'est les capteurs pour repérer l'orientation de l'appareil. Or comme c'est un hybride ultrabook/tablette, l'écran ne pivote pas quand il est en mode portrait.
J'ai vu que les sondes étaient prises en charge sur le noyau 3.14, mais l'utilisation des valeurs renvoyées pour faire pivoter l'affichage est encore dans la todo list des dév Gnome.
Au delà de ça, 5h30 d'autonomie constatée (en bureautique avec le wifi et le bt), mise en veille, hibernation, pavé tactile multitouch, retro-éclairage du clavier, gestion de la luminosité, webcam, tout ça fonctionne bien.
Je précise que je suis sous Debian Jessie (avec un noyau 3.14.2 donc)
There is no spoon...