Pour avoir été des deux côtés (montage de grands marchés de support open source, et sous-traitance à travers des intermédiaires dans le milieu familial proche), le CNLL ne comprend pas ses clients potentiels.
La raison principale pour laquelle un grand groupe ou une administration passe un GMOS est de s'affranchir de ses propres complexités organisationnelles. Donc, l’effet massification et interlocuteur unique est un objectif prioritaire. Quand on connait l'enfer organisationnel pour arriver à des décisions dans une grosse structure, imaginer qu’elle va multiplier les micro marchés (qui demandent chacun une décision) est totalement illusoire. (C'est d'ailleurs, autant vrai côté logiciel propriétaire ou même sur des marchés hors du monde logiciel).
Donc, tant que les éditeurs du CNLL avanceront en ordre dispersé, ils se feront plumer par les intermédiaires. Et c’est normal, parce que ces intermédiaires rendent un vrai service aux clients finaux (massifier), que les petits éditeurs sont incapables de remplir.
Si ces éditeurs veulent une part plus importante de ces marchés, ils doivent s'organiser en gros groupements ou coopératives. C’est tout.
Le jour où les grosses structures seront capables de gérer une bourse aux micros appels d'offre, faut pas espérer que l’argent dégagé ira côté petits éditeurs. La grosse structure ayant éliminé son besoin de massification, elle dépensera son budget sur autre chose.
Après que le GMOS oblige à reverser, bien sûr. Après un GMOS peut autant reverser à Debian ou Centos, qui rendent un vrai service d'industrialisation au client final, qu’au petit éditeur ou développeur, qui aura publié quelque chose qui demande un gros travail d'intégration pour être utilisé en production.
L’argent suit la chaîne de valeur. La chaîne de valeur, vue du client final, est souvent bien différente de celle du développeur sur GitHub. Capter plus d’argent des grands comptes, demande d’assurer une part plus importante de cette chaîne de valeur.
De base:
– laser (ne sèche pas)
— recto verso
– multifonction
— 100% compatible (PPD lisible par cups, envoie les numérisations par courriel, configuration par appli web sans plugin)
— chargeur automatique recto-verso
— 30 pages/min
– couleur (mais laser)
– réseau (rj45, wifi en option)
— cartouches noir + couleur incluses données pour 4000 pages (la vraie cartouche noire fait plus, livré avec une demi-cartouche)
Après
– Lexmark n’est pas mon fabriquant préféré côté solidité,
– c’est plus gros qu'une multifonction jet d’encre
– une photo ou une page avec beaucoup de graphiques couleur sortira certainement mieux avec une jet d’encre si cartouches neuves (mais inversement le texte noir est beaucoup mieux)
– l’ergonomie du panneau de contrôle est nulle (dans la moyenne des constructeurs)
Mais à ce prix là, il n’y a pas photo niveau prix et absence de soucis.
Étant l'auteur de fr-oss (qui hérite des principes de fr-latin9) je peux te dire qu'il y a de tout dedans : des éléments extrêmement bien pensés, des horreurs imposées par la volonté de rester compatible avec l'existant, des bouts que j'ai ajoutés parce qu'il restait de la place et que c'était dommage de gaspiller.
Par exemple un des principes de fr-oss est de respecter la sérigraphie des claviers Azerty existants pour éviter les rejets des utilisateurs occasionnels. Donc on se retrouve avec des horreurs comme le ² qui ne sert à rien en pratique (mais utilisés par la console de pas mal de jeux et c'est pas moi qui allait les faire évoluer), le @ pas pratique, éèçà idem.
Je vois que l'Afnor a déplacé les guillemets, c'est dommage fr-oss reproduisait délibérément le placement des claviers Canadiens.
Et des éléments mis au cas où à l'origine comme les flèches se sont révélées extrêmement pratiques pour tous les usages télégraphiques (courriels, messagerie instantanée, présentations…).
Donc il est loin d'être choquant que l'Afnor s'en éloigne, elle a les moyens de faire beaucoup mieux. Par contre la disposition proposée me laisse dubitatif. Je suppose qu'il va falloir que je commente.
Base était un des modules de LibreOffice que SUN avait le plus java-isé. Les volontaires ne se bousculent donc pas au portillon (SUN a été très efficace pour creuser le fossé entre le monde Java et le logiciel libre classique)
Le corps en sérif + les titres en sans sérif est une convention typographique américaine (d'avant l'informatisation des publications).
Ça choque beaucoup en Europe il est vrai.
C'est le genre de défaut insipide choisi par un informaticien comme bouche trou en attendant que quelqu'un dont c'est le métier corrige.
Malheureusement il y a peu de graphistes pro dans le développement libre, et ce type d'applicatif a tellement de valeurs par défaut (souvent en dur, essayez de changer la police par défaut dans les styles) qu'il est difficile de les modifier à postériori.
La gestion des palettes d'OpenOffice/LibreOffice a toujours été supérieure à celle de Microsoft Office.
On peut depuis toujours ajouter des couleurs personnalisées à la palette, sans retaper les codes RGB tous les deux jours parce que l'applicatif l'a oublié (MSO). Avec les versions récentes LO peut même lire les formats de palettes graphiques tiers, on peut donc partager la même palette avec d'autres outils de la chaîne de publication (OO.o avait le fétichisme de ses propres formats, et refusait de s'intégrer avec autre chose).
Ce qui permet d'importer les couleurs officielles définies par les communicants de la boîte dans tous les documents.
Après il est vrai que MSO a compensé la nullité profonde de sa gestion des couleurs par de bons défauts. Le monde du logiciel libre a encore du travail à faire pour attirer de bons graphistes/designers dans un rôle de contributeur (inkscape & co ont résolu la partie utilisateur ces dernières années).
Ce n'est même pas du vrai maildir, après 12 ans à nier les problèmes de mbox, les devs de mozilla ont décidé d'implémenter un nouveau format incomplet et inutilisable dans beaucoup de cas https://bugzilla.mozilla.org/show_bug.cgi?id=58308#c190
Ils n'ont toujours pas compris qu'ils n'étaient pas les seuls à faire du mail et qu'il était utile de capitaliser sur les retours d'expérience des autres applications de messagerie.
Et après ils se demandent pourquoi thundermail a une part de marché ridicule… Si Firefox a décollé c'est qu'il ne mégotait pas sur les standards web comme thunderbird mégote sur les standards de messagerie.
Oracle n'aime pas les relations commerciales équilibrées, donc leurs conditions de vente officielles sont exorbitantes, les conditions réelles moins mais au moindre conflit ils te ressortent les tarifs publics.
Comment se faire avoir par Oracle (non exhaustif) :
— accepter une belle ristourne pour les laisser entrer chez soi (sans budgéter sa baisse une fois qu'Oracle pourra prendre la base installée en otage)
— baser sa stratégie d'achat matériel sur les coefficients CPU les plus favorables dans l'offre Oracle (les coefficients valsent d'années en année en fonction des partenaires qui ont le plus offensé Ellison ; il y a des variantes : en ce moment Oracle ne tourne soit-disant pas sous RHEL6 ou VMWare)
— installer sans compter en espérant une reconduction tacite de l'accord commercial du moment (Oracle adore exiger un audit de la base installée pendant les renégo, en menaçant de faire payer toutes les installations en plus au tarif public)
— négocier un tarif imbattable sur un produit Oracle particulier (si Oracle a accepté des conditions trop favorables à trop de monde sur un produit pour le lancer, dans le catalogue suivant il n'existera plus et il y aura autre chose avec les mêmes fonctionnalités, l'essentiel du même code, et un tarif différent)
Pour que le mode sécurisé UEFI serve à quelque chose il faut que ce qu'il autorise à démarrer ne puisse pas lui-même attaquer le système. Donc il ne peut servir qu'à limiter les bootloaders autorisés, mais les seuls qui seront autorisés sont ceux qui contrôlent l'OS et les applis qu'il y a derrière. C'est du verrouillage récursif
Si tu trouves freedesktop orienté GNU tu seras plus heureux avec openoffice puisque les autres autres bouts de code qu'utilise libreoffice et qui sont hébergés sur freedesktop sont précisément ceux qu'IBM est en train de faire amputer
De ce point de vue là l'utilisation du bugzilla de freedesktop est entièrement cohérente avec les orientations de Libreoffice.
À mon avis :
1. Ça ne sert à rien de monter une nouvelle infra quand il y en a une rodée prête à t'accueillir
2. Comme ça les bogues peuvent être réaffectés simplement à tous les autres composants (comme fontconfig, gstreamer, etc) qui sont déjà présent sur le bugzilla de freedesktop
Maintenant qu'il y a une équipe de développement motivée (au lieu de faire l'autruche de peur de déstabiliser l'existant) as-tu signalé ces problèmes dans le bugzilla de freedesktop?
Bien sûr tout ne va pas être corrigé tout de suite, mais au moins maintenant le projet affiche clairement son souhait de ne plus s'assoir dessus.
Dixit l'annonce :
“bugs were not solved in order to avoid creating problems, and this – with time – was the origin of a large technical debt,” says Caolán McNamara
Faut pas confondre le copier coller du cahier des charges de grand-maman avec la réalité du terrain. Ce pour quoi tu aurais dû développer, on te le dira à la sortie de ton logiciel. Relis ton Dilbert, il est très réaliste sur le fonctionnement des grosses boites.
avec POP/SMTP désactivé sur les serveurs pour éviter les petits
malins qui essaieraient d'utiliser un autre client mail
Nan, c'est parce que Domino c'est du x 500 propriétaire repeint en infrastructure mail "standard", les protocoles de tout le monde ont été ajoutés après coup, et IBM veut pas s'engager sur la tenue en charge de ces protocoles sur de grosses infras (après réalité technique ou enfumage des commerciaux, qui va parier son poste dessus)
Le webmail à la sauce Domino, c'est aussi très drôle, il y a tellement de js spaghetti partout qu'ils est plus lourd que le client lourd de base (celui l'avant la refonte sous Eclipse, qui a consisté a rajouter une tartine de java sur l'existant sans résorber celui-ci)
Mais bon tant que tu as échappé à Lotus QuickR tu ne peux pas savoir tout le bien qu'IBM te veut
J'ai jamais dit que le photovoltaique avait un label Bio-bobo
Nicolas Hulot ^^
Simplement, je prefere ça, à des trains complet d'Uranium appauvri
qui traverse la sibérie, à des rejets permanents de Krypton
radioactif made in la Hague, à des rejets permanents de
radioactivité dans l'Océan atlantique, à des enfouissements de
déchets pour plus de 200.000 ans dans en fûts en bétons à 50km de
mon lieu de Naissance, à des zones complètements inhabitable parce
que l'impossible s'est produit, à des pauvres bougres qui bouffent
leur dose annuel de µSievert en 15 min parce qu'il faut bien que
quelqu'un aille "En Zone" réparer brillamment nos centrales si
"sures et propres", etc....
Et ces pauvres bougres, comme tu dis, ils sont vivants aujourd'hui et le seront pour des dizaines d'années. Ce qui n'est pas le cas des 'recycleurs' de circuits.
C'est bien joli de sortir des durées avec beaucoup de zéros pour effrayer la populace, mais les nappes que tu viens de passer par pertes et profits, elles ont mis quelques âges géologiques à se constituer (donc on parle en millions pas en milliers d'années). Et les métaux lourds, s'ils n'ont pas de demi-vie, ce n'est pas parce qu'ils sont plus inoffensifs, c'est parce qu'ils restent un poison pour l'éternité (je rappelle qu'aujourd'hui la méthode la plus efficace pour nettoyer des métaux lourds consiste à empoisonner le maximum de plantes avec et récolter le résultat avant qu'il ne fuite plus loin dans la pyramide alimentaire).
Après on peut délivrer un certificat de mort conventionnelle aux familles de tous ces gens, mais je doute qu'elles apprécient ta focalisation sur le nucléaire au détriment de tout le reste.
PS Le pire désastre écologique de l'Union Soviétique, qui ne s'embarrassait pas de sentiments, ce n'est pas Tchernobyl mais l'empoisonnement de la mer d'Aral et de tous les territoires avoisinants aux engrais on ne peut plus conventionnels. À Tchernobyl, il y a encore des arbres et des animaux.
C'est vrai, Le silicium c'est connu pour être au moins aussi
polluant que le plutonium.
Le silicium d'un circuit n'est que le substrat. Le circuit lui-même est réalisé en enrichissant le silicium avec des composés exotiques et des métaux lourds (Il y a toute une industrie du "recyclage" des circuits dans quelques pays du tiers monde où des crève-la-faim rachètent des circuits au kilo et les fondent dans leur petits fourneaux en espérant ramasser une pépite comme au Klondike. Le taux de mortalité dû aux vapeurs toxiques est dans les mêmes ordres de grandeur http://www.time.com/time/photogallery/0,29307,1870162,00.html).
Mais même en faisant abstraction de cette partie (et des résines et autres laques utilisées pour protéger le résultat) un circuit est réalisé avec du silicium pur. Pour obtenir du silicium pur à partir du sable de plage que les fabricants de photovoltaïque aiment faire miroiter aux naïfs dans ton genre, il faut traiter avec des cochonneries bien violentes (acides forts, etc). Et consommer beaucoup d'eau douce, la plus pure possible (parce qu'on purifie pas le silicium pour remettre des saletés dedans). L'idéal étant de pomper directement dans une bonne vieille nappe phréatique fossile, et tant pis pour les autres utilisateurs (bon, on veut bien partager les nappes avec les fabricants de soda).
Tout ça pour dire qu'un circuit, photovoltaïque ou non, c'est très loin d'être propre. Et proposer d'en faire des kilomètres carrés au nom de la planète c'est une absurdité complète.
Si tu avais aussi des restes de géographie (c'est vrai, d'un niveau plus élevé que le CM2) tu saurais que les Suisses sont assis sur le plus grand château d'eau d'Europe, et les Allemands sur de grands gisements de charbon. Donc les enjeux ne sont pas les mêmes pour eux.
La manière dont Red Hat a choisi yum est bien documentée : ils ont pris tous les apt-like pour rpm de l'époque, fait un audit de code, et pris celui qui avait un code propre et extensible (et embauché son auteur). yum a gagné car :
1. il était codé proprement (pas encore optimisé, mais bien structuré). On peut optimiser du bon code, c'est très difficile de maintenir du code rapide mais bordélique
2. il utilisait le moteur de résolution de dépendances de rpm au lieu d'utiliser un algo différent lors de la résolution réseau, et espérer que rpm soit d'accord à l'installation (apt-rpm). Cela a permis :
a. de reprendre l'existant rpm sans rupture (simple bon sens pour Red Hat qui était n°1 sur son marché
b. d'écrire des règles de packaging rigoureuses, claires et détaillées, puisqu'il n'y a aucune ambiguïté sur le moteur de règles à respecter (tout passe par librpm et que par librpm), ce qui a permis d'assainir et améliorer la qualité de la distribution en général
3. il était intégrable simplement dans les autres outils Red Hat (Anaconda est en python, comme son nom l'indique). C'est complètement invisible pour les utilisateurs, mais aujourd'hui tous les outils Fedora/Red Hat (Anaconda, PackageKit, la ferme de compilation, Spacewalk, Satellite, Cobbler j'en passe et des meilleures) font appel à l'infrastructure yum et ça marche très bien.
Yum est un choix qui s'est révélé plus que judicieux avec le temps. Red Hat n'avait pas besoin d'un client d'installation type apt-rpm (ils avaient déjà leur propre bouse, up2date qui a heureusement été abandonnée) mais d'une vraie brique d'infrastructure avec laquelle ils pourraient construire d'autres applications. Le yum vu par l'utilisateur est juste un frontal shell, c'est une toute petite partie de ce que yum fait pour Fedora.
D'ailleurs Suse/Novell (qui avait aussi besoin de construire des infras autour de rpm) a écarté comme Red Hat tous les clients apt-like de l'époque, et a fini par écrire le sien de zéro. C'est ce qui leur a permis ensuite de construire https://build.opensuse.org/
Yum est juste un gestionnaire de paquets, il faut passer par anaconda pour toutes les opérations qui nécessitent un traitement spécifique (un exemple simple a été la migration ext3 → ext4, par exemple. Trop dangereux de changer le système de fichier sous les pieds de l'OS en train de tourner)
# Le CNLL ne comprend pas ses clients
Posté par nimnim . En réponse à la dépêche Revue de presse de l’April pour la semaine 48 de l’année 2019. Évalué à 4.
Pour avoir été des deux côtés (montage de grands marchés de support open source, et sous-traitance à travers des intermédiaires dans le milieu familial proche), le CNLL ne comprend pas ses clients potentiels.
La raison principale pour laquelle un grand groupe ou une administration passe un GMOS est de s'affranchir de ses propres complexités organisationnelles. Donc, l’effet massification et interlocuteur unique est un objectif prioritaire. Quand on connait l'enfer organisationnel pour arriver à des décisions dans une grosse structure, imaginer qu’elle va multiplier les micro marchés (qui demandent chacun une décision) est totalement illusoire. (C'est d'ailleurs, autant vrai côté logiciel propriétaire ou même sur des marchés hors du monde logiciel).
Donc, tant que les éditeurs du CNLL avanceront en ordre dispersé, ils se feront plumer par les intermédiaires. Et c’est normal, parce que ces intermédiaires rendent un vrai service aux clients finaux (massifier), que les petits éditeurs sont incapables de remplir.
Si ces éditeurs veulent une part plus importante de ces marchés, ils doivent s'organiser en gros groupements ou coopératives. C’est tout.
Le jour où les grosses structures seront capables de gérer une bourse aux micros appels d'offre, faut pas espérer que l’argent dégagé ira côté petits éditeurs. La grosse structure ayant éliminé son besoin de massification, elle dépensera son budget sur autre chose.
Après que le GMOS oblige à reverser, bien sûr. Après un GMOS peut autant reverser à Debian ou Centos, qui rendent un vrai service d'industrialisation au client final, qu’au petit éditeur ou développeur, qui aura publié quelque chose qui demande un gros travail d'intégration pour être utilisé en production.
L’argent suit la chaîne de valeur. La chaîne de valeur, vue du client final, est souvent bien différente de celle du développeur sur GitHub. Capter plus d’argent des grands comptes, demande d’assurer une part plus importante de cette chaîne de valeur.
[^] # Re: Et les imprimantes laser ?
Posté par nimnim . En réponse à la dépêche Du rififi dans ta cartouche d’encre. Évalué à 0. Dernière modification le 04 avril 2018 à 13:32.
Doublon
[^] # Re: Et les imprimantes laser ?
Posté par nimnim . En réponse à la dépêche Du rififi dans ta cartouche d’encre. Évalué à 2.
Par ailleurs, Lexmark fait régulièrement des ventes privées (sur les sites spécialisés), où on peut acheter pour 200 € (220 avec la livraison) des choses comme ceci:
https://www.lexmark.com/FR/fr/catalog/product.jsp?catId=cat290005&prodId=FR7777
De base:
– laser (ne sèche pas)
— recto verso
– multifonction
— 100% compatible (PPD lisible par cups, envoie les numérisations par courriel, configuration par appli web sans plugin)
— chargeur automatique recto-verso
— 30 pages/min
– couleur (mais laser)
– réseau (rj45, wifi en option)
— cartouches noir + couleur incluses données pour 4000 pages (la vraie cartouche noire fait plus, livré avec une demi-cartouche)
Après
– Lexmark n’est pas mon fabriquant préféré côté solidité,
– c’est plus gros qu'une multifonction jet d’encre
– une photo ou une page avec beaucoup de graphiques couleur sortira certainement mieux avec une jet d’encre si cartouches neuves (mais inversement le texte noir est beaucoup mieux)
– l’ergonomie du panneau de contrôle est nulle (dans la moyenne des constructeurs)
Mais à ce prix là, il n’y a pas photo niveau prix et absence de soucis.
[^] # Re: fr-oss
Posté par nimnim . En réponse à la dépêche Vers une norme AFNOR pour le clavier français. Évalué à 5.
Bonjour,
Étant l'auteur de fr-oss (qui hérite des principes de fr-latin9) je peux te dire qu'il y a de tout dedans : des éléments extrêmement bien pensés, des horreurs imposées par la volonté de rester compatible avec l'existant, des bouts que j'ai ajoutés parce qu'il restait de la place et que c'était dommage de gaspiller.
À un moment j'ai arrêté de faire évoluer parce que c'était assez bien comme ça©, les utilisateurs en avaient marre que ça change tout le temps, et franchement travailler une disposition dans xkb-config c'est très chiant®.
Par exemple un des principes de fr-oss est de respecter la sérigraphie des claviers Azerty existants pour éviter les rejets des utilisateurs occasionnels. Donc on se retrouve avec des horreurs comme le ² qui ne sert à rien en pratique (mais utilisés par la console de pas mal de jeux et c'est pas moi qui allait les faire évoluer), le @ pas pratique, éèçà idem.
Je vois que l'Afnor a déplacé les guillemets, c'est dommage fr-oss reproduisait délibérément le placement des claviers Canadiens.
Et des éléments mis au cas où à l'origine comme les flèches se sont révélées extrêmement pratiques pour tous les usages télégraphiques (courriels, messagerie instantanée, présentations…).
Donc il est loin d'être choquant que l'Afnor s'en éloigne, elle a les moyens de faire beaucoup mieux. Par contre la disposition proposée me laisse dubitatif. Je suppose qu'il va falloir que je commente.
# Lion de den ?
Posté par nimnim . En réponse à la dépêche Parution de 0 A.D. alpha 20 Timosthenes. Évalué à 4.
Lion's den → Tanière du Lion, pas Lion de den
[^] # Re: Pb de LibreOffice
Posté par nimnim . En réponse à la dépêche LibreOffice 5.0 : sous le capot. Évalué à 5.
Base était un des modules de LibreOffice que SUN avait le plus java-isé. Les volontaires ne se bousculent donc pas au portillon (SUN a été très efficace pour creuser le fossé entre le monde Java et le logiciel libre classique)
LibreOffice a quand même investi pour proposer l'option Firebird en plus de HSQLDB dans base, mais il reste du travail.
https://wiki.documentfoundation.org/ReleaseNotes/4.2/fr#Fonctionnalit.C3.A9s_exp.C3.A9rimentales
[^] # Re: Crashs tests
Posté par nimnim . En réponse à la dépêche LibreOffice 5.0 : sous le capot. Évalué à 3.
Tous les documents attachés à un bogue dans le bugzilla LO sont ensuite réutilisés dans ces tests (de mémoire).
[^] # Re: Styles et formatage
Posté par nimnim . En réponse à la dépêche LibreOffice 5.0 : sous le capot. Évalué à 4.
Le corps en sérif + les titres en sans sérif est une convention typographique américaine (d'avant l'informatisation des publications).
Ça choque beaucoup en Europe il est vrai.
C'est le genre de défaut insipide choisi par un informaticien comme bouche trou en attendant que quelqu'un dont c'est le métier corrige.
Malheureusement il y a peu de graphistes pro dans le développement libre, et ce type d'applicatif a tellement de valeurs par défaut (souvent en dur, essayez de changer la police par défaut dans les styles) qu'il est difficile de les modifier à postériori.
[^] # Re: Xamarin et LibreOffice ?
Posté par nimnim . En réponse à la dépêche LibreOffice 5.0 : sous le capot. Évalué à 5.
La gestion des palettes d'OpenOffice/LibreOffice a toujours été supérieure à celle de Microsoft Office.
On peut depuis toujours ajouter des couleurs personnalisées à la palette, sans retaper les codes RGB tous les deux jours parce que l'applicatif l'a oublié (MSO). Avec les versions récentes LO peut même lire les formats de palettes graphiques tiers, on peut donc partager la même palette avec d'autres outils de la chaîne de publication (OO.o avait le fétichisme de ses propres formats, et refusait de s'intégrer avec autre chose).
Ce qui permet d'importer les couleurs officielles définies par les communicants de la boîte dans tous les documents.
Après il est vrai que MSO a compensé la nullité profonde de sa gestion des couleurs par de bons défauts. Le monde du logiciel libre a encore du travail à faire pour attirer de bons graphistes/designers dans un rôle de contributeur (inkscape & co ont résolu la partie utilisateur ces dernières années).
# Prise en compte de la norme HTML5 : l'attribut CSS @page est pris en charge
Posté par nimnim . En réponse à la dépêche Firefox et Firefox mobile en version 19. Évalué à 3.
Par quel miracle de la com la correction d'un bogue de 2001 devient une “Prise en compte de la norme HTML5” ?
https://bugzilla.mozilla.org/show_bug.cgi?id=115199
Pour @page-break (demandé en 2002) if faudra attendre HTML6 ?
https://bugzilla.mozilla.org/show_bug.cgi?id=132035
[^] # Re: L'avenir est dans le passéisme
Posté par nimnim . En réponse à la dépêche Firefox 12 et Thunderbird 12 sont sortis ; Mobile est mis à jour. Évalué à 10.
Ce n'est même pas du vrai maildir, après 12 ans à nier les problèmes de mbox, les devs de mozilla ont décidé d'implémenter un nouveau format incomplet et inutilisable dans beaucoup de cas
https://bugzilla.mozilla.org/show_bug.cgi?id=58308#c190
Ils n'ont toujours pas compris qu'ils n'étaient pas les seuls à faire du mail et qu'il était utile de capitaliser sur les retours d'expérience des autres applications de messagerie.
Et après ils se demandent pourquoi thundermail a une part de marché ridicule… Si Firefox a décollé c'est qu'il ne mégotait pas sur les standards web comme thunderbird mégote sur les standards de messagerie.
[^] # Re: question bête
Posté par nimnim . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 10.
Oracle n'aime pas les relations commerciales équilibrées, donc leurs conditions de vente officielles sont exorbitantes, les conditions réelles moins mais au moindre conflit ils te ressortent les tarifs publics.
Comment se faire avoir par Oracle (non exhaustif) :
— accepter une belle ristourne pour les laisser entrer chez soi (sans budgéter sa baisse une fois qu'Oracle pourra prendre la base installée en otage)
— baser sa stratégie d'achat matériel sur les coefficients CPU les plus favorables dans l'offre Oracle (les coefficients valsent d'années en année en fonction des partenaires qui ont le plus offensé Ellison ; il y a des variantes : en ce moment Oracle ne tourne soit-disant pas sous RHEL6 ou VMWare)
— installer sans compter en espérant une reconduction tacite de l'accord commercial du moment (Oracle adore exiger un audit de la base installée pendant les renégo, en menaçant de faire payer toutes les installations en plus au tarif public)
— négocier un tarif imbattable sur un produit Oracle particulier (si Oracle a accepté des conditions trop favorables à trop de monde sur un produit pour le lancer, dans le catalogue suivant il n'existera plus et il y aura autre chose avec les mêmes fonctionnalités, l'essentiel du même code, et un tarif différent)
[^] # Re: Mariiane 2 - Alerte Généralisée
Posté par nimnim . En réponse à la dépêche Revue de presse de l'April pour la semaine 7 de l'année 2012. Évalué à 0.
Pour que le mode sécurisé UEFI serve à quelque chose il faut que ce qu'il autorise à démarrer ne puisse pas lui-même attaquer le système. Donc il ne peut servir qu'à limiter les bootloaders autorisés, mais les seuls qui seront autorisés sont ceux qui contrôlent l'OS et les applis qu'il y a derrière. C'est du verrouillage récursif
[^] # Re: mouhais
Posté par nimnim . En réponse à la dépêche LibreOffice 3.5 est disponible. Évalué à 2.
Si tu trouves freedesktop orienté GNU tu seras plus heureux avec openoffice puisque les autres autres bouts de code qu'utilise libreoffice et qui sont hébergés sur freedesktop sont précisément ceux qu'IBM est en train de faire amputer
De ce point de vue là l'utilisation du bugzilla de freedesktop est entièrement cohérente avec les orientations de Libreoffice.
[^] # Re: mouhais
Posté par nimnim . En réponse à la dépêche LibreOffice 3.5 est disponible. Évalué à 2.
À mon avis :
1. Ça ne sert à rien de monter une nouvelle infra quand il y en a une rodée prête à t'accueillir
2. Comme ça les bogues peuvent être réaffectés simplement à tous les autres composants (comme fontconfig, gstreamer, etc) qui sont déjà présent sur le bugzilla de freedesktop
[^] # Re: mouhais
Posté par nimnim . En réponse à la dépêche LibreOffice 3.5 est disponible. Évalué à 3.
Maintenant qu'il y a une équipe de développement motivée (au lieu de faire l'autruche de peur de déstabiliser l'existant) as-tu signalé ces problèmes dans le bugzilla de freedesktop?
Bien sûr tout ne va pas être corrigé tout de suite, mais au moins maintenant le projet affiche clairement son souhait de ne plus s'assoir dessus.
Dixit l'annonce :
“bugs were not solved in order to avoid creating problems, and this – with time – was the origin of a large technical debt,” says Caolán McNamara
[^] # Re: Politique du SI
Posté par nimnim . En réponse à la dépêche Stratégie Open-source à EDF R&D. Évalué à 7.
Faut pas confondre le copier coller du cahier des charges de grand-maman avec la réalité du terrain. Ce pour quoi tu aurais dû développer, on te le dira à la sortie de ton logiciel. Relis ton Dilbert, il est très réaliste sur le fonctionnement des grosses boites.
[^] # Re: 100% ok avec xnx
Posté par nimnim . En réponse à la dépêche Stratégie Open-source à EDF R&D. Évalué à 8.
Nan, c'est parce que Domino c'est du x 500 propriétaire repeint en infrastructure mail "standard", les protocoles de tout le monde ont été ajoutés après coup, et IBM veut pas s'engager sur la tenue en charge de ces protocoles sur de grosses infras (après réalité technique ou enfumage des commerciaux, qui va parier son poste dessus)
Le webmail à la sauce Domino, c'est aussi très drôle, il y a tellement de js spaghetti partout qu'ils est plus lourd que le client lourd de base (celui l'avant la refonte sous Eclipse, qui a consisté a rajouter une tartine de java sur l'existant sans résorber celui-ci)
Mais bon tant que tu as échappé à Lotus QuickR tu ne peux pas savoir tout le bien qu'IBM te veut
[^] # Re: Le nuclaire, une solution ?????
Posté par nimnim . En réponse au sondage Quelle énergie pour demain ?. Évalué à 2.
C'est pas difficile à trouver, même en France, bien que les industriels soient le plus discrets possibles sur le sujet
http://www.liberation.fr/societe/0109235578-quand-ibm-se-branche-sur-l-eau-du-neocomien-cette-nappe-d-eau-tres-pure-devait-officiellement-etre-preservee
http://www.onearth.org/article/drinking-the-desert-dry
http://www.timesunion.com/business/article/Second-fab-water-line-likely-to-be-late-1419425.php
[^] # Re: Le nuclaire, une solution ?????
Posté par nimnim . En réponse au sondage Quelle énergie pour demain ?. Évalué à 2.
Et ces pauvres bougres, comme tu dis, ils sont vivants aujourd'hui et le seront pour des dizaines d'années. Ce qui n'est pas le cas des 'recycleurs' de circuits.
C'est bien joli de sortir des durées avec beaucoup de zéros pour effrayer la populace, mais les nappes que tu viens de passer par pertes et profits, elles ont mis quelques âges géologiques à se constituer (donc on parle en millions pas en milliers d'années). Et les métaux lourds, s'ils n'ont pas de demi-vie, ce n'est pas parce qu'ils sont plus inoffensifs, c'est parce qu'ils restent un poison pour l'éternité (je rappelle qu'aujourd'hui la méthode la plus efficace pour nettoyer des métaux lourds consiste à empoisonner le maximum de plantes avec et récolter le résultat avant qu'il ne fuite plus loin dans la pyramide alimentaire).
Après on peut délivrer un certificat de mort conventionnelle aux familles de tous ces gens, mais je doute qu'elles apprécient ta focalisation sur le nucléaire au détriment de tout le reste.
PS Le pire désastre écologique de l'Union Soviétique, qui ne s'embarrassait pas de sentiments, ce n'est pas Tchernobyl mais l'empoisonnement de la mer d'Aral et de tous les territoires avoisinants aux engrais on ne peut plus conventionnels. À Tchernobyl, il y a encore des arbres et des animaux.
[^] # Re: Le nuclaire, une solution ?????
Posté par nimnim . En réponse au sondage Quelle énergie pour demain ?. Évalué à 0.
(et ce n'est pas le seul cas)
http://ngm.nationalgeographic.com/2008/01/high-tech-trash/carroll-text/1
http://bop.nppa.org/2010/still_photography/winners/?cat=OES&place=2nd&item=201463
[^] # Re: Le nuclaire, une solution ?????
Posté par nimnim . En réponse au sondage Quelle énergie pour demain ?. Évalué à 2.
Le silicium d'un circuit n'est que le substrat. Le circuit lui-même est réalisé en enrichissant le silicium avec des composés exotiques et des métaux lourds (Il y a toute une industrie du "recyclage" des circuits dans quelques pays du tiers monde où des crève-la-faim rachètent des circuits au kilo et les fondent dans leur petits fourneaux en espérant ramasser une pépite comme au Klondike. Le taux de mortalité dû aux vapeurs toxiques est dans les mêmes ordres de grandeur http://www.time.com/time/photogallery/0,29307,1870162,00.html).
Mais même en faisant abstraction de cette partie (et des résines et autres laques utilisées pour protéger le résultat) un circuit est réalisé avec du silicium pur. Pour obtenir du silicium pur à partir du sable de plage que les fabricants de photovoltaïque aiment faire miroiter aux naïfs dans ton genre, il faut traiter avec des cochonneries bien violentes (acides forts, etc). Et consommer beaucoup d'eau douce, la plus pure possible (parce qu'on purifie pas le silicium pour remettre des saletés dedans). L'idéal étant de pomper directement dans une bonne vieille nappe phréatique fossile, et tant pis pour les autres utilisateurs (bon, on veut bien partager les nappes avec les fabricants de soda).
Tout ça pour dire qu'un circuit, photovoltaïque ou non, c'est très loin d'être propre. Et proposer d'en faire des kilomètres carrés au nom de la planète c'est une absurdité complète.
[^] # Re: Le nuclaire, une solution ?????
Posté par nimnim . En réponse au sondage Quelle énergie pour demain ?. Évalué à 3.
Si tu avais aussi des restes de géographie (c'est vrai, d'un niveau plus élevé que le CM2) tu saurais que les Suisses sont assis sur le plus grand château d'eau d'Europe, et les Allemands sur de grands gisements de charbon. Donc les enjeux ne sont pas les mêmes pour eux.
[^] # Re: 6 mois d'utilisation déjà
Posté par nimnim . En réponse à la dépêche Sortie de Fedora 14. Évalué à 6.
1. il était codé proprement (pas encore optimisé, mais bien structuré). On peut optimiser du bon code, c'est très difficile de maintenir du code rapide mais bordélique
2. il utilisait le moteur de résolution de dépendances de rpm au lieu d'utiliser un algo différent lors de la résolution réseau, et espérer que rpm soit d'accord à l'installation (apt-rpm). Cela a permis :
a. de reprendre l'existant rpm sans rupture (simple bon sens pour Red Hat qui était n°1 sur son marché
b. d'écrire des règles de packaging rigoureuses, claires et détaillées, puisqu'il n'y a aucune ambiguïté sur le moteur de règles à respecter (tout passe par librpm et que par librpm), ce qui a permis d'assainir et améliorer la qualité de la distribution en général
3. il était intégrable simplement dans les autres outils Red Hat (Anaconda est en python, comme son nom l'indique). C'est complètement invisible pour les utilisateurs, mais aujourd'hui tous les outils Fedora/Red Hat (Anaconda, PackageKit, la ferme de compilation, Spacewalk, Satellite, Cobbler j'en passe et des meilleures) font appel à l'infrastructure yum et ça marche très bien.
Yum est un choix qui s'est révélé plus que judicieux avec le temps. Red Hat n'avait pas besoin d'un client d'installation type apt-rpm (ils avaient déjà leur propre bouse, up2date qui a heureusement été abandonnée) mais d'une vraie brique d'infrastructure avec laquelle ils pourraient construire d'autres applications. Le yum vu par l'utilisateur est juste un frontal shell, c'est une toute petite partie de ce que yum fait pour Fedora.
D'ailleurs Suse/Novell (qui avait aussi besoin de construire des infras autour de rpm) a écarté comme Red Hat tous les clients apt-like de l'époque, et a fini par écrire le sien de zéro. C'est ce qui leur a permis ensuite de construire https://build.opensuse.org/
[^] # Re: Youpi !!!
Posté par nimnim . En réponse à la dépêche Sortie de Fedora 14. Évalué à 2.