T'as au moins vu une étude quelque part qui montre que ce que tu fais à un impact positif ? Par ce que c'est vraiment s'emmerder pour pas grand chose autrement...
En chargeant absolument n'importe comment, plusieurs fois par jour, 7 jour sur 7, depuis plus de 32 mois, mon e4300; j'ai encore largement dans les 4/5h d'autonomie en mode lecture de PDF + LibreOffice. Soit une très faible perte depuis le début.
Du coup je suis pas vraiment certain que pour un portable le côté emmerdement vaille le coup par rapport aux effets réels et au coût d'une batterie neuve. Et si ça prolonge de six mois, ça change pas grand chose non plus. Dans 6 mois t'auras quand même besoin d'une nouvelle batterie. Et avec deux batteries tu couvriras largement la durée de vie du matériel quelque soit la technique...
Au contraire, un nombre incroyable de projets open-source sont les références de fait dans écosystème Java. En vérité il est même plutôt rare d'utiliser des softs non open-source... Le marché de Java c'est les serveurs et les backend de site web.
Je dirai surtout que la notion de paquet n'est pas la même : je pense TCP (si j'envoie un paquet TCP D1 puis D2, je les recevrai dans l'ordre.
Non c'est complétement faux.
- Si tu te places d'un point de vue utilisateur de la pile TCP/IP tout ce que tu peux dire c'est "transmet moi ce buffer" et "donne moi un buffer si il y a des données dispo". TCP/IP t'assures que ton stream sera identique en émission et en réception point final. Il n'y a aucune notion de paquet ou autre.
- Si tu te places du point de vue de la couche TCP alors c'est complétement faux. Le paquet arrivent dans un ordre indéterminé et sont réordonnés par le destinataire.
Jamais bossé avec X25, mais un protocole basé sur des virtual circuit ou du circuit switching par définition assure, entre autre, que les paquets ne peuvent pas arriver dans le désordre. Il n'y a donc pas de travail de re-ordonnancement à faire côté destinataire.
Si un point commun entre les deux est que le stream de l’émetteur et du récepteur sont identiques. Leur différence de fonctionnement change pas mal de choses sur les autres propriétés. Ça n'a pas d'importance si tout ce qui t'intéresse c'est que les bits émis et reçus soit identiques. Mais si tu désires d'autres propriété, notamment du point de vue latence et synchro, ca peut tout changé et demander beaucoup plus de travail au niveau de la couche applicative.
Limiter la mémoire totale prise par l'ensemble des processus issus d'un processus donne. - Quelque chose d'assez semblable pour le CPU mais la on peut se débrouiller sans trop de compromis.
Tuer tout les processus créés par un processus donne sachant que ces processus peuvent faire ce qu'ils veulent (changer de groupes, se retrouver avec un ppid = 1 et pleins d'autres choses).
Pour les autres systèmes, je visais uniquement les différents UNIX et les Linux sans cgroup. Si tu as une solution portable, ça m’intéresse grandement.
Je te posais la question par ce que tu parlais des articles system administrator que du coup j'ai lu pour me faire un avis. Et a absolument aucun moment il ne parle de desktop/NM/avahi ou autre dedans.
Dans la série il explique juste des choses simples qui semblent sensées, voir même de bonnes idées et des avancées. Apres il faut jouer avec le truc pour se rendre compte.
Pour la portabilité faut arrêter de déconner. Je dois me taper le packaging pour quelques distros. Les scripts d'init demandent des modifs entre distro pour etre propre, et passe leur temps a changer. Donc de ce cote la. Devoir maintenir plusieurs scripts bash, ou scripts bash + fichier de config pour systemd ca va pas changer grand chose. Et en dehors de linux, les scripts d'init portables...
Si on regarde juste les fonctionnalités pour les serveurs, je ne vois pas de régression et quelque progrès. J'ai rien contre le fait qu'il propose des avancées dans le desktop si ca ne compromet le reste. Il reste le problème de la complexité du processus init. Mais a ce sujet en dehors des reproches vagues, je n'ai pas vu d'argumentation convaincante dans un sens ou dans l'autre.
Cool t'as fait une super caricature. Mais tu as des arguments concrets ? Ou c'etait juste un commentaire de bar PMU ? J'ai le défaut de donner le bénéfice du doute aux gens.
Par ce que bon le coup il suffit de faire une abstraction blahblahblah j'ose penser qu'il est pas si con que ça et que tu ne viens pas de lui faire la révélation du siècle... D'ailleurs qu'on aime ou pas ce qu'il fait, ses articles laissent a penser que justement il sait ou il veut aller.
Si OpenBSD à très bonne réputation. Je ne jugerais pas d'OpenSSH vu que je n'ai jamais lu ce code en particulier (les on-dit et les généralités...).
Pour arriver à ses objectifs fonctionnels il a besoin d'utiliser des fonctionnalités qui n'existent pas (encore ?) sur d'autres systèmes. Soit il renonce à tout ou une partie de ce qu'il veut faire, soit il le fait en n'étant compatible qu'avec les systèmes offrant les mêmes fonctionnalités.
Je me suis retrouvé dans le même cas que lui il y a quelques mois. Je ne pouvais pas assurer une fonctionnalité sans les cgroups. Et bien elle est linux only et n'existe que si tu as les cgroups activés. Y'a pas de miracle. Si tu m'offres quelque chose d'équivalent sous un autre système, la fonctionnalité existera sur ce système. Je préfère être portable. Mais tu ne peux pas tout faire avec l'API POSIX... Triste réalité.
Quelles sont les propositions concrètes pour permettre de supporter plus de systèmes ? Qu'est ce qui aurait pu être mieux fait ? À quel prix (fonctionnalités/performances/maintenabilité) ? C'est facile de critiquer en restant vague. Les faits m'intéressent.
C'est un peu comme dire que SIGKILL ne sert a rien. Il suffit de supposer que tout les processus se comportent comme attendu et n'ont jamais de bug.
Le job d'un init c'est de démarrer et de terminer des processus. C'est une grande avancée si on passe de "Je fais confiance au démon pour ne pas faire de saloperies" à "Je suis capable d'identifier et de terminer tout ce qui appartient à un démon même si celui ci à eu un problème".
Avoir besoin de la coopération de code non identifié pour assurer un fonctionnement correct est forcément un constat d'échec et un signe de faiblesse. Ce qui n'empêche pas de faire en sorte que les démons se comportent correctement. Bref ce n'est pas cacher la misère, c'est résoudre un problème existant. Supposer que l'ensemble du code qu'un init peut lancer ne sera jamais soumis à un bug ou autre, je ne sais pas si c'est flippant, présomptueux ou naïf.
Non par ce que généralement quand on l'est, et ne dit pas ça et on comprend qu'à un moment il faut du feedback utilisateur. C'est pour ça qu'on fait des alpha, des beta et qu'à un moment il faut se lancer à releaser. Pour qu'un produit se stabilise et soit bon, il faut avoir des retours utilisateurs et observer ce que ça donne sur le terrain. C'est encore plus vrai quand tu bosses sur un truc qui doit gérer X composants hardware/Y configs différentes et que tu es dans l'impossibilité de tout tester exhaustivement. Ça n'a rien a voir avec de la flemme. Tu peux attendre 10 ans pour releaser, faudra essuyer les plâtres à un moment. Au mieux tu peux limiter les dégats si tu leurs offre un test bed à quelques centaines de milliers d'euros et la main d’œuvre qui va derrière pour se palucher les tests.
Si des gens ont packagé trop tôt ou mal c'est plutôt à eux qu'il faut jeter la pierre. Fedora c'est leur but d'effectuer ce travail. Ils intègrent des trucs fraichement sorti pour voir ce que ça donne et permettre de les valider/finaliser.
On retombe sur le cas de OpenSSH. L'équipe d'OpenSSH code pour OpenBSD uniquement. L'équipe d'OpenSSH-portable s'occupe de faire le portage.
OpenSSH is developed by two teams. One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable (adding the "goop") to make it run on many operating systems
On retrouve un peu les arguments qu'il avance.
Il reste à trouver des volontaires pour se farcir un portage. Je ne vois pas pourquoi ça serait à lui de faire ce boulot si il n'a ni envie, ni d’intérêt à le faire. Après évidement, si il met volontairement des bâtons dans les roues c'est un autre problème. Mais pondre du code libre ça ne veut pas dire devoir supporter toutes les volontés de tout les utilisateurs du monde. Ça veut dire permettre à qui le veut de continuer/reprendre sans entrave ce qui existe.
Tu cites OpenSSH, mais justement OpenSSH se fout ouvertement de la portabilité. Ils codent pour OpenBSD uniquement (leur motivation est justifiée et légitime) et après une seconde équipe se frappe le boulot de portage.
La vraie question n'est pas d’être portable ou non mais que doit on faire en cas de non équivalence fonctionnelle entre les systèmes ?
Exemple, si BSD n'offre pas d'équivalent aux cgroup, il dommage de se passer de cette fonctionnalité qui est une énorme avancée. Ca comble une grosse lacune. On avance ou on attend qu'hypothétiquement tout les systèmes existant implémentent une fonctionnalité équivalente ?
On peut décider d'avancer en se disant, que les autres pourront continuer d'exister comme actuellement. On ne leur retire rien, on avance simplement. On peut aussi se dire que ça les boostera pour offrir les fonctionnalités manquantes et qu'après ça ne sera que du travail de portage bête et méchant.
On peut aussi décider que c'est plus grave de fragmenter (temporairement ?) l'écosystème que de stagner.
Chacun peut avoir son opinion (et elle peut être différente selon les logiciels) mais je pense qu'il sera dur pour quelqu'un de prouver que son opinion est la meilleure et que l'autre à tord.
En lisant les conditions, ça m'a tout de suite fait penser à un article que j'ai lu au sujet du Clount by Microsoft. Il était indiqué qu'il était parfois nécessaire de fournir le contenu au autorité …
Oui. Ça s'appelle respecter la loi et ça n'a rien de spécifique au cloud. Ce n'est pas spécifique aux USA; mais depuis le patriot act, si ça te pose un problème tu ferais mieux d'éviter que tes bits résident ou passent par les USA ou une entreprise américaine. Ils ont tendance à avoir un peu beaucoup libéralisé le self-service pour le renseignement là où d'autres pays font encore croire qu'il y a besoin d'un juge.
La concurrence libre et non faussée. N'importe qui peut démarrer un marché, c'est simple et libre. Contrairement au système bancaire.
Comme partout. Si ça devient sérieux tu auras aussi à te soumettre aux réglementations.
Par ailleurs qu'est ce qui t'empêche d'ouvrir un dark pool actuellement ? Où une banque qui aurait des pratiques que tu juges correctes ?
Avec la différence que tu n'as pas besoin d'intermédiaire pour l'envoyer aux quatre coins du monde.
Envoyer la monnaie d'un point à un autre c'est uniquement une des nombreux besoins. Les intermédiaires apparaîtrons sous une forme ou une autre car ils répondent tout de même à des besoins (sans juger de leurs pratiques). Deux exemples tout bêtes parmi des dizaines :
Stocker ses bitcoins sur son ordi sans assurance c'est risqué. Y'a un marché à prendre.
Ton entreprise, pour payer les salaires un jour. Elle aura besoin de contracter un crédit.
Si ça devient sérieux et que tu laisses s'écouler quelques dizaines/centaines d'années il n'y a pas de raison objective que le résultat soit bien différent.
En quoi bitcoin empêche des intermédiaires de se sucrer ? Les places de marchés pour bitcoin prennent déjà une commission (faut bien les financer). Des intermédiaires équivalents à ceux actuels apparaitrons dans l’économie bitcoin. Et il n'y a aucun raison qu'ils se comportent différemment qu'actuellement. Ce n'est qu'une monnaie comme les autres (sans entrer dans le débat).
du FTPS qui ne coûterait rien et qui est ouvert. Impossible d'avoir une des informations techniques et une offre basée sur FTPS [...] et à louer mensuellement un accès au serveur de sa banque?
Posté par ckyl .
En réponse au journal CAPTCHA.
Évalué à 5.
Ca nous fait une belle jambe d'avoir un problème qui n'est résoluble ni par un ordinateur ni par un humain... Autant désactiver les commentaires ou le sign up ;)
Ils permettent à ceux qui veulent d'attribuer et d'utiliser des raccourcis clavier. Et de le faire très facilement pour n'importe quelle action. Ceux que ça intéresse peuvent le faire. Il y aura toujours des réglages qui plairont aux uns ou aux autres; et il y aura toujours des gens pour gueuler à tord ou à raison.
Moi ce qui me navre c'est le dénigrement perpétuel de ceux qui se bougent le cul et qui proposent quelque chose par ceux qui ne font rien. En utilisant toujours l'hypothétique "madame michu" pour se justifier. Si ça te plait pas utilise pas; pas la peine d'essayer de montrer a quel point tu es moins con qu'eux. D'ailleurs ils font tellement de la merde que tu utilises leur produit, tu dois être masochiste...
Autrement au lieu de gémir pendant 704 caractères:
1- Sélectionner un fichier de ta play queue
2- Sélectionner menu edit>remove from playlist
3- Appuyer sur delete ou n'importe quelle touche de ton choix
4- Enjoy !
Gnome c'est tellement pourri et pas configurable que ça ma pris 20 secondes pour trouver cette solution. Change vite de bureau.
C'est bien de ça dont il s'agit, à la différence près que chaque timestamp ici inclut une preuve cryptographique. Ce qui permet de travailler avec des noeuds dans lesquels on n'a pas confiance.
Oui enfin ça il faudrait encore le prouver, ce qui demande de commencer par être capable d'expliquer ton aglo et de définir ses propriétés.
Autrement y'a deux ou trois trucs qui ont déjà été prouvés concernant les systèmes distribués asynchrones dans le domaine des horloges logiques, du (partial|total)-order et des pannes byzantines ces 40 dernières années.
Entre le moment où Firefox sort, et celui où les extensions/plugins sont portés, il s'écoule du temps. Que ce soit un jour, une semaine ou un mois, pour une en entreprise ce n'est pas acceptable de se retrouver avec quelque chose qui fonctionnait un jour, et plus le lendemain.
Peut être que la release ne se fait pas du jour au lendemain et qu'il existe de RC pour pouvoir valider avant et être prêt avant le jour J ? Pourquoi tu ne gueules pas sur google ?
Peut être aussi que rien ne t'oblige a mettre à jour. Puisque c'est un outil de dev, tu utilises une install dédiée pour le développement et voilà. Ça prend pas 10 jours...
Pour de la production, oui, pour des machines de développement, faut peut être pas pousser... Quand tu installes une distrib, et que tu n'utilises pas de dépôts spécifiques, tu t'attends à pouvoir profiter des corrections de bugs et des mises à jour de sécurité, et c'est ce que fournit Ubuntu par défaut. Parce que là tu te rend bien compte que tu me demandes à choisir entre fonctionnel et sécurité. Mais je ne devrais pas avoir à choisir bon sang, je veux les deux !
Je suis sur que si vous êtes nombreux, un prestataire se fera la joie de vous offrir ce service.
[^] # Re: Chargement intelligent
Posté par ckyl . En réponse au journal De l'électronique portable et de le durée de vie des batteries. Évalué à 2.
T'as au moins vu une étude quelque part qui montre que ce que tu fais à un impact positif ? Par ce que c'est vraiment s'emmerder pour pas grand chose autrement...
En chargeant absolument n'importe comment, plusieurs fois par jour, 7 jour sur 7, depuis plus de 32 mois, mon e4300; j'ai encore largement dans les 4/5h d'autonomie en mode lecture de PDF + LibreOffice. Soit une très faible perte depuis le début.
Du coup je suis pas vraiment certain que pour un portable le côté emmerdement vaille le coup par rapport aux effets réels et au coût d'une batterie neuve. Et si ça prolonge de six mois, ça change pas grand chose non plus. Dans 6 mois t'auras quand même besoin d'une nouvelle batterie. Et avec deux batteries tu couvriras largement la durée de vie du matériel quelque soit la technique...
[^] # Re: Part de marché
Posté par ckyl . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 8.
Et les fondation Apache/Eclipse c'est du poulet ?
Au contraire, un nombre incroyable de projets open-source sont les références de fait dans écosystème Java. En vérité il est même plutôt rare d'utiliser des softs non open-source... Le marché de Java c'est les serveurs et les backend de site web.
[^] # Re: Chacun son style
Posté par ckyl . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Je te conseil de regarder la bytecode généré par javac... Dans 99% des cas, quelque soit le source tu te retrouveras avec le même bytecode.
Même au pire cas où tu utiliserais un StringBuffer quand il faut pas, il va détecter qu'il
qu'il ne peut pas avoir de concurrence sur le lock.
[^] # Re: XoT et fermeture transpac
Posté par ckyl . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 3.
Non c'est complétement faux.
- Si tu te places d'un point de vue utilisateur de la pile TCP/IP tout ce que tu peux dire c'est "transmet moi ce buffer" et "donne moi un buffer si il y a des données dispo". TCP/IP t'assures que ton stream sera identique en émission et en réception point final. Il n'y a aucune notion de paquet ou autre.
- Si tu te places du point de vue de la couche TCP alors c'est complétement faux. Le paquet arrivent dans un ordre indéterminé et sont réordonnés par le destinataire.
Jamais bossé avec X25, mais un protocole basé sur des virtual circuit ou du circuit switching par définition assure, entre autre, que les paquets ne peuvent pas arriver dans le désordre. Il n'y a donc pas de travail de re-ordonnancement à faire côté destinataire.
Si un point commun entre les deux est que le stream de l’émetteur et du récepteur sont identiques. Leur différence de fonctionnement change pas mal de choses sur les autres propriétés. Ça n'a pas d'importance si tout ce qui t'intéresse c'est que les bits émis et reçus soit identiques. Mais si tu désires d'autres propriété, notamment du point de vue latence et synchro, ca peut tout changé et demander beaucoup plus de travail au niveau de la couche applicative.
[^] # Re: Quid de la diversité et des serveurs ?
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 3.
Par ce que t'arrive a te connecter facilement sur n'importe quel reseau wifi en tant que simple utilisateur sans network manager peut être ?
[^] # Re: Ça fait peur
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 2. Dernière modification le 05 juillet 2011 à 22:52.
De mémoire :
Pour les autres systèmes, je visais uniquement les différents UNIX et les Linux sans cgroup. Si tu as une solution portable, ça m’intéresse grandement.
[^] # Re: Quid de la diversité et des serveurs ?
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 5.
Je te posais la question par ce que tu parlais des articles system administrator que du coup j'ai lu pour me faire un avis. Et a absolument aucun moment il ne parle de desktop/NM/avahi ou autre dedans.
Dans la série il explique juste des choses simples qui semblent sensées, voir même de bonnes idées et des avancées. Apres il faut jouer avec le truc pour se rendre compte.
Pour la portabilité faut arrêter de déconner. Je dois me taper le packaging pour quelques distros. Les scripts d'init demandent des modifs entre distro pour etre propre, et passe leur temps a changer. Donc de ce cote la. Devoir maintenir plusieurs scripts bash, ou scripts bash + fichier de config pour systemd ca va pas changer grand chose. Et en dehors de linux, les scripts d'init portables...
Si on regarde juste les fonctionnalités pour les serveurs, je ne vois pas de régression et quelque progrès. J'ai rien contre le fait qu'il propose des avancées dans le desktop si ca ne compromet le reste. Il reste le problème de la complexité du processus init. Mais a ce sujet en dehors des reproches vagues, je n'ai pas vu d'argumentation convaincante dans un sens ou dans l'autre.
[^] # Re: Ça fait peur
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 2.
Cool t'as fait une super caricature. Mais tu as des arguments concrets ? Ou c'etait juste un commentaire de bar PMU ? J'ai le défaut de donner le bénéfice du doute aux gens.
Par ce que bon le coup il suffit de faire une abstraction blahblahblah j'ose penser qu'il est pas si con que ça et que tu ne viens pas de lui faire la révélation du siècle... D'ailleurs qu'on aime ou pas ce qu'il fait, ses articles laissent a penser que justement il sait ou il veut aller.
[^] # Re: Quid de la diversité et des serveurs ?
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 2.
Tu peux développer ? Qu'est ce qui te semble une régression pour un usage serveur ?
[^] # Re: Ça fait peur
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 6.
Si OpenBSD à très bonne réputation. Je ne jugerais pas d'OpenSSH vu que je n'ai jamais lu ce code en particulier (les on-dit et les généralités...).
Pour arriver à ses objectifs fonctionnels il a besoin d'utiliser des fonctionnalités qui n'existent pas (encore ?) sur d'autres systèmes. Soit il renonce à tout ou une partie de ce qu'il veut faire, soit il le fait en n'étant compatible qu'avec les systèmes offrant les mêmes fonctionnalités.
Je me suis retrouvé dans le même cas que lui il y a quelques mois. Je ne pouvais pas assurer une fonctionnalité sans les cgroups. Et bien elle est linux only et n'existe que si tu as les cgroups activés. Y'a pas de miracle. Si tu m'offres quelque chose d'équivalent sous un autre système, la fonctionnalité existera sur ce système. Je préfère être portable. Mais tu ne peux pas tout faire avec l'API POSIX... Triste réalité.
Quelles sont les propositions concrètes pour permettre de supporter plus de systèmes ? Qu'est ce qui aurait pu être mieux fait ? À quel prix (fonctionnalités/performances/maintenabilité) ? C'est facile de critiquer en restant vague. Les faits m'intéressent.
[^] # Re: Ça fait peur
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 8.
N'importe quoi. L'un n'empêche pas l'autre.
C'est un peu comme dire que SIGKILL ne sert a rien. Il suffit de supposer que tout les processus se comportent comme attendu et n'ont jamais de bug.
Le job d'un init c'est de démarrer et de terminer des processus. C'est une grande avancée si on passe de "Je fais confiance au démon pour ne pas faire de saloperies" à "Je suis capable d'identifier et de terminer tout ce qui appartient à un démon même si celui ci à eu un problème".
Avoir besoin de la coopération de code non identifié pour assurer un fonctionnement correct est forcément un constat d'échec et un signe de faiblesse. Ce qui n'empêche pas de faire en sorte que les démons se comportent correctement. Bref ce n'est pas cacher la misère, c'est résoudre un problème existant. Supposer que l'ensemble du code qu'un init peut lancer ne sera jamais soumis à un bug ou autre, je ne sais pas si c'est flippant, présomptueux ou naïf.
[^] # Re: Modestie...
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
T'es développeur ?
Non par ce que généralement quand on l'est, et ne dit pas ça et on comprend qu'à un moment il faut du feedback utilisateur. C'est pour ça qu'on fait des alpha, des beta et qu'à un moment il faut se lancer à releaser. Pour qu'un produit se stabilise et soit bon, il faut avoir des retours utilisateurs et observer ce que ça donne sur le terrain. C'est encore plus vrai quand tu bosses sur un truc qui doit gérer X composants hardware/Y configs différentes et que tu es dans l'impossibilité de tout tester exhaustivement. Ça n'a rien a voir avec de la flemme. Tu peux attendre 10 ans pour releaser, faudra essuyer les plâtres à un moment. Au mieux tu peux limiter les dégats si tu leurs offre un test bed à quelques centaines de milliers d'euros et la main d’œuvre qui va derrière pour se palucher les tests.
Si des gens ont packagé trop tôt ou mal c'est plutôt à eux qu'il faut jeter la pierre. Fedora c'est leur but d'effectuer ce travail. Ils intègrent des trucs fraichement sorti pour voir ce que ça donne et permettre de les valider/finaliser.
[^] # Re: Ça fait peur
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
On retombe sur le cas de OpenSSH. L'équipe d'OpenSSH code pour OpenBSD uniquement. L'équipe d'OpenSSH-portable s'occupe de faire le portage.
OpenSSH is developed by two teams. One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable (adding the "goop") to make it run on many operating systems
On retrouve un peu les arguments qu'il avance.
Il reste à trouver des volontaires pour se farcir un portage. Je ne vois pas pourquoi ça serait à lui de faire ce boulot si il n'a ni envie, ni d’intérêt à le faire. Après évidement, si il met volontairement des bâtons dans les roues c'est un autre problème. Mais pondre du code libre ça ne veut pas dire devoir supporter toutes les volontés de tout les utilisateurs du monde. Ça veut dire permettre à qui le veut de continuer/reprendre sans entrave ce qui existe.
[^] # Re: Ça fait peur
Posté par ckyl . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
Tu cites OpenSSH, mais justement OpenSSH se fout ouvertement de la portabilité. Ils codent pour OpenBSD uniquement (leur motivation est justifiée et légitime) et après une seconde équipe se frappe le boulot de portage.
La vraie question n'est pas d’être portable ou non mais que doit on faire en cas de non équivalence fonctionnelle entre les systèmes ?
Exemple, si BSD n'offre pas d'équivalent aux cgroup, il dommage de se passer de cette fonctionnalité qui est une énorme avancée. Ca comble une grosse lacune. On avance ou on attend qu'hypothétiquement tout les systèmes existant implémentent une fonctionnalité équivalente ?
On peut décider d'avancer en se disant, que les autres pourront continuer d'exister comme actuellement. On ne leur retire rien, on avance simplement. On peut aussi se dire que ça les boostera pour offrir les fonctionnalités manquantes et qu'après ça ne sera que du travail de portage bête et méchant.
On peut aussi décider que c'est plus grave de fragmenter (temporairement ?) l'écosystème que de stagner.
Chacun peut avoir son opinion (et elle peut être différente selon les logiciels) mais je pense qu'il sera dur pour quelqu'un de prouver que son opinion est la meilleure et que l'autre à tord.
[^] # Re: Comme Microsoft
Posté par ckyl . En réponse au journal DropBox : plus ça va... moins ça va. Évalué à 7.
Oui. Ça s'appelle respecter la loi et ça n'a rien de spécifique au cloud. Ce n'est pas spécifique aux USA; mais depuis le patriot act, si ça te pose un problème tu ferais mieux d'éviter que tes bits résident ou passent par les USA ou une entreprise américaine. Ils ont tendance à avoir un peu beaucoup libéralisé le self-service pour le renseignement là où d'autres pays font encore croire qu'il y a besoin d'un juge.
[^] # Re: Bitcoins!
Posté par ckyl . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 3. Dernière modification le 04 juillet 2011 à 21:09.
Comme partout. Si ça devient sérieux tu auras aussi à te soumettre aux réglementations.
Par ailleurs qu'est ce qui t'empêche d'ouvrir un dark pool actuellement ? Où une banque qui aurait des pratiques que tu juges correctes ?
Envoyer la monnaie d'un point à un autre c'est uniquement une des nombreux besoins. Les intermédiaires apparaîtrons sous une forme ou une autre car ils répondent tout de même à des besoins (sans juger de leurs pratiques). Deux exemples tout bêtes parmi des dizaines :
Si ça devient sérieux et que tu laisses s'écouler quelques dizaines/centaines d'années il n'y a pas de raison objective que le résultat soit bien différent.
[^] # Re: Bitcoins!
Posté par ckyl . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 4.
En quoi bitcoin empêche des intermédiaires de se sucrer ? Les places de marchés pour bitcoin prennent déjà une commission (faut bien les financer). Des intermédiaires équivalents à ceux actuels apparaitrons dans l’économie bitcoin. Et il n'y a aucun raison qu'ils se comportent différemment qu'actuellement. Ce n'est qu'une monnaie comme les autres (sans entrer dans le débat).
# Coût != Libre/Ouvert
Posté par ckyl . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 3.
Pourquoi un FTPS ne couterait rien ?
[^] # Re: mauvaise idée
Posté par ckyl . En réponse au journal CAPTCHA. Évalué à 5.
Ca nous fait une belle jambe d'avoir un problème qui n'est résoluble ni par un ordinateur ni par un humain... Autant désactiver les commentaires ou le sign up ;)
[^] # Re: clavier
Posté par ckyl . En réponse au journal C'est ça l'expérience utilisateur intuitive et ergonomique chez Gnome/Rhythmbox ?. Évalué à 4.
La touche Windows est associée à l'activities view dans gnome 3.
[^] # Re: Pertinence
Posté par ckyl . En réponse au journal Moteur de recherche orange. Évalué à 1.
FAUX.
Il répond parfaitement au mot clé le plus recherché: http://search.ke.voila.fr/S/voila?rtype=kw&bhv=web_fr&profil=voila&rdata=google
[^] # Re: Rapport de bug ?
Posté par ckyl . En réponse au journal C'est ça l'expérience utilisateur intuitive et ergonomique chez Gnome/Rhythmbox ?. Évalué à -4.
Ils permettent à ceux qui veulent d'attribuer et d'utiliser des raccourcis clavier. Et de le faire très facilement pour n'importe quelle action. Ceux que ça intéresse peuvent le faire. Il y aura toujours des réglages qui plairont aux uns ou aux autres; et il y aura toujours des gens pour gueuler à tord ou à raison.
Moi ce qui me navre c'est le dénigrement perpétuel de ceux qui se bougent le cul et qui proposent quelque chose par ceux qui ne font rien. En utilisant toujours l'hypothétique "madame michu" pour se justifier. Si ça te plait pas utilise pas; pas la peine d'essayer de montrer a quel point tu es moins con qu'eux. D'ailleurs ils font tellement de la merde que tu utilises leur produit, tu dois être masochiste...
[^] # Re: Rapport de bug ?
Posté par ckyl . En réponse au journal C'est ça l'expérience utilisateur intuitive et ergonomique chez Gnome/Rhythmbox ?. Évalué à -9.
Autrement au lieu de gémir pendant 704 caractères:
1- Sélectionner un fichier de ta play queue
2- Sélectionner menu edit>remove from playlist
3- Appuyer sur delete ou n'importe quelle touche de ton choix
4- Enjoy !
Gnome c'est tellement pourri et pas configurable que ça ma pris 20 secondes pour trouver cette solution. Change vite de bureau.
[^] # Re: ???
Posté par ckyl . En réponse au journal Un horodateur cryptographique en bash. Évalué à 3.
Oui enfin ça il faudrait encore le prouver, ce qui demande de commencer par être capable d'expliquer ton aglo et de définir ses propriétés.
Autrement y'a deux ou trois trucs qui ont déjà été prouvés concernant les systèmes distribués asynchrones dans le domaine des horloges logiques, du (partial|total)-order et des pannes byzantines ces 40 dernières années.
[^] # Re: troll
Posté par ckyl . En réponse au journal De la livraison simultanée d'évolutions et de correctifs.... Évalué à 2.
Peut être que la release ne se fait pas du jour au lendemain et qu'il existe de RC pour pouvoir valider avant et être prêt avant le jour J ? Pourquoi tu ne gueules pas sur google ?
Peut être aussi que rien ne t'oblige a mettre à jour. Puisque c'est un outil de dev, tu utilises une install dédiée pour le développement et voilà. Ça prend pas 10 jours...
Je suis sur que si vous êtes nombreux, un prestataire se fera la joie de vous offrir ce service.