C'est vrai, mais je pense que complexifier la personnalisation (au niveau administration principalement, puis logiciel) d'un système n'est pas une bonne chose.
Un bon DSL (qui garde les choses simples, simples) et un bon bootstrap (qui découpe la configuration en plusieurs fichiers voir plusieurs dossiers) rendent ça très simple. C'est là qu'on voit les DSL bien foutu. Le .vimrc moyen est très proche du fichier properties, mais est un vrai langage de programmation complet qui quand tu en a besoin pourra t'être très utile, le bootstrap de vim permet d'avoir une configuration system-wide et une configuration par utilisateur. Mais il faut en avoir le besoin, pour moi, systemd démontre que ce n'est pas nécessaire pour l'init.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Quant aux logiciels qu'il faut configurer via un langage de script[…]
C'est quand même super bien des fois. Personnellement j'essaie de pousser les fichiers de configuration les plus simples (ça commence avec les fichiers properties), puis on monte en fonction des besoins et en essayant d'éviter d'avoir 612 formats. Mais il arrive qu'un vrai LSM soit génial, c'est par exemple le cas pour vim, gradle et awesome. Tous les logiciels n'ont pas pour objectif d'être Michu-compliant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ça consomme plus de ressources (disque, RAM,…), il faut gérer la communication inter application (c'est bien d'avoir télécharger ton iso avec transmission, maintenant va la graver ou la mettre sur ton disque), pour un gain au final assez faible (tu retrouve les même problèmes que ce qu'on a actuellement et l'intégration avec l'OS doit être poussée si tu veux qu'elle soit légère).
Depuis quelques années on a plusieurs techno qui convergent vers des conteneurs efficaces (cgroup, namespace et btrfs (pour du COW) pour donner LXC et maintenant docker).
Mais c'est une problématique différente de celle du sandboxing tel qu'on le voit via capsicum, dont l'objectif est pour une application d'avoir une partie d'elle même sécurisée. Pour l'exemple de Chrome si tu met V8 (le moteur javascript) dans une VM est que le reste de Chrome y accède par réseau tu va perdre énormément en performance (parce qu'il y a toute la page à partager entre le moteur et l'interface. Ça n'est pas une solution.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Voila de quoi permettre aux bons pères de familles travaillant pour des employeurs tyranniques les obligeants à utiliser des choses bizarres comme la dernière version de RHEL ou CentOS de se former sur le temps de troll plutôt que sur leur temps libre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
On appel ça de la programmation orientée aspect, c'est puissant, mais assez dangereux en effet (et peu utilisé au final mis à part dans quelques situations classiques).
tout ça pour dire que c'est probablement très bien fait emacs-lisp, mais que ça existe dans pas mal de langages.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
ce qui au passage entre directement en conflit avec l'optimisation de pas demander la liste complète trop souvent
AMHA, la question est de savoir si le partitionnement est correct ensuite, il y a des algo (type bloom filter) qui permettent de gérer des ensembles assez grands sans trop de problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Personnellement plus ça va et plus mes fonctions sont courtes. C'est une habitude si je ne peux pas lire un code dans son ensemble avec mon écran (et moins sur les grands écrans), je trouve ça gênant. Bref tout ça pour dire qu'avec des méthodes qui font 15 à 20 lignes max (ce qui n'a rien de compliqué à faire avec un langage comme python), ça ne pose pas vraiment de problème.
Cela dis j'aime pas bien python et son indentation forcée (une histoire de goût).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
typiquement, maintenir des scripts d'admin sur un environnement de prod
C'est n'importe quoi. Oui il y a des gens qui le font, mais non c'est n'importe quoi. Tu as 2 milliards de solutions pour ne pas faire ça allant de choses très lourdes (demandant l'installation de serveurs et de deamon sur chaque machine) à très légère ne demandant qu'un accès ssh sur le serveur et un outil en local chez toi. Le libre fourmille d'outils pour faire ce genre de chose (AMHA c'est là que le libre est le mieux représenté).
Ce n'est même pas une question d'éditeur ou d'IDE, mais de savoir un peu ce que tu as fais et pourquoi et de pouvoir reproduire les choses en cas de problème sans pour autant avoir à aller fouiller les backup pour des actions aussi simples.
Dernière chose, tu parle de scripts d'admin on est à des années lumière du cas nominal de programmation. Tu va aller toucher le site de prod en direct comme ça ? Juste à coup d'un petit sed bien senti ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
En statique, il n'y a pas de contrainte de temps pour générer les pages. Si l'on s'en fiche de mettre 1 minute pour générer les 100 billets avec un moteur de blog qui tourne sous bash (comme NanoBlogger), on peut fignoler ses pages avec des logiciels tiers (par ex. l'utilitaire "cal" pour avoir un calendrier).
Ça n'a rien avoir avec le fait que ce soit dynamique, c'est le fait que ce soit synchrone qui l'en empêche. On peut très bien faire des sites web asynchrones).
La même chose, en dynamique, imposerait d'avoir ces logiciels tiers installés sur le serveur en plus de la base de données et ça entraînerait un ralentissement dans la fabrication des pages générées à la volée.
Oui/non, ce n'est pas nécessaire, mais c'est compliqué (pour un petit site de faire des actions sur divers serveurs).
En statique, il n'y aucune obligation à ce que les pages soient fabriquées sur le serveur. Donc, on peut les faire sur sa machine chez soi tranquillement puis les uploader chez son hébergeur. En dynamique, si le site est hébergé sur un serveur dont on n'a que peu de contrôle, il est difficile de peaufiner ses pages. Le plus souvent, la personnalisation se limitera aux plugins qui sont livrées avec le CMS.
Si par fignoler tes pages, tu parle de reprendre à la main tes pages, tu n'es plus vraiment dans le moteur de blog statique. C'est très long à faire et relativement peu intéressant (il y a peu voir pas) de "fignolage" qui ne peut s'automatiser.
Après faut pas non plus avancer des choses pour le principe. La contrainte de temps est très faible. Il faudrait faire des actions vraiment lourdes (compilation un peu grosse par exemple) pour que ça ai une vrai importance. Chose que tu ne peux pas faire en statique par définition (il t'est impossible de réagir à une action du client). Pour ce qui est de la forte charge, l'énorme majorité des gens qui utilisent un générateur de site statiques ont très peu de charge.
Comprends bien que je ne dis pas que ça n'a pas d'intérêt, au contraire. Les moteurs de sites statiques sont simples et s'hébergent facilement notamment sur github.io.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'était une allégorie (tu sais comme quand tu parle des "libristes"), c'est le consensus entre conservatisme et nouveauté qui est intéressant et plus productif qu'on ne le crois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
On peut concevoir un système de démarrage séquentiel ou basé sur des événements prévisible, propre et prenant en compte l'environnement autour.
C'est le coté prévisible qui ne me semble pas possible, parce que tu réagis à des évènements physiques par définition non maitrisables.
Dans mon esprit, cet init utiliserait des scripts, mais j'avoue ne pas être un grand fan des scripts sh (comme le fait Pacemaker), je verrais bien du lua dans ce rôle (peut-être parce que NetBSD a choisi ce langage pour scripter le noyau).
Personnellement pour moi c'est du détail sans grand importance, le DSL utilisé n'est pas particulièrement intéressant. Je préfère largement quelque chose de déclaratif quelque chose comme dans gradle en groovy ou dancer en perl.
Je penses que c'est plus facile qu'il n'y paraît si on part du principe que l'init ne doit fournir qu'un cadre de travail et n'essaie pas de tout faire. Après à chaque solution, donc distribution, administrateur, utilisateur, d'utiliser ce système comme il le souhaite.
Ce que je dis c'est que les solutions actuelles ne permettent pas de répondre à ces questions.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il me semblait qu'Upstart voulait s'orienter vers ça mais bon, ça n'a pas vraiment pris.
C'est de là que vient ma vision.
Quand j'avais lu ça, ça m'avait paru vachement intéressant.
Pareil. Pour le coup je trouve que par rapport à cette vision upstart semblait une vraie innovation et systemd bien moins original (c'est plus un (sysv|rc.d)++ qu'une vraie nouvelle vision).
Du coup, on commence quand à bosser là dessus ;)
De ce que j'ai lu la base technique de systemd est largement plus robuste qu'upstart.
J'aimerais bien contribuer mais j'ai piscine :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ah le jeunisme ca fait toujours rigoler a voir. Je vais te dire un secret: "un jour toi aussi tu seras vieux et toi aussi tu ne seras pas a jour sur toutes les technos qui sortent et toi aussi tu auras un gamin qui sort de l'ecole (et dont le boulot aura ete de se former sur ces trucs nouveaux) qui viendra te dire que tu es un nul :)"
Et heureusement ! Faut pas non plus faire les vieux routards., cette situation des vieux qui veulent rien toucher et des bleus qui veulent apporter des nouveautés c'est tout à fait bénéfique ! D'une part ça pousse à se remettre en question, mais en plus ça permet d'aboutir à des consensus relativement pertinents.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par barmic . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 3.
Un bon DSL (qui garde les choses simples, simples) et un bon bootstrap (qui découpe la configuration en plusieurs fichiers voir plusieurs dossiers) rendent ça très simple. C'est là qu'on voit les DSL bien foutu. Le
.vimrcmoyen est très proche du fichier properties, mais est un vrai langage de programmation complet qui quand tu en a besoin pourra t'être très utile, le bootstrap de vim permet d'avoir une configuration system-wide et une configuration par utilisateur. Mais il faut en avoir le besoin, pour moi, systemd démontre que ce n'est pas nécessaire pour l'init.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par barmic . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 4.
C'est quand même super bien des fois. Personnellement j'essaie de pousser les fichiers de configuration les plus simples (ça commence avec les fichiers properties), puis on monte en fonction des besoins et en essayant d'éviter d'avoir 612 formats. Mais il arrive qu'un vrai LSM soit génial, c'est par exemple le cas pour vim, gradle et awesome. Tous les logiciels n'ont pas pour objectif d'être Michu-compliant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Virtualisation par défaut
Posté par barmic . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 3.
Ça doit pourvoir se faire avec un LSM voir avec un namespace fs (selon ce que tu veux faire exactement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par barmic . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 7.
Il y a des programmes qui demandent de générer de l'entropie en déplaçant sa sourie.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Virtualisation par défaut
Posté par barmic . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 10.
Ça consomme plus de ressources (disque, RAM,…), il faut gérer la communication inter application (c'est bien d'avoir télécharger ton iso avec transmission, maintenant va la graver ou la mettre sur ton disque), pour un gain au final assez faible (tu retrouve les même problèmes que ce qu'on a actuellement et l'intégration avec l'OS doit être poussée si tu veux qu'elle soit légère).
Depuis quelques années on a plusieurs techno qui convergent vers des conteneurs efficaces (cgroup, namespace et btrfs (pour du COW) pour donner LXC et maintenant docker).
Mais c'est une problématique différente de celle du sandboxing tel qu'on le voit via capsicum, dont l'objectif est pour une application d'avoir une partie d'elle même sécurisée. Pour l'exemple de Chrome si tu met V8 (le moteur javascript) dans une VM est que le reste de Chrome y accède par réseau tu va perdre énormément en performance (parce qu'il y a toute la page à partager entre le moteur et l'interface. Ça n'est pas une solution.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Formation
Posté par barmic . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 10. Dernière modification le 02 août 2014 à 09:59.
Voila de quoi permettre aux bons pères de familles travaillant pour des employeurs tyranniques les obligeants à utiliser des choses bizarres comme la dernière version de RHEL ou CentOS de se former sur le temps de troll plutôt que sur leur temps libre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: malwares : remote lookup
Posté par barmic . En réponse à la dépêche Firefox sur son 31. Évalué à 3.
Je parle au sein des partitions. Tu peux te permettre d'avoir des partitions de bonnes tailles.
Mais les partitions ne sont intéressantes que si elles sont correctement équilibrées.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Commentaire du jour
Posté par barmic . En réponse au journal Des prompteurs pour Emacs. Évalué à 3.
On appel ça de la programmation orientée aspect, c'est puissant, mais assez dangereux en effet (et peu utilisé au final mis à part dans quelques situations classiques).
tout ça pour dire que c'est probablement très bien fait emacs-lisp, mais que ça existe dans pas mal de langages.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: malwares : remote lookup
Posté par barmic . En réponse à la dépêche Firefox sur son 31. Évalué à 3.
AMHA, la question est de savoir si le partitionnement est correct ensuite, il y a des algo (type bloom filter) qui permettent de gérer des ensembles assez grands sans trop de problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis à moi et rien qu'à moi
Posté par barmic . En réponse au journal Python comme premier langage de programmation ?. Évalué à 3.
Personnellement plus ça va et plus mes fonctions sont courtes. C'est une habitude si je ne peux pas lire un code dans son ensemble avec mon écran (et moins sur les grands écrans), je trouve ça gênant. Bref tout ça pour dire qu'avec des méthodes qui font 15 à 20 lignes max (ce qui n'a rien de compliqué à faire avec un langage comme python), ça ne pose pas vraiment de problème.
Cela dis j'aime pas bien python et son indentation forcée (une histoire de goût).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis à moi et rien qu'à moi
Posté par barmic . En réponse au journal Python comme premier langage de programmation ?. Évalué à 6.
C'est n'importe quoi. Oui il y a des gens qui le font, mais non c'est n'importe quoi. Tu as 2 milliards de solutions pour ne pas faire ça allant de choses très lourdes (demandant l'installation de serveurs et de deamon sur chaque machine) à très légère ne demandant qu'un accès ssh sur le serveur et un outil en local chez toi. Le libre fourmille d'outils pour faire ce genre de chose (AMHA c'est là que le libre est le mieux représenté).
Ce n'est même pas une question d'éditeur ou d'IDE, mais de savoir un peu ce que tu as fais et pourquoi et de pouvoir reproduire les choses en cas de problème sans pour autant avoir à aller fouiller les backup pour des actions aussi simples.
Dernière chose, tu parle de scripts d'admin on est à des années lumière du cas nominal de programmation. Tu va aller toucher le site de prod en direct comme ça ? Juste à coup d'un petit sed bien senti ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Options
Posté par barmic . En réponse à la dépêche Firefox sur son 31. Évalué à 3.
Alt+h ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: client android
Posté par barmic . En réponse à la dépêche Sortie de SFLphone 1.4.0 - Softphone libre pour GNU/Linux. Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Options
Posté par barmic . En réponse à la dépêche Firefox sur son 31. Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: malwares : remote lookup
Posté par barmic . En réponse à la dépêche Firefox sur son 31. Évalué à 2.
Tu peut récupérer ton profile ça marche aussi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Fortran 2008
Posté par barmic . En réponse au journal Python comme premier langage de programmation ?. Évalué à 3.
Ça n'a rien avoir avec le fait que ce soit dynamique, c'est le fait que ce soit synchrone qui l'en empêche. On peut très bien faire des sites web asynchrones).
Oui/non, ce n'est pas nécessaire, mais c'est compliqué (pour un petit site de faire des actions sur divers serveurs).
Si par fignoler tes pages, tu parle de reprendre à la main tes pages, tu n'es plus vraiment dans le moteur de blog statique. C'est très long à faire et relativement peu intéressant (il y a peu voir pas) de "fignolage" qui ne peut s'automatiser.
Après faut pas non plus avancer des choses pour le principe. La contrainte de temps est très faible. Il faudrait faire des actions vraiment lourdes (compilation un peu grosse par exemple) pour que ça ai une vrai importance. Chose que tu ne peux pas faire en statique par définition (il t'est impossible de réagir à une action du client). Pour ce qui est de la forte charge, l'énorme majorité des gens qui utilisent un générateur de site statiques ont très peu de charge.
Comprends bien que je ne dis pas que ça n'a pas d'intérêt, au contraire. Les moteurs de sites statiques sont simples et s'hébergent facilement notamment sur github.io.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: GUI SDL
Posté par barmic . En réponse au journal Pas libre mais dans la tendance. Évalué à 3.
C'est quoi la différence fondamentale ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Fortran 2008
Posté par barmic . En réponse au journal Python comme premier langage de programmation ?. Évalué à 4.
Comme quoi par exemple ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Contournement de déficiences du Web
Posté par barmic . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 4.
Tu as finalement envoyé un mail au groupe qui discute (discutait ?) de HTTP 2 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilation du noyau sous root ?
Posté par barmic . En réponse à la dépêche Crux 3.1: une distribution KISS à la saveur BSD. Évalué à 3.
Un utilisateur responsable ferra aussi un
chown -R george:users /boot?Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu sais
Posté par barmic . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 3.
C'était une allégorie (tu sais comme quand tu parle des "libristes"), c'est le consensus entre conservatisme et nouveauté qui est intéressant et plus productif qu'on ne le crois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Justement
Posté par barmic . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 3.
C'est le coté prévisible qui ne me semble pas possible, parce que tu réagis à des évènements physiques par définition non maitrisables.
Personnellement pour moi c'est du détail sans grand importance, le DSL utilisé n'est pas particulièrement intéressant. Je préfère largement quelque chose de déclaratif quelque chose comme dans gradle en groovy ou dancer en perl.
Ce que je dis c'est que les solutions actuelles ne permettent pas de répondre à ces questions.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Justement
Posté par barmic . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 2.
C'est de là que vient ma vision.
Pareil. Pour le coup je trouve que par rapport à cette vision upstart semblait une vraie innovation et systemd bien moins original (c'est plus un (sysv|rc.d)++ qu'une vraie nouvelle vision).
De ce que j'ai lu la base technique de systemd est largement plus robuste qu'upstart.
J'aimerais bien contribuer mais j'ai piscine :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu sais
Posté par barmic . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 3.
J'ai rien compris. Il a besoin de connaître ou pas ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu sais
Posté par barmic . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 4.
Et heureusement ! Faut pas non plus faire les vieux routards., cette situation des vieux qui veulent rien toucher et des bleus qui veulent apporter des nouveautés c'est tout à fait bénéfique ! D'une part ça pousse à se remettre en question, mais en plus ça permet d'aboutir à des consensus relativement pertinents.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)