Maintenant effectivement l'index lui même n'a aucun intérêt à être lisible humainement. A partir de là le mettre au format texte serait un pur gaspillage de place.
Placé dans un même fichier il t'empêche juste d'utiliser grep, sed et autres awk dont certains expliquent qu'ils sont vitaux pour leur survit ou ceux de leur entreprise. Oui grep fonctionne mais il n'est pas efficace car on se retrouve avec du bruit qui pourris toutes les sorties, etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc si je résume on ne peut pas indexer ou rajouter des metas à un fichier texte, parce que si on le fait il devient de facto un fichier binaire ?
Ben ça dépend ton index il est en binaire ou pas ? S'il est en binaire pourquoi diantre l'est-il ? Pas pour des raisons de performances j'espère parce qu'on peut très bien avoir des performance en fichier texte.
Si je fais un less de mon fichier de données SQLite, j'ai du charabia qui s'affiche ou je peux voir mes données ?
# less ~/mozilla/firefox/*/addons.sqlite"addons.sqlite" may be a binary file. See it anyway?
Si je lui demande de le lire tout de même il voit des bouts de textes dedans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc c'est normal que MySQL et consorts utilise leur propre format.
Tu viens d'expliquer pourquoi ils utilisent leur propre format et non pourquoi ils utilisent un format binaire.
Il y a le problème de la performance : un log ça peut être gros (tu peux chercher sur plusieurs semaines si tu as envie), les log binaires sont plus petits (les écritures aussi sont plus petites donc on charges moins les buffers noyau) et la recherche y est plus performante. Il y a aussi une question de fiabilité. La recherche par expression rationnelle a des limites (les séparateurs peuvent se trouver n'importe où).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc on peut dire que c'est juste de la syntaxe et juste pour certains cas, mais de mon point de vue la gestion des ressources lors d'une transaction est un cas assez courant pour mériter un support particulier.
A mais j'ai pas dis le contraire :)
Ça me paraît un peu moins agréable mais beaucoup plus souple que le mot clef with de python ou java (qui sont intéressants avec une ressource unique).
Quel langage implémente cette fonctionnalité ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et là les problèmes vont commencer avec le try catch…
Je ne pense pas que retarder le problème soit une bonne façon de gérer les try catch. Personnellement en même temps que je réfléchis aux paramètres et au retour d'une fonction, je me pose la question des exceptions (de quoi à besoin ma fonction ? à quoi elle sert/qu'est ce qu'elle retourne ? pourquoi/comment elle peut planter ?). Il me semble que c'est comme ça que ça reste logique. Ensuite l'architecture d'une application peut beaucoup aider (dans une archi à composant les composants ne doivent pas se vautrer salement déjà).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Mais je ne vois pas en quoi, dans le langage, on ne pourrait pas faire beaucoup plus (contrairement au C par exemple où c'est quand même lourd de faire autre chose que de la programmation système)
Je n'ai pas dis le contraire. Ce qui va faire la différence ce n'est pas le langage, mais ce que les gens vont en faire (qu'elles bibliothèques/framework vont arriver ? quels projets à forte visibilité vont y passer ou être construit avec ?). D'après ce que j'ai compris les créateurs de Go l'ont pensé pour les développeurs C/C++ et finalement c'est des développeurs python/ruby qui s'y mettent, mais je ne pense pas que ces derniers vont lâcher leur langage de prédiction pour autant. Ils utiliseront un langage dynamique pour tout ce qui est web et interface utilisateur et utiliseront go pour faire du système.
Mais ce n'est là que mon avis « nostradamusien » et « pifometrique » (reconnu « pif le moins fiable » par meteo France 3 années de suite).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Hum, ce que tu propose ressemble fortement à Java qui indique(indiquait?) dans le prototype des fonctions les exceptions potentiellement levée ce qui causé pas mal de protestations car c'est pénible à gérer..
Il y a plusieurs choses à voir.
D'une part il n'y a qu'une partie des exceptions qui doivent être gérées (soit en étant attrapées soit en étant déclarée plus haut). Les Error et les RuntimeException ne sont pas obligatoirement gérées (en fait d'un point de vu pratique c'est des choses qui peuvent arriver n'importe quand. Ce sont les CheckedException qui doivent être gérées.
Pour ce qui est des problèmes de contamination que ça entraine. De mon point de vu une méthode cliente doit gérer l'exception (ou l'encapsuler) et je ne pense que que c'est un problème que la méthode cliente ai un couplage fort avec la classe appelée.
D'autre part même si c'est plus verbeux, je ne trouve pas ça plus contraignant que le pattern matching qu'on trouve avec l'inférence de type.
les scopes (*) qui remplacent en mieux le try .. finally
Si j'ai bien compris. Dans un bloc d'instruction on place une instruction du type :
scope(failure)foo(m);
et si on sort de ce bloc en erreur (pour le cas en exemple), la méthode foo est appelée. Par contre la documentation semble dire que la détection des erreurs se fait encore via des exceptions (ou alors je n'ai pas compris « scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. »). Donc ça ne remplace pas vraiment les exceptions.
Je ne vois pas non plus comment tu peut gérer certains cas avec. Pour libérer des ressources c'est super (les exemples le montre), mais quand il s'agit de gérer une erreur par exemple pour écrire dans un log ou remonter une information à l'utilisateur, tu es obligé d'utiliser une variable globale qui va contenir l'information alors dans quand les cas « classiques » (qu'on trouve en Java ou C++ par exemple) c'est l'exception qui contient cette information. Ça me semble plus propre.
les références non-nullable par défaut et le type Maybe.
Les valeurs null sont une plaie. D'ailleurs on vois en Java avec common lang, guava ou la dernière version de Java SE qu'une partie des aides sont en faites des helpers pour gérer les valeurs null. J'aime bien l'approche patern matching qu'on trouve dans les langages fonctionnels pour ça (on est obligé de gérer la valeur null (ou plutôt le type null quand celui-ci peut se présenter)). Les types nullables de C# sont plutôt pas mal je trouve, ils obligent les développeurs à gérer les cas de valeurs null.
la gestion d'exception "à la Lisp" qui semble un peu différente des autres, mais je ne comprends pas bien si c'est vraiment un avantage en pratique..
Tu parle du fait de pouvoir corriger et rejouer la partie incriminées ? J'ai encore jamais utilisé un tel système, je ne peux pas en dire beaucoup plus que toi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Comme l'a dis Nonolapero python peut fournir un ensemble ressemblant à R mais avec un langage bien plus généraliste et une documentation/communauté plus grande. Par contre R possède plus d'algo de base je crois.
Ensuite pour ce qui est de comparer R à octave ou autre, je pense que R est fait pour le calcul statistique alors que les autres traitent l’ensemble des mathématiques. Du coup avec scilab tu va facilement faire des intégrale alors qu'avec R tu va traiter une grande quantité de données.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et côté nouveautés langage, Rust vient de sortir la version 0.4. J’ai l’impression que par certains côtés ça s’oriente vers les mêmes solutions que, par exemple :
Je pense qu'il manque un mot dans la dépêche (je présume que c'est « Go »).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[…] les concepteurs n'ont pas peur d'expérimenter et de faire encore longtemps des changements fondamentaux. Ça veut dire qu'il ne faut pas vouloir l'utiliser pour des projets sérieux à maintenir sur le long terme aujourd'hui, mais plutôt le voir comme un véhicule en déplacement.
C'est ce qui fait qu'il est si bas dans ma liste des langages à tester. Je comprends bien leur volonté mais ça a tendance à m'exaspérer de voir de gros changements à prendre en compte dans le code.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ben déjà Go n'est finalement plus un langage orienté système (en tout cas pas que).
Je trouve tout de même que si. D'une part c'est la volonté initiale des développeurs de Go, d'autre part les projets dont j'entends parler en Go c'est :
un proxy d'image pour linuxfr
les DNS de NTP dont tu parle
la gestion du loadbalancing de youtube
C'est pas un mal (bien au contraire), mais j'ai l'impression que ce langage amène les développeurs Python/Ruby à faire du développement système compilé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Personnellement, ca n'a rien à voir avec mon intervention initiale (le reste je trouvais pertinent).
Je répondais à tes « Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora » où j'avais l'impression que tu parlais d'un couplage fort entre le DE et systemd.
J'ai une question pourquoi un design orienté événement est pertinent pour un init?
En fait les « ordinateurs » (au sens large, tablettes comprises) sont des modulaires et leur évènement évolue dynamiquement (ils passent de connectés à une prise à une alimentation sur batterie, ils changent de réseau (pour passer d'un réseau ethernet, à du wifi ou un modem 3G), on y connecte un (ou pas) une imprimante, un disque dur en plus,…). Tout ces changements demandent soit des initialisations soit des lancement ou retrait de service. La solution des inits évènementiels consiste à dire que tout est évènement (le démarrage, l'arrêt, etc). La seconde est plus simple à prendre en main et elle me semble plus naturelle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je te signale encore que je ne parlais pas de systemd mais de mutualisation, lance le troll une fois de plus si tu veux… mais je n'interviendrais pas.
Oula. Je me suis juste contenté de retranscrire en français les raisons qui amènent à systemd pour le mainteneur d'Archlinux (il me semble qu'il est relativement bien placé pour en parler). C'est toi qui par au quart de tour sur des propos que je n'ai pas tenu (juste retranscrit sans donner mon avis).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
c'est pas pour cela qu'il ne faut pas se réjouir quand des distributions arrivent à améliorer leur interopérabilité.
Interopérabilité de quoi? On est sur un OS identique avec des toolchains identiques, un userland aussi différent qu'il y a de différences génétique entre l'homme et le singe!
Pourquoi tu dis vouloir être pris au sérieux ? Être interopérable c'est pouvoir faire fonctionner un script par exemple un script de démarrage de postgre sur fedora comme sur maegia.
Si être interopérable, c'est de sauter entre un Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora… alors la communauté linuxienne a un problème.
Si tu te demande pourquoi tu semble n'être qu'un trolleur de bas étage voici la raison. Tu peste sans argumenter, tu pointe du doigt toute une série de logiciel sans expliquer pourquoi (qu'est ce viens faire Debian, Fedora et KDE ici ?).
Mais pour parler sérieusement (puisque c'est ainsi que tu veux qu'on prenne tes messages). Systemd a défini avec précision ces interfaces ce qui permet de le remplacer. Ubuntu le fait avec upstart. Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard. Là où sysinit est juste un standard de fait peu défini.
Réellement je n'ai pas encore touché à systemd et je suis plutôt attiré par sysint et openrc, mais c'est pas une raison pour faire preuve de mauvaise fois.
Comme il y a en ce moment avec systemd….
7 distributions majeures y sont passées. Même si ubuntu continue a garder upstart, gentoo openrc et debian autre chose, ça reste une harmonisation importante.
et franchement qu'est-ce que ça change a aptitude install, un synaptic, yum, pour les utilisateurs/admin ..etc tant que ça gère les dépendances et ça installe. D'ailleurs il y a pakagekit maintenant…
L'autre problème des mainteneurs, c'est la gestion des dépendances et le versionning… pourquoi ne pas mutualiser?
Il y a des projets dans ce sens (je crois me souvenir qu'un Debian Project Leader bossait dessus), mais l'ampleur de la tâche est immense ce qui fait que c'est long.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Faut garder un minimum la tête froide. Les différent gestionnaires de paquets viennent de dissensions qui n'ont jamais étaient résolu (malgré une tentative avec LSB). Là en l’occurrence une partie des mainteneurs de distributions arrivent à se mettre d'accord pour cette solution. Oui ce n'est pas une solution spécifiée de manière collégiale mais c'est des fois comme ça que ça marche le mieux (qu'il n'y a pas des discussions de durée infinie). Hors de c'est deux choses, il reste la gestion du réseau et ensuite ? Tout le reste du système est identique ou presque d'une distribution à l'autre (modulo la configuration par défaut). Ubuntu maintiens ses spécificités (upstart et unity).
Tout cela a créé des dizaines de flameware et des milliers de troll, c'est pas pour cela qu'il ne faut pas se réjouir quand des distributions arrivent à améliorer leur interopérabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Non. C'est un problème qui possède une composante humaine.
Systemd (comme openrc) apportent une uniformisation (et une simplification) ils poussent vers un standard. Les mécanismes de base sont déjà implémenté (vérifier que le service n'est pas déjà lancé par exemple). Bien sûr tu peut contourner ces mécanismes pour créer les tiens mais ça demande un travail beaucoup plus important que celui de suivre les mécanismes classiques. Debian utilise des fonction « start-stop-deamon » mais je crois justement que c'est spécifique à Debian.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
il supporte des configurations mouvante (hot plug) : on branche un disque, il lance fsck et le monte proprement
Ça peut déjà être fait avec udev.
C'est peut être plus simple avec systemd qui écoute les évènement udev, plutôt que d'écrire son propre script pour udev ?
On peut également savoir quels sont les services actifs sur les init standard. Que le PID1 le sache apporte quoi au juste ? Une manière différente d’interroger ?
Je crois que l'idée c'est d'avoir une vision globale du système. Savoir pour un service donné s'il est lancé ou pas est simple, mais le faire de manière globale avec des services lancés à la demande (par socket activation, dbus activation ou udev) c'est plus compliqué.
les sockets activation et dbus activation permettent de simplifier les dépendances
Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.
Je ne comprends pas ce que tu veux dire dans ta seconde phrase ? Je pense que l'idée c'est de ne pas mettre une dépendance sur un service appelé par gnome via dbus occasionnellement par exemple.
C’est vrai, l’uniformisation du system permet d’uniformiser les configs… mais si c’était un argument, il n’y aurait pas 300 distribution GNU/Linux. Quitte à uniformiser, je préfère openrc. En même temps, je suis gentooiste.
Je pense qu'il compare rc.sysinit et systemd. Il ne parle pas de l'ensemble des alternatives et de leur intérêt à chacune.
logind fait le boulot que consolekit devrait faire (suivre les sessions utilisateurs, donner des droits, etc)
À bon. Consolekit ne répond pas aux exigences. Quand je lis devrait je comprends que consolekit ne répond pas au besoin de cette personne d’Arch, mais en quoi c’est-il ce que consolekit devrait faire ? Les dév de consolekit doivent le savoir également, et donc faire la correction, non ?
J'ai traduit modestement ce qu'il disait, mais c'est peut être une subtilité que j'ai introduit malencontreusement. La vo :
logind will finally deliver on what consolekit was supposed to do: we can now track user sessions and seats, assign permissions to resources on-the-fly etc. This should be the topic of a separate message, as it is too much to get into. Suffice it to say that I'm very happy that we are finally getting these features working as they should.
C'est le « consolekit was supposed to do » qui m'a fait penser qu'il ne faisait pas ce qu'il était censé faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
La lecture du long message (en anglais) de Tom Gundersen (le mainteneur de SysVinit dans Archlinux) est intéressante. Il précise plusieurs raisons techniques qui justifient, à ses yeux, l'adoption de systemd. Ça se passe sur ce lien (seule la seconde partie du message est pertinente, après le « Benefits »).
C'est très intéressant. Grosso modo :
il supporte des configurations mouvante (hot plug) : on branche un disque, il lance fsck et le monte proprement
on peut connaître l'état du système : systemd connaît l'état de tout les deamons
c'est modulaire : on peut remplacer des parties par nos propres scripts (et ces parties sont bien documentées), il dit que c'est plus compliqué avec rc.sysinit car les dépendances sont moins claires
on peut plus facilement lancer un service à la demande notamment avec udev
les sockets activation et dbus activation permettent de simplifier les dépendances
on gagne en sécurité via les cgroup
on peut capitaliser les fichiers de descriptions de services (fini les scripts spécifiques à chaque distribution)
c'est plus simple pour eux d'être plus proche de l'upstream
logind fait le boulot que consolekit devrait faire (suivre les sessions utilisateurs, donner des droits, etc)
il est rapide ou pas, mais il s'en fout
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Y'a un filtre sur les messages suivant ce qui plait aux dévs?
Quelqu'un qui teste, qui remonte des bugs et/ou qui poste une critique constructive sur la mailing liste des développeurs est un contributeur.
Quelqu'un qui teste et qui balance un « c'est trop nul, les développeurs font des choix pourris à l'encontre des utilisateurs !!!! » sur DLFP1 sont des troll.
Il y a 2 grosses de différences entre les 2 approches :
dans le premier cas, il y a une tentative de discussion avec les développeurs ;
dans le premier cas, il y a une volonté d'améliorer les choses plutôt que de considérer qu'il faut tout jeter.
1 : par DLFP j'entends n'importe quel canal qui n'est pas dans la liste des moyens de communication décrite sur le site du projet souvent les développeurs ont une mailing list et éventuellement un canal IRC. Facebook, google+, DLFP, clubic ou je ne sais quel forum ce n'est pas un moyen de contacter les développeurs en question. De plus c'est plus diplomate de commencer par un canal spécialisé (et public) avant de commencer à baver sur une solution, disons que ça rend pas les développeurs plus enclins à l'écoute (oui oui ils sont humain et peuvent se braquer si tu commence par les prendre à revers).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ceci dit, Debian a une variante sur noyau FreeBSD […]
Ainsi qu'hurd et à une époque on parlait de portage vers le noyau NetBSD. Sans chercher à faire rire, Debian cherche depuis longtemps a avoir différent noyaux et avoir des scripts d'init différents pour chacun deviendrais compliqué à maintenir.
Peut être que la solution serait un openrc qui mange exactement le même format que systemd, comme ça il n'y aurait pas à réécrire les scripts pour chaque noyau ou d'une manière inverse demander à systemd d'exécuter les scripts init classiques (voir des script Openrc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par barmic . En réponse au journal Documentation du format du Journal. Évalué à 6.
Placé dans un même fichier il t'empêche juste d'utiliser grep, sed et autres awk dont certains expliquent qu'ils sont vitaux pour leur survit ou ceux de leur entreprise. Oui grep fonctionne mais il n'est pas efficace car on se retrouve avec du bruit qui pourris toutes les sorties, etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par barmic . En réponse au journal Documentation du format du Journal. Évalué à 3.
Ben ça dépend ton index il est en binaire ou pas ? S'il est en binaire pourquoi diantre l'est-il ? Pas pour des raisons de performances j'espère parce qu'on peut très bien avoir des performance en fichier texte.
Si je lui demande de le lire tout de même il voit des bouts de textes dedans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par barmic . En réponse au journal Documentation du format du Journal. Évalué à 2.
Ces idiots de chez sqlite ne connaissent rien de la puissances de grep, sed et awk ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par barmic . En réponse au journal Documentation du format du Journal. Évalué à 5.
Tu viens d'expliquer pourquoi ils utilisent leur propre format et non pourquoi ils utilisent un format binaire.
Il y a le problème de la performance : un log ça peut être gros (tu peux chercher sur plusieurs semaines si tu as envie), les log binaires sont plus petits (les écritures aussi sont plus petites donc on charges moins les buffers noyau) et la recherche y est plus performante. Il y a aussi une question de fiabilité. La recherche par expression rationnelle a des limites (les séparateurs peuvent se trouver n'importe où).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dommage
Posté par barmic . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
A mais j'ai pas dis le contraire :)
Ça me paraît un peu moins agréable mais beaucoup plus souple que le mot clef with de python ou java (qui sont intéressants avec une ressource unique).
Quel langage implémente cette fonctionnalité ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dommage
Posté par barmic . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Je ne pense pas que retarder le problème soit une bonne façon de gérer les try catch. Personnellement en même temps que je réfléchis aux paramètres et au retour d'une fonction, je me pose la question des exceptions (de quoi à besoin ma fonction ? à quoi elle sert/qu'est ce qu'elle retourne ? pourquoi/comment elle peut planter ?). Il me semble que c'est comme ça que ça reste logique. Ensuite l'architecture d'une application peut beaucoup aider (dans une archi à composant les composants ne doivent pas se vautrer salement déjà).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rust
Posté par barmic . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #42. Évalué à 2.
Je n'ai pas dis le contraire. Ce qui va faire la différence ce n'est pas le langage, mais ce que les gens vont en faire (qu'elles bibliothèques/framework vont arriver ? quels projets à forte visibilité vont y passer ou être construit avec ?). D'après ce que j'ai compris les créateurs de Go l'ont pensé pour les développeurs C/C++ et finalement c'est des développeurs python/ruby qui s'y mettent, mais je ne pense pas que ces derniers vont lâcher leur langage de prédiction pour autant. Ils utiliseront un langage dynamique pour tout ce qui est web et interface utilisateur et utiliseront go pour faire du système.
Mais ce n'est là que mon avis « nostradamusien » et « pifometrique » (reconnu « pif le moins fiable » par meteo France 3 années de suite).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dommage
Posté par barmic . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Il y a plusieurs choses à voir.
D'une part il n'y a qu'une partie des exceptions qui doivent être gérées (soit en étant attrapées soit en étant déclarée plus haut). Les Error et les RuntimeException ne sont pas obligatoirement gérées (en fait d'un point de vu pratique c'est des choses qui peuvent arriver n'importe quand. Ce sont les CheckedException qui doivent être gérées.
Pour ce qui est des problèmes de contamination que ça entraine. De mon point de vu une méthode cliente doit gérer l'exception (ou l'encapsuler) et je ne pense que que c'est un problème que la méthode cliente ai un couplage fort avec la classe appelée.
D'autre part même si c'est plus verbeux, je ne trouve pas ça plus contraignant que le pattern matching qu'on trouve avec l'inférence de type.
Si j'ai bien compris. Dans un bloc d'instruction on place une instruction du type :
et si on sort de ce bloc en erreur (pour le cas en exemple), la méthode foo est appelée. Par contre la documentation semble dire que la détection des erreurs se fait encore via des exceptions (ou alors je n'ai pas compris « scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. »). Donc ça ne remplace pas vraiment les exceptions.
Je ne vois pas non plus comment tu peut gérer certains cas avec. Pour libérer des ressources c'est super (les exemples le montre), mais quand il s'agit de gérer une erreur par exemple pour écrire dans un log ou remonter une information à l'utilisateur, tu es obligé d'utiliser une variable globale qui va contenir l'information alors dans quand les cas « classiques » (qu'on trouve en Java ou C++ par exemple) c'est l'exception qui contient cette information. Ça me semble plus propre.
Les valeurs null sont une plaie. D'ailleurs on vois en Java avec common lang, guava ou la dernière version de Java SE qu'une partie des aides sont en faites des helpers pour gérer les valeurs null. J'aime bien l'approche patern matching qu'on trouve dans les langages fonctionnels pour ça (on est obligé de gérer la valeur null (ou plutôt le type null quand celui-ci peut se présenter)). Les types nullables de C# sont plutôt pas mal je trouve, ils obligent les développeurs à gérer les cas de valeurs null.
Tu parle du fait de pouvoir corriger et rejouer la partie incriminées ? J'ai encore jamais utilisé un tel système, je ne peux pas en dire beaucoup plus que toi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pour votre prochain gestionnaire de paquets, pensez à CUDF/Dose
Posté par barmic . En réponse à la dépêche NetBSD 6.0. Évalué à 2.
On avait eu vent du sujet il y a 2 ans : CUDF, ou la résolution de dépendances universelle.
D'ailleurs à partir de wheezy, ça commence à pouvoir être utilisé dans Debian : http://packages.debian.org/wheezy/apt-cudf
Et à titre personnel je te remercie car j'ai plusieurs fois recherché cette info sans trouver plus d'infos.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Installation
Posté par barmic . En réponse à la dépêche OpenELEC 2.0 annoncé. Évalué à 2.
C'est dommage de ne pas avoir de version 64bits.
Il existe des images lives pour tester ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: R
Posté par barmic . En réponse à la dépêche Scilab version 5.4.0. Évalué à 4.
Comme l'a dis Nonolapero python peut fournir un ensemble ressemblant à R mais avec un langage bien plus généraliste et une documentation/communauté plus grande. Par contre R possède plus d'algo de base je crois.
Ensuite pour ce qui est de comparer R à octave ou autre, je pense que R est fait pour le calcul statistique alors que les autres traitent l’ensemble des mathématiques. Du coup avec scilab tu va facilement faire des intégrale alors qu'avec R tu va traiter une grande quantité de donné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: Deux merci, un paquet de platitudes, une question sans intérêt, ....
Posté par barmic . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #42. Évalué à 4.
Quel est le rapport entre les deux ? Je comprends bien qu'on puisse les « détester » chacun de leur coté mais je vois pas en quoi ils se rapprochent ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rust
Posté par barmic . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #42. Évalué à 3.
Je pense qu'il manque un mot dans la dépêche (je présume que c'est « Go »).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rust
Posté par barmic . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #42. Évalué à 2.
C'est ce qui fait qu'il est si bas dans ma liste des langages à tester. Je comprends bien leur volonté mais ça a tendance à m'exaspérer de voir de gros changements à prendre en compte dans le code.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rust
Posté par barmic . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #42. Évalué à 1.
Je trouve tout de même que si. D'une part c'est la volonté initiale des développeurs de Go, d'autre part les projets dont j'entends parler en Go c'est :
C'est pas un mal (bien au contraire), mais j'ai l'impression que ce langage amène les développeurs Python/Ruby à faire du développement système compilé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 2.
Excuse-moi j'ai mal suivi à qui tu répondais.
Je répondais à tes « Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora » où j'avais l'impression que tu parlais d'un couplage fort entre le DE et systemd.
En fait les « ordinateurs » (au sens large, tablettes comprises) sont des modulaires et leur évènement évolue dynamiquement (ils passent de connectés à une prise à une alimentation sur batterie, ils changent de réseau (pour passer d'un réseau ethernet, à du wifi ou un modem 3G), on y connecte un (ou pas) une imprimante, un disque dur en plus,…). Tout ces changements demandent soit des initialisations soit des lancement ou retrait de service. La solution des inits évènementiels consiste à dire que tout est évènement (le démarrage, l'arrêt, etc). La seconde est plus simple à prendre en main et elle me semble plus naturelle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 0.
Oula. Je me suis juste contenté de retranscrire en français les raisons qui amènent à systemd pour le mainteneur d'Archlinux (il me semble qu'il est relativement bien placé pour en parler). C'est toi qui par au quart de tour sur des propos que je n'ai pas tenu (juste retranscrit sans donner mon avis).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à -1.
Pourquoi tu dis vouloir être pris au sérieux ? Être interopérable c'est pouvoir faire fonctionner un script par exemple un script de démarrage de postgre sur fedora comme sur maegia.
Si tu te demande pourquoi tu semble n'être qu'un trolleur de bas étage voici la raison. Tu peste sans argumenter, tu pointe du doigt toute une série de logiciel sans expliquer pourquoi (qu'est ce viens faire Debian, Fedora et KDE ici ?).
Mais pour parler sérieusement (puisque c'est ainsi que tu veux qu'on prenne tes messages). Systemd a défini avec précision ces interfaces ce qui permet de le remplacer. Ubuntu le fait avec upstart. Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard. Là où sysinit est juste un standard de fait peu défini.
Réellement je n'ai pas encore touché à systemd et je suis plutôt attiré par sysint et openrc, mais c'est pas une raison pour faire preuve de mauvaise fois.
7 distributions majeures y sont passées. Même si ubuntu continue a garder upstart, gentoo openrc et debian autre chose, ça reste une harmonisation importante.
Les différences ce sont estompée (dans le temps dpkg gérait les paquets virtuels ce que rpm ne faisait pas, aujourd'hui yum peut télécharger des delta de paquet ce qu'apt n'est pas capable de faire, la gestion des fichiers de config n'est pas une chose aisée, Debian grâce à Raphël Herzog travail sur la possibilité d'installer des paquets de différentes architectures c'est quelque chose que l'on ne trouve pas à ma connaissance ailleurs). pakagekit n'est qu'une abstraction par dessus.
Il y a des projets dans ce sens (je crois me souvenir qu'un Debian Project Leader bossait dessus), mais l'ampleur de la tâche est immense ce qui fait que c'est long.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 0.
Faut garder un minimum la tête froide. Les différent gestionnaires de paquets viennent de dissensions qui n'ont jamais étaient résolu (malgré une tentative avec LSB). Là en l’occurrence une partie des mainteneurs de distributions arrivent à se mettre d'accord pour cette solution. Oui ce n'est pas une solution spécifiée de manière collégiale mais c'est des fois comme ça que ça marche le mieux (qu'il n'y a pas des discussions de durée infinie). Hors de c'est deux choses, il reste la gestion du réseau et ensuite ? Tout le reste du système est identique ou presque d'une distribution à l'autre (modulo la configuration par défaut). Ubuntu maintiens ses spécificités (upstart et unity).
Tout cela a créé des dizaines de flameware et des milliers de troll, c'est pas pour cela qu'il ne faut pas se réjouir quand des distributions arrivent à améliorer leur interopérabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 0.
Inspire bien fort, fais de la relaxation, respire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 1.
Non. C'est un problème qui possède une composante humaine.
Systemd (comme openrc) apportent une uniformisation (et une simplification) ils poussent vers un standard. Les mécanismes de base sont déjà implémenté (vérifier que le service n'est pas déjà lancé par exemple). Bien sûr tu peut contourner ces mécanismes pour créer les tiens mais ça demande un travail beaucoup plus important que celui de suivre les mécanismes classiques. Debian utilise des fonction « start-stop-deamon » mais je crois justement que c'est spécifique à Debian.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 2.
C'est peut être plus simple avec systemd qui écoute les évènement udev, plutôt que d'écrire son propre script pour udev ?
Je crois que l'idée c'est d'avoir une vision globale du système. Savoir pour un service donné s'il est lancé ou pas est simple, mais le faire de manière globale avec des services lancés à la demande (par socket activation, dbus activation ou udev) c'est plus compliqué.
Je ne comprends pas ce que tu veux dire dans ta seconde phrase ? Je pense que l'idée c'est de ne pas mettre une dépendance sur un service appelé par gnome via dbus occasionnellement par exemple.
Je pense qu'il compare rc.sysinit et systemd. Il ne parle pas de l'ensemble des alternatives et de leur intérêt à chacune.
J'ai traduit modestement ce qu'il disait, mais c'est peut être une subtilité que j'ai introduit malencontreusement. La vo :
C'est le « consolekit was supposed to do » qui m'a fait penser qu'il ne faisait pas ce qu'il était censé faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 6.
C'est très intéressant. Grosso modo :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Parallèle avec dragonfly
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 2.
Quelqu'un qui teste, qui remonte des bugs et/ou qui poste une critique constructive sur la mailing liste des développeurs est un contributeur.
Quelqu'un qui teste et qui balance un « c'est trop nul, les développeurs font des choix pourris à l'encontre des utilisateurs !!!! » sur DLFP1 sont des troll.
Il y a 2 grosses de différences entre les 2 approches :
1 : par DLFP j'entends n'importe quel canal qui n'est pas dans la liste des moyens de communication décrite sur le site du projet souvent les développeurs ont une mailing list et éventuellement un canal IRC. Facebook, google+, DLFP, clubic ou je ne sais quel forum ce n'est pas un moyen de contacter les développeurs en question. De plus c'est plus diplomate de commencer par un canal spécialisé (et public) avant de commencer à baver sur une solution, disons que ça rend pas les développeurs plus enclins à l'écoute (oui oui ils sont humain et peuvent se braquer si tu commence par les prendre à revers).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian et systemd
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 5.
Ainsi qu'hurd et à une époque on parlait de portage vers le noyau NetBSD. Sans chercher à faire rire, Debian cherche depuis longtemps a avoir différent noyaux et avoir des scripts d'init différents pour chacun deviendrais compliqué à maintenir.
Peut être que la solution serait un openrc qui mange exactement le même format que systemd, comme ça il n'y aurait pas à réécrire les scripts pour chaque noyau ou d'une manière inverse demander à systemd d'exécuter les scripts init classiques (voir des script Openrc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)