En quoi elle est paralysée ? L'accès au fichier a subit 2 grosses mises à jour (nio et nio2), l'IHM en eu une grosse (swing pour remplacer awt). Oui on pourrait peut être espérer plus de nouveautés (swing commence à moisir par exemple), mais ça n'a rien à voir avec la compatibilité.
Effectivement, cela n'a rien à voir avec la compatibilité puisque AWT, io et Date, dont plus de la moitié de l'API est deprecated, se trouvent toujours dans l'API…
C'est quoi ta définition de paralysée ? Parce que si c'est le fait qu'elle ne peux plus évoluée, j'ai tenté de donner des exemples d'évolutions.
Et donc, ça fait donc 15 ans que la compatibilité n'a pas été cassée.
Je suis impressionné qu'on puisse voir ça comme un 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)
Le problème, ce n'est pas qu'elle ne me plaît pas mais simplement, comme le dit Cykl, elle est paralysée.
En quoi elle est paralysée ? L'accès au fichier a subit 2 grosses mises à jour (nio et nio2), l'IHM en eu une grosse (swing pour remplacer awt). Oui on pourrait peut être espérer plus de nouveautés (swing commence à moisir par exemple), mais ça n'a rien à voir avec la compatibilité.
Personnellement, je pense que quelque chose qui est deprecated devrait sortir de l'API au bout de deux ou trois révisions du langage, quitte à y revenir sous une autre forme plus tard.
La dénomination commerciale/publique du langage depuis Java 5 est justement « Java 5 », « Java 6 » et « Java 7 », mais l'API est en version 1.5, 1.6 et 1.7. Ils se permettront de casser la compatibilité pour la version 2.x (pas prévue à ce que je sache).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ce que je ne comprends pas, c'est que tu parle de problème de bibliothèque standard (je ne dis pas qu'elle n'a pas de problème) et qu'il est nécessaire d'utiliser des bibliothèques autres pour faire certaines choses. Hors la plupart des langages compilés sans JIT ont une bibliothèque standard bien plus petite (je pense en particulier à C et C++, mais c'est applicable à d'autres). Je suis d'accord qu'une partie des bibliothèques actuelles sont trop grosses, mais le problèmes c'est surtout qu'elles sont trop grosses et cherchent à faire un peu trop de choses.
Y'a un moment ou il faut faire quelque chose (et on peut le faire sans rien, ou trop, casser) mais le JDK à du mal.
Sans trop casser ce n'est pas acceptable pour la politique de Java. Les nouvelles versions du langage ont déjà bien du mal à être utilisée donc casser la compatibilité même faiblement ce serait se tirer une balle dans le pied. Il n'y a qu'à voir les sécurités Java2 qui ne sont que très rarement utilisées. Sans rien casser je demande à voir. Par exemple tu reproche l'API d'accès au fichier. En Java 5 est arrivé Scanner qui simplifié la lecture en en Java 7 nio2 fini le travail, tu peut toujours continuer à utiliser les anciennes API (d'ailleurs nio2 ne remplace pas tout nio ni tout io). Le projet fonctionne par ajout de fonctionnalités dans l'API, mais c'est apparemment assez difficile de se mettre d'accord (par exemple les lambdas semblent être un vrai combat dans le JCP).
En fait le problème est juste délégué d'un niveau on se retrouve avec un sale JAR hell et des dépendances délirantes.
AMHA c'est surtout du à une très forte réutilisation, là où les autres écosystème en font beaucoup moins. C'est lié à la taille des bibliothèques qui cherchent toute à te préparer une expresso en réutilisant chacune une café différent (ou des fois le même café mais pas de la même année).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Pour prendre l'exemple le plus grossier il a fallut attendre fin 2011 pour avoir un accès basique aux fichiers.
C'est marrant tu reprend Guillaume qui dit que le langage c'est amélioré (en fait on parle là plus de la bibliothèque standard que dans le langage en lui même) et l'argument que tu donne c'est quelque chose qui justement a évolué dans le bon sens.
Il y a eu d'énorme loupés dans le design de lib standard et des collections qui ne sont pas corrigés par soucis de backward compatibilité
Et ça c'est bien. Si tu as besoin d'un langage qui a le comportement inverse choisi python.
forcent à mélanger 100 bibliothèques qui font la même chose (bonjour commons, guava & les amis)
Par common, je présume que tu parle de common collections principalement. Elle est presque inutilisable aujourd'hui à cause de sa compatibilité Java 1.4 (pas de généricité).
Pour guava une partie n'a plus de sens avec Java 7 grâce à des évolutions de la bibliothèque standard et du langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas
Dans un monde de bisounours ton environnement est clean. Même le mien, que je bichonne, n'est pas clean, mais il est très stable.
(Oui on peut être stable sans être clean lorsque l'on sait gérer son système)
T'as un environnement qui tiens à peine avec des bouts de ficelles que tu ai le seul à maitr faire tomber en marche et tu en es fiers en expliquant qu'un outil qui te pousserais à faire mieux serait mauvais ? La prochaine fois tu nous explique que l'haskel c'est pourri parce que le typage est fort ?
En gros, pour vous les Gentooistes sont incapables d'avoir une bonne méthode pour connaître les problèmes de sécurité d'un soft sans la MAJ.
Par exemple, si le OpenSSL nouveau débarque, ils ne sauraient pas ? Vous plaisantez là ?
Bref, c'est n'importe qui qui fait du Gentoo quoi. Vous êtes un peu gonflé non?
Homme de paille ?
Dites vous croyez qu'ils sont stupides chez Nginx, ou dans le kernel.org pour préferer un JSON like ?
$ less /boot/config-$(uname -r)
Ils font quoi chez kernel.org ?
Tu parle d'absence d'argumentation, mais là tu ne présente aucun argument mis à part un argument d'autorité relativement pourris pour nous dire que ini c'est null.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Un autre avantage d'une registry, c'est qu'elle pourrait être étendue relativement facilement pour gérer elle-même le versionning.
Puisque vous partez là dessus, moi ce qui me gêne le plus c'est l'export de la configuration d'un logiciel (un seul). Je ne crois pas avoir vu ce genre de choses ni dans dconf ni sous windows. Notez que pour configurer le système ça ne pose pas de problème.
Sinon oui comme l'arborescence d'une base de registre pourrais indiquer les versions de logiciel /Apps/MySoft/1.0/* et /Apps/MySoft/2.0/*, mais justement ça n'a rien de problématique pour un système de fichier. Dans un cas comme dans l'autre le logiciel pourrait réimporter lui-même les anciennes configuration dans la nouvelle version.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Si les parametres etaient separes, le probleme ne se poserait tout simplement pas (qui a dit le mot registry ?)
Si, si ça continue. Si le logiciel change de paramètres alors tu doit faire un merge entre les anciens paramètres et les nouveaux. Certains logiciels sont très stables à ce niveau là alors que d'autres non. Je vois pas le besoin de la base de registre pour faire ça : des fichiers ini, xml, yaml, json par logiciel suffisent amplement (je ne trollerais pas plus sur la base de registre ce serais mesquin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Comprends bien que je me fou de VP8. Mon commentaire n'en tenais pas trace.
La qualité dépend de l'espace disque.
Oui et tout les algo ont la même courbe ? Mais ensuite il y en a d'autres, la possibilité (ou la facilité) de faire du streaming par exemple, la performance lors de la compression ou de la décompression (logiciel ou hardware) et probablement un tas que le néophyte que je suis en la matière n'imagine même pas.
Un autre peut être mieux dans un autre domaine.
Oui mais de quel domaine tu parle ? Tu dis que H26{4,5} sont les meilleurs sans donner de domaine particulier et surtout en disant que tout le reste (que ce soit VP8 ou MPEG-4 Visual) c'est du pipi de chat.
Juste posez vous une question : tout le monde ou presque s'en fout de VP8, pourquoi? Tout le monde regarde H265 et ne connait même pas VP9, pourquoi?
Il y a tellement peu de monde qui utilise autre chose (VP8 ou autre relire la première ligne) que mediainfo est inutile, n'est ce pas ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Mais en fait je m'en fout : je m'interesse au premier choix en fait, le second est comme le dernier : à ne pas utiliser.
Je trouve bizarre cette discussion. De mon point de vu de néophyte, il y a 2 axes pour comparer des formats/encodeurs : la qualité (le fait d'avoir une retranscription la plus proche possible de l'originale) et l'espace disque. Il y en a probablement d'autres comme la performance en lecture ou en écriture. Je ne vois pas comment un format pourrait être meilleur que tous dans chaque domaine (puisque c'est ce qui ressort du « le second c'est de la merde »).
De plus il y a un paquet de format d'image, le jpeg le plus utilisé sort beaucoup d'artefacts dès qu'il est un peu compressé, png est super pour des images avec de grandes surfaces d'une même couleur, tiff/bmp ne compressent pas pour ainsi dire, etc Je vois pas comment sans avoir de format d'image qui se démarque réellement des autres, on peut créer un format de vidéo qui déchire tout les autres.
Bref tu aurais pas oublié de te rasé ce matin dans ta caverne ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Mais c'est un problème compliqué, car parfois, un fichier de configuration n'arrive pas à exprimer toutes les subtilités de ce que tu veux exprimé, et parfois, faut juste essayer de rentrer dans les clous.
Il faut voir au cas par cas. Dans un certain nombre de cas un système comme apt avec les sources.list.d est très largement suffisant (principe aussi utilisé dans grub2 et dans la gestion des connexions graphiques sous debian). OpenSSH se contente assez bien d'un fichier clef/valeur et /etc/networks/interfaces ne fais au contraire rien dans ce sens.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Mais ça n'a d'intérêt que si tu sépare le coté scripting de la configuration. Par exemple imaginons un script qui lance un service de manière simpliste :
#!/bin/bashPORT=80
function start {
/usr/sbin/serveur --port "$PORT"}case"$1" in
'start') start;;
# suiteesac
Si une nouvelle version arrive et maintenant pour passer le port on utilise plus l'option --port, mais une variable d'environnement. Si tu as modifié le port, tu es marron.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Ouai je comprends. Ça me paraît être un mauvais usage de l'initsysv. Je viens de regarder dans ma distrib' (debian stable) ssh ne souffre pas de ce problème mais exim si.
Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part.
En effet. Mais une autre solution plus vielle que les cgroups consiste à utiliser les namespaces pour créer un nouveau pool de pid, ton script shell deviens le PID=1 et tout les fils reviennent vers toi quoi qu'il arrive. Je ne sais pas s'il y a des effets de bords à cette méthode par contre (mais je ne crois pas que ça ai était utilisé un jour par un système d'init).
(oui je sais que cgroups fais bien plus que ça notamment pour gérer l'ordonnanceur)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
le fait de modifier le fichier fait qu'il risque de passer à coté d'une modification, car c'est plus proche d'un script. Pareil, il mets la correction de ce souci comme avantage de systemd.
Je n'ai pas bien compris ça. Tu peux en dire plus, s'il te plaît ?
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Je trouve ça bizarre pourquoi ne pas faire :
wait$PID_BIND &
PID_WAITING=$!
rdnc # + liste éventuelle d'argumentswait$PID_WAITING
L'attente n'est pas active, ne dépend pas de durée arbitraire estimées dans le meilleur ou le pire cas et pas de race condition. Bien sûr c'est moins propre que les cgroup notamment à cause des éventuels fils, mais ça me semble mieux que les solutions dont tu parle.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Oui c'est proposé par Lennard, mais rien de très spécifique à systemd là dedans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Quel esprit torturé… :) Tu prend toujours les exemples les plus tordus possibles pour illustrer tes idées sans explications ?
Ok donc si le message de bob se perd ou arrive après celui d'alice. Tu va l'ajouter dans l'historique (c'est spécial d'un point de vu utilisateur), maintenant si le message de charlie ou garspard se perd tu fait comment ?
Sinon c'est mignon de recréer un balisage dans du json. Ça permet de se fader deux parsers dont un à partir de 0 ^
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je comprends mal ton exemple. La partie content. On a l'utilisateur charlie qui dis « Bonjour Charlie » en réponse à un message de garspard qui dis « Bonjour Charlie » ? Pourquoi un coup l'identifiant est de la forme d'un email et la fois d'après c'est un username ?
Les 2 premiers identifiants identifient des messages alors que les deux de la partie content identifient des utilisateur, c'est ça ?
Que représente le $norloge ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Un FS déjà déployé partout (donc FAT, ISO et éventuellement NTFS) et libre ? Non ça n'existe pas (à moins qu'ISO en lecture seule te conviens). Repasse dans 5 ans peut être.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc en gros, HL Lamport suffisent pour du dialogue à 2 participants. A N participants (N potentiellement grand) et avec des communications asynchrones, le problème se corse : tu dois garder des structures (vecteurs ou matrices) en O(N) et les faire transiter dans chaque message.
Et encore tu n'a pas pris en compte que ce N est dynamique et peut grandir et réduire. Les horloges de Lamport sont bien pour des réplications de serveurs (tu garde un pool de serveurs synchronisés), mais pour un fonctionnement sur un réseau asynchrone avec un nombre variable de nœuds, je ne pense pas que ce soit une bonne idée.
Il faut aussi prendre en compte l'éventualité d'une attaque du réseau. De ce que je crois savoir les horloges de Lamport supportent très mal les pannes byzantines.
Bref, si vous voulez vraiment gardez des norloges en pair à pair je vous conseille la synchro UTC. Et je peux étayer mes dires avec des publications si besoin est :)
Ça m'intéresse. Je n'ai étudié que les grandes lignes des réseaux paire à paire (structuré ou non) avec comme problématique la recherche de ressources/documents. Comment fais-tu pour assurer le séquencement des messages ? À moins de s'amuser à modifier l'historique (te rendre compte que tu as un nouveau message qui est apparu 10min avant le dernier message que tu as délivré), je ne vois pas comment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Promouvoir le web : en quoi est-ce un intérêt ? Je ne vois pas pourquoi il faudrait promouvoir les web app et le web en général. Ce n'est pas « le Bien » absolu.
ça c'est pas une question de firefox os mais de mozilla dans son ensemble. ils en parlent en long et en large depuis plusieurs années.
Et pour l'instant, en quoi Firefox OS innove-t-il ? Je n'ai pas regardé la présentation en détail, mais pour l'instant, je n'ai rien vu qu'il n'existe déjà sur d'autres OS.
comme déjà dis ce sont les api qui le sont et par elles la volonté de créer un standard pour le développement mobile.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et tu ne vérifie pas que la copie de ta sauvegarde c'est bien faite ? Si c'est le cas c'est dommage.
Si bien sûr, avec l'outil de transfert, une vérification périodique des checksum est effectuée.
Ça ne fait pas de mal que ton outil de copie le fasse. Personnellement une fois j'ai un peu à la va vite fait une copie d'un gros fichier sur une clef avant de partir pour me rendre compte pendant mon voyage (quand j'en avais besoin) que la copie c'était mal passé. C'est pas agréable.
D'ailleurs (je sais pas sur quoi tu fais tes backups) mais btrfs et zfs font eux aussi des checksum sur les (meta ?)données et au moins pour btrfs, il est capable de corriger les erreurs si le volume en question est en RAID autre que 0. Ce n'est pas parce que ta couche en dessous n'est pas fiable que tu ne peut pas par dessus ajouter de la fiabilité (comme en réseau) et c'est très agréable quand ton origine ou ta destination ne sont pas des périphériques branchés en IDE/SATA/SCSI.
Bref ça peut être utile.
Au lieu d'utiliser ce genre d'arguments, je sais que la forme de mon discours est perfectible, pourrais-tu répondre sur le fond ?
Comprends que c'est lié et quand tu rentre dans le lard de ton interlocuteur ça a plus tendance à le braquer.
J'ai une opinion, je l'exprime
Et c'est très bien ! (vraiment je parlais de la forme et pas du fond)
comme étant la mienne sans généraliser, il est vrai que je pourrais l'exprimer différement.
Tu n'a peut être pas tendance à généraliser mais tu donne vraiment l'impression de rabaisser les autres. Notamment dès le départ quand tu les met dans une jolie boite : ceux qui utilisent des gestionnaires de fichiers alors que toi tu fais de la CLI (alors que vcp et gcp entre autre montre que ce besoin est exprimé aussi par des utilisateurs de CLI).
Et ce n'est pas tuner son noyau de choisir des valeurs adaptées à son usage. D'ailleurs des programmes permettent très facilement de régler ce genre de chose, par exemple laptop-mode-tools.
Si c'est tuner son noyau, mais il n'y a aucun mal si je connaissais cette technique je l'aurais probablement fais. Je n'ai absolument rien contre.
Par contre j'ai des questions sur ta technique.
Tu augmente la quantité de pages sales que le noyau accepte. Ça reviens à augmenter le buffer de lecture (comme tu l'a bien dis les écritures sont asynchrones donc on s'en fout). Dans les fait comment ça se passe ? Si tu fais un read(fd, buff, SIZE); le noyau va se permettre de lire plus préventivement ? ou est-ce que ça s'applique principalement sur des appels comme mmap ?
Au final, de ce que j'en comprend, si je fais un cp -R /etc /etc-back & cp -R /usr /usr-back le noyau va prendre le premier fichier de /etc le mettre en cache pour l'écriture ultérieur, puis il va prendre le second fichier de /etc ou le premier fichier de /usr le lire et mettre en cache pour son écriture. Ça n'est pas idiot. Un intérêt c'est que c'est indépendant de l'utilisateur. Mais je pense que c'est un peu pointu de faire ça via les le nombre ou le ratio de pages sales (il peut y avoir des implications auquel je ne pense pas). Ça devrait être dans une politique de lecture.
Par contre pour les gros fichiers (ceux qui sont trop gros pour que tu les mettent en cache), il vaut mieux utiliser une technique comme ultracopier, car il faut que l'utilisateur voit pourquoi son fichier n'est pas entrain d'être lu et qu'il puisse mettre en pause la copie qui le bloque (parce que la première est moins prioritaire pour lui). Bien sûr tu peut faire un Ctr+z sur le cp en question, mais c'est moins pratique il faut savoir que c'est bien lui qui bloque.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Moi je ne considère pas un disque comme fiable. Je dois être parano. Donc pour moi, écrire de manière fiable sur un support qu'il ne l'est pas, ce n'est pas très utile. Pour cela j'utilise d'autres solutions pour garantir la pérennité de mes données (comme des sauvegardes délocalisées)
Et tu ne vérifie pas que la copie de ta sauvegarde c'est bien faite ? Si c'est le cas c'est dommage.
Mais ce qui est vraiment dommage c'est de te voir depuis 2 jours aligner les "moi je …" tune mon noyau, n'est pas besoin de… etc en prenant un peu tout le monde de haut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par barmic . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 2.
C'est quoi ta définition de paralysée ? Parce que si c'est le fait qu'elle ne peux plus évoluée, j'ai tenté de donner des exemples d'évolutions.
Je suis impressionné qu'on puisse voir ça comme un 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: Usine
Posté par barmic . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 2.
En quoi elle est paralysée ? L'accès au fichier a subit 2 grosses mises à jour (nio et nio2), l'IHM en eu une grosse (swing pour remplacer awt). Oui on pourrait peut être espérer plus de nouveautés (swing commence à moisir par exemple), mais ça n'a rien à voir avec la compatibilité.
La dénomination commerciale/publique du langage depuis Java 5 est justement « Java 5 », « Java 6 » et « Java 7 », mais l'API est en version 1.5, 1.6 et 1.7. Ils se permettront de casser la compatibilité pour la version 2.x (pas prévue à ce que je sache).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par barmic . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 2.
C'est pas l'optique de Java, C, C++, Fortran, ADA et un tas d'autres langages qui veulent pouvoir être utilisé dans des endroits critiques.
Personnellement je ne vois pas en quoi c'est un problème une API qui ne plaît pas il suffit de ne pas l'utiliser.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par barmic . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 2.
Ce que je ne comprends pas, c'est que tu parle de problème de bibliothèque standard (je ne dis pas qu'elle n'a pas de problème) et qu'il est nécessaire d'utiliser des bibliothèques autres pour faire certaines choses. Hors la plupart des langages compilés sans JIT ont une bibliothèque standard bien plus petite (je pense en particulier à C et C++, mais c'est applicable à d'autres). Je suis d'accord qu'une partie des bibliothèques actuelles sont trop grosses, mais le problèmes c'est surtout qu'elles sont trop grosses et cherchent à faire un peu trop de choses.
Sans trop casser ce n'est pas acceptable pour la politique de Java. Les nouvelles versions du langage ont déjà bien du mal à être utilisée donc casser la compatibilité même faiblement ce serait se tirer une balle dans le pied. Il n'y a qu'à voir les sécurités Java2 qui ne sont que très rarement utilisées. Sans rien casser je demande à voir. Par exemple tu reproche l'API d'accès au fichier. En Java 5 est arrivé Scanner qui simplifié la lecture en en Java 7 nio2 fini le travail, tu peut toujours continuer à utiliser les anciennes API (d'ailleurs nio2 ne remplace pas tout nio ni tout io). Le projet fonctionne par ajout de fonctionnalités dans l'API, mais c'est apparemment assez difficile de se mettre d'accord (par exemple les lambdas semblent être un vrai combat dans le JCP).
AMHA c'est surtout du à une très forte réutilisation, là où les autres écosystème en font beaucoup moins. C'est lié à la taille des bibliothèques qui cherchent toute à te préparer une expresso en réutilisant chacune une café différent (ou des fois le même café mais pas de la même année).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par barmic . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 3.
C'est marrant tu reprend Guillaume qui dit que le langage c'est amélioré (en fait on parle là plus de la bibliothèque standard que dans le langage en lui même) et l'argument que tu donne c'est quelque chose qui justement a évolué dans le bon sens.
Et ça c'est bien. Si tu as besoin d'un langage qui a le comportement inverse choisi python.
Par common, je présume que tu parle de common collections principalement. Elle est presque inutilisable aujourd'hui à cause de sa compatibilité Java 1.4 (pas de généricité).
Pour guava une partie n'a plus de sens avec Java 7 grâce à des évolutions de la bibliothèque standard et du langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vraiment ?
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 6.
T'as un environnement qui tiens à peine avec des bouts de ficelles que tu ai le seul à
maitrfaire tomber en marche et tu en es fiers en expliquant qu'un outil qui te pousserais à faire mieux serait mauvais ? La prochaine fois tu nous explique que l'haskel c'est pourri parce que le typage est fort ?Homme de paille ?
Ils font quoi chez kernel.org ?
Tu parle d'absence d'argumentation, mais là tu ne présente aucun argument mis à part un argument d'autorité relativement pourris pour nous dire que ini c'est null.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Puisque vous partez là dessus, moi ce qui me gêne le plus c'est l'export de la configuration d'un logiciel (un seul). Je ne crois pas avoir vu ce genre de choses ni dans dconf ni sous windows. Notez que pour configurer le système ça ne pose pas de problème.
Sinon oui comme l'arborescence d'une base de registre pourrais indiquer les versions de logiciel /Apps/MySoft/1.0/* et /Apps/MySoft/2.0/*, mais justement ça n'a rien de problématique pour un système de fichier. Dans un cas comme dans l'autre le logiciel pourrait réimporter lui-même les anciennes configuration dans la nouvelle version.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
Ça m'a l'air intéressant, tu as un pointeur à ce sujet ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 5.
Si, si ça continue. Si le logiciel change de paramètres alors tu doit faire un merge entre les anciens paramètres et les nouveaux. Certains logiciels sont très stables à ce niveau là alors que d'autres non. Je vois pas le besoin de la base de registre pour faire ça : des fichiers ini, xml, yaml, json par logiciel suffisent amplement (je ne trollerais pas plus sur la base de registre ce serais mesquin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Round 2 : fight !
Posté par barmic . En réponse à la dépêche H.265 est finalisé. Évalué à 4.
Comprends bien que je me fou de VP8. Mon commentaire n'en tenais pas trace.
Oui et tout les algo ont la même courbe ? Mais ensuite il y en a d'autres, la possibilité (ou la facilité) de faire du streaming par exemple, la performance lors de la compression ou de la décompression (logiciel ou hardware) et probablement un tas que le néophyte que je suis en la matière n'imagine même pas.
Oui mais de quel domaine tu parle ? Tu dis que H26{4,5} sont les meilleurs sans donner de domaine particulier et surtout en disant que tout le reste (que ce soit VP8 ou MPEG-4 Visual) c'est du pipi de chat.
Il y a tellement peu de monde qui utilise autre chose (VP8 ou autre relire la première ligne) que mediainfo est inutile, n'est ce 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: Round 2 : fight !
Posté par barmic . En réponse à la dépêche H.265 est finalisé. Évalué à 1.
Je trouve bizarre cette discussion. De mon point de vu de néophyte, il y a 2 axes pour comparer des formats/encodeurs : la qualité (le fait d'avoir une retranscription la plus proche possible de l'originale) et l'espace disque. Il y en a probablement d'autres comme la performance en lecture ou en écriture. Je ne vois pas comment un format pourrait être meilleur que tous dans chaque domaine (puisque c'est ce qui ressort du « le second c'est de la merde »).
De plus il y a un paquet de format d'image, le jpeg le plus utilisé sort beaucoup d'artefacts dès qu'il est un peu compressé, png est super pour des images avec de grandes surfaces d'une même couleur, tiff/bmp ne compressent pas pour ainsi dire, etc Je vois pas comment sans avoir de format d'image qui se démarque réellement des autres, on peut créer un format de vidéo qui déchire tout les autres.
Bref tu aurais pas oublié de te rasé ce matin dans ta caverne ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Il faut voir au cas par cas. Dans un certain nombre de cas un système comme apt avec les sources.list.d est très largement suffisant (principe aussi utilisé dans grub2 et dans la gestion des connexions graphiques sous debian). OpenSSH se contente assez bien d'un fichier clef/valeur et /etc/networks/interfaces ne fais au contraire rien dans ce sens.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Ça me fait penser au divert dispo dans dpkg depuis que je le connais (7 ou 8 ans) http://linux.die.net/man/8/dpkg-divert
Mais ça n'a d'intérêt que si tu sépare le coté scripting de la configuration. Par exemple imaginons un script qui lance un service de manière simpliste :
Si une nouvelle version arrive et maintenant pour passer le port on utilise plus l'option --port, mais une variable d'environnement. Si tu as modifié le port, tu es marron.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
Ouai je comprends. Ça me paraît être un mauvais usage de l'initsysv. Je viens de regarder dans ma distrib' (debian stable) ssh ne souffre pas de ce problème mais exim si.
En effet. Mais une autre solution plus vielle que les cgroups consiste à utiliser les namespaces pour créer un nouveau pool de pid, ton script shell deviens le PID=1 et tout les fils reviennent vers toi quoi qu'il arrive. Je ne sais pas s'il y a des effets de bords à cette méthode par contre (mais je ne crois pas que ça ai était utilisé un jour par un système d'init).
(oui je sais que cgroups fais bien plus que ça notamment pour gérer l'ordonnanceur)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par barmic . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
Je n'ai pas bien compris ça. Tu peux en dire plus, s'il te plaît ?
Je trouve ça bizarre pourquoi ne pas faire :
L'attente n'est pas active, ne dépend pas de durée arbitraire estimées dans le meilleur ou le pire cas et pas de race condition. Bien sûr c'est moins propre que les cgroup notamment à cause des éventuels fils, mais ça me semble mieux que les solutions dont tu parle.
Oui c'est proposé par Lennard, mais rien de très spécifique à systemd là 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: Images?
Posté par barmic . En réponse à la dépêche H.265 est finalisé. Évalué à 2.
Quand tu ajoute la racine il te demande pour quels usages tu la destine. Tu peut le mettre pour les extensions si je ne m'abuse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En fait...
Posté par barmic . En réponse au journal Une tribune décentralisée est-elle possible?. Évalué à 2.
Quel esprit torturé… :) Tu prend toujours les exemples les plus tordus possibles pour illustrer tes idées sans explications ?
Ok donc si le message de bob se perd ou arrive après celui d'alice. Tu va l'ajouter dans l'historique (c'est spécial d'un point de vu utilisateur), maintenant si le message de charlie ou garspard se perd tu fait comment ?
Sinon c'est mignon de recréer un balisage dans du json. Ça permet de se fader deux parsers dont un à partir de 0 ^
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En fait...
Posté par barmic . En réponse au journal Une tribune décentralisée est-elle possible?. Évalué à 3.
Je comprends mal ton exemple. La partie content. On a l'utilisateur charlie qui dis « Bonjour Charlie » en réponse à un message de garspard qui dis « Bonjour Charlie » ? Pourquoi un coup l'identifiant est de la forme d'un email et la fois d'après c'est un username ?
Les 2 premiers identifiants identifient des messages alors que les deux de la partie content identifient des utilisateur, c'est ça ?
Que représente le $norloge ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Alternative libre ?
Posté par barmic . En réponse à la dépêche FUSE-exFAT en version 1.0.0. Évalué à 4.
Un FS déjà déployé partout (donc FAT, ISO et éventuellement NTFS) et libre ? Non ça n'existe pas (à moins qu'ISO en lecture seule te conviens). Repasse dans 5 ans peut être.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En fait...
Posté par barmic . En réponse au journal Une tribune décentralisée est-elle possible?. Évalué à 5.
Et encore tu n'a pas pris en compte que ce N est dynamique et peut grandir et réduire. Les horloges de Lamport sont bien pour des réplications de serveurs (tu garde un pool de serveurs synchronisés), mais pour un fonctionnement sur un réseau asynchrone avec un nombre variable de nœuds, je ne pense pas que ce soit une bonne idée.
Il faut aussi prendre en compte l'éventualité d'une attaque du réseau. De ce que je crois savoir les horloges de Lamport supportent très mal les pannes byzantines.
Ça m'intéresse. Je n'ai étudié que les grandes lignes des réseaux paire à paire (structuré ou non) avec comme problématique la recherche de ressources/documents. Comment fais-tu pour assurer le séquencement des messages ? À moins de s'amuser à modifier l'historique (te rendre compte que tu as un nouveau message qui est apparu 10min avant le dernier message que tu as délivré), je ne vois pas comment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pertinence de l'investissement
Posté par barmic . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 3.
ça c'est pas une question de firefox os mais de mozilla dans son ensemble. ils en parlent en long et en large depuis plusieurs années.
comme déjà dis ce sont les api qui le sont et par elles la volonté de créer un standard pour le développement mobile.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Alternative libre ?
Posté par barmic . En réponse à la dépêche FUSE-exFAT en version 1.0.0. Évalué à 3.
Tu as essayé udf ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par barmic . En réponse à la dépêche Supercopier 3. Évalué à 4.
Ça ne fait pas de mal que ton outil de copie le fasse. Personnellement une fois j'ai un peu à la va vite fait une copie d'un gros fichier sur une clef avant de partir pour me rendre compte pendant mon voyage (quand j'en avais besoin) que la copie c'était mal passé. C'est pas agréable.
D'ailleurs (je sais pas sur quoi tu fais tes backups) mais btrfs et zfs font eux aussi des checksum sur les (meta ?)données et au moins pour btrfs, il est capable de corriger les erreurs si le volume en question est en RAID autre que 0. Ce n'est pas parce que ta couche en dessous n'est pas fiable que tu ne peut pas par dessus ajouter de la fiabilité (comme en réseau) et c'est très agréable quand ton origine ou ta destination ne sont pas des périphériques branchés en IDE/SATA/SCSI.
Bref ça peut être utile.
Comprends que c'est lié et quand tu rentre dans le lard de ton interlocuteur ça a plus tendance à le braquer.
Et c'est très bien ! (vraiment je parlais de la forme et pas du fond)
Tu n'a peut être pas tendance à généraliser mais tu donne vraiment l'impression de rabaisser les autres. Notamment dès le départ quand tu les met dans une jolie boite : ceux qui utilisent des gestionnaires de fichiers alors que toi tu fais de la CLI (alors que vcp et gcp entre autre montre que ce besoin est exprimé aussi par des utilisateurs de CLI).
Si c'est tuner son noyau, mais il n'y a aucun mal si je connaissais cette technique je l'aurais probablement fais. Je n'ai absolument rien contre.
Par contre j'ai des questions sur ta technique.
Tu augmente la quantité de pages sales que le noyau accepte. Ça reviens à augmenter le buffer de lecture (comme tu l'a bien dis les écritures sont asynchrones donc on s'en fout). Dans les fait comment ça se passe ? Si tu fais un
read(fd, buff, SIZE);le noyau va se permettre de lire plus préventivement ? ou est-ce que ça s'applique principalement sur des appels comme mmap ?Au final, de ce que j'en comprend, si je fais un
cp -R /etc /etc-back & cp -R /usr /usr-backle noyau va prendre le premier fichier de /etc le mettre en cache pour l'écriture ultérieur, puis il va prendre le second fichier de /etc ou le premier fichier de /usr le lire et mettre en cache pour son écriture. Ça n'est pas idiot. Un intérêt c'est que c'est indépendant de l'utilisateur. Mais je pense que c'est un peu pointu de faire ça via les le nombre ou le ratio de pages sales (il peut y avoir des implications auquel je ne pense pas). Ça devrait être dans une politique de lecture.Par contre pour les gros fichiers (ceux qui sont trop gros pour que tu les mettent en cache), il vaut mieux utiliser une technique comme ultracopier, car il faut que l'utilisateur voit pourquoi son fichier n'est pas entrain d'être lu et qu'il puisse mettre en pause la copie qui le bloque (parce que la première est moins prioritaire pour lui). Bien sûr tu peut faire un Ctr+z sur le cp en question, mais c'est moins pratique il faut savoir que c'est bien lui qui bloque.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par barmic . En réponse à la dépêche Supercopier 3. Évalué à 3.
Et tu ne vérifie pas que la copie de ta sauvegarde c'est bien faite ? Si c'est le cas c'est dommage.
Mais ce qui est vraiment dommage c'est de te voir depuis 2 jours aligner les "moi je …" tune mon noyau, n'est pas besoin de… etc en prenant un peu tout le monde de haut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pertinence de l'investissement
Posté par barmic . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 0.
C'est pas parce qu'elle a un grande visibilité qu'elle est bien écrite (contrairement à ce qui était sous-entendu).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)