On a pareil ici ; un truc installé au niveau du bios et avec un pilote Windows qui empêche d'utiliser une clé USB en mass storage. Super pénible, mais moins depuis qu'ils ont rajouté github et stackoverflow à la liste blanche.
Je travaille moi aussi pour une institution financière mais d'une autre couleur.
Je pensais à "mois", mais je suis certain qu'il est déjà arrivé que ce soit "jours". De toute manière, c'est dès que la pression monte et qu'on commence à bosser dans l'urgence.
Je pense qu'on est effectivement pas dans le même monde, et ce n'est pas du tout péjoratif : en fait je t'envie.
modifier la responsabilité en montrant que le problème/bug qu'ils ont en prod est corrigé depuis N temps de notre coté et que la balle n'est plus dans notre camps, qu'il n'est pas besoin de nous en reparler tant qu'ils n'ont pas fait de mise à niveau. Sur le long terme mettre en évidence les temps de cycle, ça a était payant.
J'ai d'un côté mon "client" (le métier sponsor de l'application et demandeur d'évolutions) qui voudrait que tout aille très vite, donne son accord à tout pourvu que la réactivité soti là, et de l'autre ma production informatique (typiquement une filiale du groupe dédiée à l'exploitation informatique) qui est accrochée à ses procédures, son respect idéologique à ITIL et surtout à son implémentation locale.
Quand j'ai un bug fonctionnel, que je peux corriger rapidement parce qu'il est dans une procédure stockée, je peux faire la modification et ne livrer que cette procédure stockée. Une fois que le fix est testé, je peux faire une demande de livraison pour ce morceau uniquement, pour lequel on va me donner un accès (temporaire) à la base de production. Je livre vite, mon client est content. Ma production informatique, elle, s'en fout : le périmètre du changement est maîtrisé donc le risque est faible.
Si il est dans la couche Java/JSP/Javascript/… je dois relivrer un EAR complet. Là, c'est l'artillerie lourde, je fais une demande, elle sera prise en compte sous une semaine. Je n'ai pas et je n'aurais jamais accès à la machine hébergeant mon serveur d'app, donc je suis totalement dépendant de ma production pour ça. En fonction de la modification, si en plus il y a un changement de structure de base, je suis obligé d'arrêter l'application, et donc le service, en pleine journée ou attendre le week-end (oui, nos applications tournent 24/5). Par défaut, on ne peut pas arrêter nos applications plus de 15 minutes en journée, sinon les pertes financières peuvent être abyssales.
Je peux montrer tous les tests de la terre, un zoli écran Sonar montrant ma couverture de test unitaire (j'essaye d'être au moins à 50%), mes tests automatiques (un automate simulateur de flux d'entrée/sortie), mon respect des règles de codage, etc. Ca ne change rien ; ma production s'en fout, s'en est toujours foutue et continuera ainsi bien après ma retraite.
Le seul cas où je peux accélérer les choses, c'est en cas d'incident majeur, mais auquel cas je dois justifier de la gravité et de l'impact, faire une escalade hiérarchique pour obtenir 2 ou 3 tampons. Autant dire que si je fais ça trop souvent, je peux mettre tout de suite un terme à ma carrière et partir élever des chèvres dans le Larzac. Donc c'est réservé à la résolution d'incident avec impact, pas juste pour faire plaisir à mon client. Et c'est pensé pour être comme ça, ce n'est pas un effet collatéral.
Tu pars du principe (fort louable) que les tests unitaires/d'intégration sont bien faits, bien maintenus, etc.
De tous les projets que j'ai vu, on a cette approche sur les 6 à 12 premiers d'un projet. Puis ça part en sucette. Pas toujours, certes. Mais très souvent. Dès que la pression commence à monter.
Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".
Maintenant, si sur les projets que tu as vu, la couverture de test reste une priorité sans limite de temps, j'applaudis des deux mains et je te souhaite tout le bonheur du monde. Mais vraiment, c'est pas ce que j'ai vu jusqu'ici, et des projets, j'en vois passer beaucoup (environ 30 nouveaux projets par an dans le secteur bancaire, aux alentours de 15 000 jours/homme).
D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.
Sur ces individus, je les classifie in fine en deux catégories.
1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.
2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.
J'ai vu des énormes projets (i.e. > 10 mio €, au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.
Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.
Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.
Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.
Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).
Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.
Ce que tu décris, c'est l'exception ; dans la plupart des cas, plus de cache signifie moins d'I/O physiques et plus d'I/O logiques.
Sur une base pouvant tenir entièrement en RAM (i.e. moins de 200 Go pour des machines un peu récentes), j'ai vu une amélioration des performances d'environ 50% sur une machine qui saturait les I/Os entre le dataserver et le SAN.
Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.
C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.
Tu as déjà eu des traitements de masse à faire sur une base SQL ? Et tu fais ça via ton appli qui charge chaque ligne, fait le calcul, et stocke le résultat ? Tu fais ça 10,000,000 fois, et tu penses que parce que tu as été super fort, en répartissant le travail sur 200 noeuds, tu as obtenu une bonne vitesse de traitement ? Quid des I/Os engendrées entre la machine hébergeant la base, et la machine hébergeant ton application ? Le franchissement de DMZ, la charge sur la baie de stockage, la non-utilisation du cache de la base, et j'en passe ?
Mon dieu…
C'est pas seulement une question de savoir où on met la couche truc et la layer bidule. C'est juste d'avoir un temps d'exécution acceptable pour répondre aux contraintes des utilisateurs.
J'utilise ça tous les jours et ça fonctionne plutôt bien.
Par contre, pleins de fonctionnalités sont en option (minimal logging, compression), le transac-sql (langage de procédures stockées) évolue très très très lentement. Bref, je bave devant un postgresql.
L'autre soucis c'est que c'est tellement en perte de vitesse que le support se dégrade : plusieurs semaines pour le correctif d'un bug qui fait crasher le dataserver systématiquement…
Dans l'article je vois qu'effectivement Mozilla n'est pas un des navigateurs testés, mais en remontant à l'article source (eweek) je ne vois nulle part écrit 'because it's too easy'. Juste qu'il n'y a pas eu d'évolution significative coté sécurité.
Quelqu'un a une autre source pour confirmer la motivation derrière la décision des organisateurs ?
Sinon, on parle beaucoup d'IE dans les commentaires de ce journal mais ce dernier n'est plus testé non plus c'est désormais Edge qui retient l'attention.
Même constat ici avec 50GB de photos. J'ai beau être sous Gnome3, je continue d'utiliser digikam.
De là à dire que la perte de shotwell ne serait pas gênante, je ne suis pas d'accord. C'est une application assez sobre, bien dans l'esprit de Gnome : les actions de base sont faciles d'accès, et c'est l'enfer dès qu'on veut aller plus loin. Ca répond bien au besoin de beaucoup de personnes.
Etre agnostique c'est aussi se dire qu'il y a d'autres questions plus importantes dans la vie. Ou en tout cas qui t'apporteront plus si tu y trouves une réponse, genre "comment être heureux ?", "comment permettre aux autres d'être heureux ?"…
Je travaille dans une filiale d'institution financière ; environ 8,000 postes. Tout le monde a MS/Office d'installé (package par défaut), mais uniquement certains utilisateurs ont un usage vraiment avancé.
On va dire grosso modo :
1) des équipes IT, qui font tourner des macros pour simplifier la vie des équipes de support fonctionnel (environ 800),
2) quelques power users (allez, à la louche on va dire une centaine)
3) les salles des marchés (les cambistes et les vendeurs) : entre 1 et 2% des salariés
Pour 1) et 2), on peut envisager de réécrire ; il y a finalement peu de ligne de code, et généralement rien de bien compliqué.
Pour 3), j'ai beau avoir désinstallé MS/Office de chez moi il y a plusieurs années, je n'imagine pas de solution au remplacement de MS/Office. Certains produits incontournables (genre Thomson-Reuters Eikon) ne peuvent tout simplement pas fonctionner sans Excel, et la salle de marché ne peut pas travailler sans eux.
La seule solution serait d'isoler ces utilisateurs, de les laisser dans leur petite bulle. C'est déjà un peu le cas (ils sont les seuls à disposer de 6 écrans, de machines avec plus de 32 Go de RAM, etc. Mais les décisions sont prises au niveau du groupe, et d'autres filiales ont une proportion d'utilisateurs en salle de marché bien plus importante.
Et personne ne veut risquer d'avoir plusieurs "standards" bureautique dans la même entité.
D'autant qu'on est tous d'accord pour dire que Excel, c'est une tuerie en terme de performances (pour la stabilité, c'est une autre histoire). J'arrive pas à faire les même choses avec LibreOffice Calc, ou en tout cas pas autant de calculs simultanés sans constater de grosses lenteurs.
Désolé, au final mon commentaire n'a pratiquement plus rien à voir avec le fil auquel il répond, mais mon esprit vagabond fait ce qu'il veut - effet conjoint de la chaleur du sud de la France et des vacances :-).
"Comment demander à des gens de faire confiance à un truc alors qu'ils n'en maîtrisent même pas le concept de base ET qu'ils s'en rendent compte ?" - Je comprends mais les gens ne comprennent pas le système monétaire actuel.
Le fait est qu'ils ont l'impression de le comprendre, ou au moins d'en comprendre la base. Cette impression leur permet d'avoir confiance. Avec les Bitcoins, ils n'ont même pas ça, d'où une confiance moindre (voire nulle).
Rends-toi compte : il a fallu plus d'un siècle pour que les gens arrêtent de stocker leur argent dans des bas de laine planqués sous le matelas. Et là, on leur parle de crypto devise ! Le concept risque de devoir attendre quelques générations avant de se répandre…
L'exemple du venezuella est extrême mais après tout, la BCE n'a pas réussi à maintenir le taux d'inflation qu'elle devait maintenir. Certains pensent qu'il vaut mieux avoir confiance dans le marché qu'en les banques centrales.
Alors là, une source est bienvenue sur qui sont ces "certains". Le marché, c'est aussi la spéculation. Sans régulateur, c'est la foire. Et pour l'instant, je ne vois rien qui empêche la spéculation sur le Bitcoin, bien au contraire.
Et la BCE n'a certes pas réussi à maintenir le taux d'inflation, mais elle a limité les dégâts. Sans BCE, quelle aurait été la situation ?
Si tu regardes l'histoire récente, et que tu regardes le rouble par exemple, je ne suis pas d'accord. ça dépend fortement de la période que tu consultes.
Encore un contre exemple. Même le cours USD/RUB, qui a effectivement été très perturbé, n'a pas connu une volatilité aussi forte que le Bitcoin. Et pourtant, le Bitcoin n'a pas encore été confronté à une utilisation massive - ça ne laisse pas présager le meilleur…
Dans la partie "Réserve de valeur", tu expliques que tu veux pouvoir garder de l'argent de côté en ayant un bon niveau de confiance sur le fait que sa valeur ne variera pas trop d'ici à ton achat.
Et tu dis après que ça n'implique pas qu'un organisme se charge de gérer la devise ? Mais c'est exactement à ça que sert une banque centrale : à trouver des compromis entre risques déflationnistes et inflationnistes. En jouant sur les taux d'intérêt. En créant/supprimant de la monnaie. Si on enlève la banque centrale, c'est la seule loi de l'offre et de la demande qui définit la valeur de la monnaie.
Et l'histoire récente a bien montré cela : les variations BitCoins vs. devise XYZ (quel que soit XYZ) ont été bien plus importantes qu'entre n'importe quelles devises traditionnelles. Et ce malgré les crises rencontrées (et on est quand même dans une période bien agitée…). Et ce malgré l'usage encore restreint des BitCoins.
Quand le cours EUR/USD varie de 50% sur 2 ans, les marchés sont bouleversés ; le coût de la vie d'un côté et/ou de l'autre de l'Atlantique s'en ressent fortement. Or, pour le BitCoin, ce sont des variations de 400% sur quelques mois qu'on a pu voir.
Perso, l'argent pour ma maison, je vais continuer à le mettre de côté sur un compte traditionnel, quitte à mettre une petite partie en BitCoin pour respecter le principe de diversification. Bref, le BitCoin va venir en plus et ne va rien remplacer.
Pour continuer, ton exemple sur la création de la banque d'Angleterre est un contre-exemple. Les billets avaient une valeur faciale avec un cours fixe équivalent or. Il y avait un intermédiaire unique - certes, pas l'état, mais dont l'intérêt était que la valeur des billets ne soit jamais remise en doute. Quel est le parallèle avec le BitCoin ?
Par ailleurs, et c'est très important : cette correspondance billet/quantité d'or était un concept compréhensible par tous et qui inspirait confiance (ce qui ne veut pas dire qu'il méritait cette confiance, la nuance est importante) ; la crypto devise, c'est un concept moins accessible au commun des mortels. Dès que tu parles de blockchain tu as perdu 99% de ton auditoire, et pourtant c'est un des concepts indispensables pour appréhender le fonctionnement.
Comment demander à des gens de faire confiance à un truc alors qu'ils n'en maîtrisent même pas le concept de base ET qu'ils s'en rendent compte ?
A mon sens, les crypto devises ont de l'avenir, mais aujourd'hui je ne parierai pas grand chose sur le BitCoin. Il y a encore bien des aspects non techniques à gérer.
[^] # Re: La sécurité ? Une contrainte pour la productivité
Posté par Dring . En réponse au journal Avant c'est trop cher, après c'est trop tard. Évalué à 2.
On a pareil ici ; un truc installé au niveau du bios et avec un pilote Windows qui empêche d'utiliser une clé USB en mass storage. Super pénible, mais moins depuis qu'ils ont rajouté github et stackoverflow à la liste blanche.
Je travaille moi aussi pour une institution financière mais d'une autre couleur.
[^] # Re: Traditions du HS
Posté par Dring . En réponse au journal LinuxFr.org n'aime pas discuter du hors sujet [titre réécrit]. Évalué à 6.
Bonjour,
Je suis nouveau sur le site, et je vois souvent l'emploi du verbe "bronsoniser". C'est quoi donc que ça veut dire ?
D'avance merci,
Un gars qu'il est nouveau sur le site et qui aime l'humour de répétition. De répétition.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Je pensais à "mois", mais je suis certain qu'il est déjà arrivé que ce soit "jours". De toute manière, c'est dès que la pression monte et qu'on commence à bosser dans l'urgence.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Je pense qu'on est effectivement pas dans le même monde, et ce n'est pas du tout péjoratif : en fait je t'envie.
J'ai d'un côté mon "client" (le métier sponsor de l'application et demandeur d'évolutions) qui voudrait que tout aille très vite, donne son accord à tout pourvu que la réactivité soti là, et de l'autre ma production informatique (typiquement une filiale du groupe dédiée à l'exploitation informatique) qui est accrochée à ses procédures, son respect idéologique à ITIL et surtout à son implémentation locale.
Quand j'ai un bug fonctionnel, que je peux corriger rapidement parce qu'il est dans une procédure stockée, je peux faire la modification et ne livrer que cette procédure stockée. Une fois que le fix est testé, je peux faire une demande de livraison pour ce morceau uniquement, pour lequel on va me donner un accès (temporaire) à la base de production. Je livre vite, mon client est content. Ma production informatique, elle, s'en fout : le périmètre du changement est maîtrisé donc le risque est faible.
Si il est dans la couche Java/JSP/Javascript/… je dois relivrer un EAR complet. Là, c'est l'artillerie lourde, je fais une demande, elle sera prise en compte sous une semaine. Je n'ai pas et je n'aurais jamais accès à la machine hébergeant mon serveur d'app, donc je suis totalement dépendant de ma production pour ça. En fonction de la modification, si en plus il y a un changement de structure de base, je suis obligé d'arrêter l'application, et donc le service, en pleine journée ou attendre le week-end (oui, nos applications tournent 24/5). Par défaut, on ne peut pas arrêter nos applications plus de 15 minutes en journée, sinon les pertes financières peuvent être abyssales.
Je peux montrer tous les tests de la terre, un zoli écran Sonar montrant ma couverture de test unitaire (j'essaye d'être au moins à 50%), mes tests automatiques (un automate simulateur de flux d'entrée/sortie), mon respect des règles de codage, etc. Ca ne change rien ; ma production s'en fout, s'en est toujours foutue et continuera ainsi bien après ma retraite.
Le seul cas où je peux accélérer les choses, c'est en cas d'incident majeur, mais auquel cas je dois justifier de la gravité et de l'impact, faire une escalade hiérarchique pour obtenir 2 ou 3 tampons. Autant dire que si je fais ça trop souvent, je peux mettre tout de suite un terme à ma carrière et partir élever des chèvres dans le Larzac. Donc c'est réservé à la résolution d'incident avec impact, pas juste pour faire plaisir à mon client. Et c'est pensé pour être comme ça, ce n'est pas un effet collatéral.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Désolé de me (ré)insérer dans cette discussion.
Tu pars du principe (fort louable) que les tests unitaires/d'intégration sont bien faits, bien maintenus, etc.
De tous les projets que j'ai vu, on a cette approche sur les 6 à 12 premiers d'un projet. Puis ça part en sucette. Pas toujours, certes. Mais très souvent. Dès que la pression commence à monter.
Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".
Maintenant, si sur les projets que tu as vu, la couverture de test reste une priorité sans limite de temps, j'applaudis des deux mains et je te souhaite tout le bonheur du monde. Mais vraiment, c'est pas ce que j'ai vu jusqu'ici, et des projets, j'en vois passer beaucoup (environ 30 nouveaux projets par an dans le secteur bancaire, aux alentours de 15 000 jours/homme).
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 5.
D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.
Sur ces individus, je les classifie in fine en deux catégories.
1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.
2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.
J'ai vu des énormes projets (i.e. > 10 mio €, au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.
Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.
Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.
Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.
Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).
Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Ce que tu décris, c'est l'exception ; dans la plupart des cas, plus de cache signifie moins d'I/O physiques et plus d'I/O logiques.
Sur une base pouvant tenir entièrement en RAM (i.e. moins de 200 Go pour des machines un peu récentes), j'ai vu une amélioration des performances d'environ 50% sur une machine qui saturait les I/Os entre le dataserver et le SAN.
Donc oui, je l'ai déjà testé. Plusieurs fois.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 7.
Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.
C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.
Tu as déjà eu des traitements de masse à faire sur une base SQL ? Et tu fais ça via ton appli qui charge chaque ligne, fait le calcul, et stocke le résultat ? Tu fais ça 10,000,000 fois, et tu penses que parce que tu as été super fort, en répartissant le travail sur 200 noeuds, tu as obtenu une bonne vitesse de traitement ? Quid des I/Os engendrées entre la machine hébergeant la base, et la machine hébergeant ton application ? Le franchissement de DMZ, la charge sur la baie de stockage, la non-utilisation du cache de la base, et j'en passe ?
Mon dieu…
C'est pas seulement une question de savoir où on met la couche truc et la layer bidule. C'est juste d'avoir un temps d'exécution acceptable pour répondre aux contraintes des utilisateurs.
[^] # Re: Sybase / SAP ASE
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
J'utilise ça tous les jours et ça fonctionne plutôt bien.
Par contre, pleins de fonctionnalités sont en option (minimal logging, compression), le transac-sql (langage de procédures stockées) évolue très très très lentement. Bref, je bave devant un postgresql.
L'autre soucis c'est que c'est tellement en perte de vitesse que le support se dégrade : plusieurs semaines pour le correctif d'un bug qui fait crasher le dataserver systématiquement…
[^] # Re: Zfs vs BTRFS
Posté par Dring . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 1.
Le planificateur Windows existait déjà sous Windows 95… Et sous Windows NT 3.x. Où on avait aussi la formidable commande "at".
[^] # Re: Ceci n'est pas un troll !
Posté par Dring . En réponse au journal Iceweasel is dead!. Évalué à 7.
Dans l'article je vois qu'effectivement Mozilla n'est pas un des navigateurs testés, mais en remontant à l'article source (eweek) je ne vois nulle part écrit 'because it's too easy'. Juste qu'il n'y a pas eu d'évolution significative coté sécurité.
Quelqu'un a une autre source pour confirmer la motivation derrière la décision des organisateurs ?
Sinon, on parle beaucoup d'IE dans les commentaires de ce journal mais ce dernier n'est plus testé non plus c'est désormais Edge qui retient l'attention.
[^] # Re: Liquide
Posté par Dring . En réponse au journal Galette pomme/noisette. Évalué à 9.
Je préfère l'hydrogène, ça marchera si je prends ça comme liquide ? ;-)
Bon, sérieusement, le liquide en question doit être liquide à l'état naturel, sinon vous ne passerez pas l'hiver.
[^] # Re: Ça a l'air trop bon
Posté par Dring . En réponse au journal Galette pomme/noisette. Évalué à 10.
Je m'insurge ; du point de vue des industriels, la margarine est bien meilleure puisque la marge dégagée est supérieure !
Après, si on parle santé bien sûr…
[^] # Re: lcdlp
Posté par Dring . En réponse au journal Ian Murdock est mort :-(. Évalué à 3.
Indice : "con de mime !"
[^] # Re: shotwell
Posté par Dring . En réponse au journal Yorba ne développera plus Geary, Shotwell et California. Évalué à 5. Dernière modification le 23 novembre 2015 à 13:16.
Même constat ici avec 50GB de photos. J'ai beau être sous Gnome3, je continue d'utiliser digikam.
De là à dire que la perte de shotwell ne serait pas gênante, je ne suis pas d'accord. C'est une application assez sobre, bien dans l'esprit de Gnome : les actions de base sont faciles d'accès, et c'est l'enfer dès qu'on veut aller plus loin. Ca répond bien au besoin de beaucoup de personnes.
[^] # Re: Dieu n'existe pas
Posté par Dring . En réponse au journal Paris sous les balles. Évalué à 3.
Etre agnostique c'est aussi se dire qu'il y a d'autres questions plus importantes dans la vie. Ou en tout cas qui t'apporteront plus si tu y trouves une réponse, genre "comment être heureux ?", "comment permettre aux autres d'être heureux ?"…
[^] # Re: Design orthogonal
Posté par Dring . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 3.
Foutaises !
[^] # Re: participation en rédaction
Posté par Dring . En réponse à la dépêche Sortie du noyau Linux 4.2. Évalué à 5.
J'ai déjà des crampes d'estomac :-)
[^] # Re: Beep
Posté par Dring . En réponse au journal Concours de musique 1-bit. Évalué à 2. Dernière modification le 23 août 2015 à 15:13.
Commentaire effacé par son auteur
[^] # Re: Pourquoi libreoffice ne gère pas les macros excel ?
Posté par Dring . En réponse au journal Nantes migre vers LibreOffice. Évalué à 10.
Je travaille dans une filiale d'institution financière ; environ 8,000 postes. Tout le monde a MS/Office d'installé (package par défaut), mais uniquement certains utilisateurs ont un usage vraiment avancé.
On va dire grosso modo :
1) des équipes IT, qui font tourner des macros pour simplifier la vie des équipes de support fonctionnel (environ 800),
2) quelques power users (allez, à la louche on va dire une centaine)
3) les salles des marchés (les cambistes et les vendeurs) : entre 1 et 2% des salariés
Pour 1) et 2), on peut envisager de réécrire ; il y a finalement peu de ligne de code, et généralement rien de bien compliqué.
Pour 3), j'ai beau avoir désinstallé MS/Office de chez moi il y a plusieurs années, je n'imagine pas de solution au remplacement de MS/Office. Certains produits incontournables (genre Thomson-Reuters Eikon) ne peuvent tout simplement pas fonctionner sans Excel, et la salle de marché ne peut pas travailler sans eux.
La seule solution serait d'isoler ces utilisateurs, de les laisser dans leur petite bulle. C'est déjà un peu le cas (ils sont les seuls à disposer de 6 écrans, de machines avec plus de 32 Go de RAM, etc. Mais les décisions sont prises au niveau du groupe, et d'autres filiales ont une proportion d'utilisateurs en salle de marché bien plus importante.
Et personne ne veut risquer d'avoir plusieurs "standards" bureautique dans la même entité.
D'autant qu'on est tous d'accord pour dire que Excel, c'est une tuerie en terme de performances (pour la stabilité, c'est une autre histoire). J'arrive pas à faire les même choses avec LibreOffice Calc, ou en tout cas pas autant de calculs simultanés sans constater de grosses lenteurs.
Désolé, au final mon commentaire n'a pratiquement plus rien à voir avec le fil auquel il répond, mais mon esprit vagabond fait ce qu'il veut - effet conjoint de la chaleur du sud de la France et des vacances :-).
[^] # Re: hum
Posté par Dring . En réponse à la dépêche Envoi de spam à partir d'un serveur, comment réagir ?. Évalué à 6.
Attention, l'auteur du journal parle bien de la zone "sender", pas du "From" de l'entête de mail qui est effectivement libre.
[^] # Re: Ma réponse
Posté par Dring . En réponse au journal Que répondre quand on vous dit que Bitcoin n’est pas une vraie monnaie ?. Évalué à 7.
Pour les mécréants qui n'ont pas accès à Twitter (bloqué par le proxy de ma société), quelqu'un peut me raconter ce qui s'y passe ? Je suis intrigué.
[^] # Re: Un peu trop facile...
Posté par Dring . En réponse au journal Que répondre quand on vous dit que Bitcoin n’est pas une vraie monnaie ?. Évalué à 5.
Le fait est qu'ils ont l'impression de le comprendre, ou au moins d'en comprendre la base. Cette impression leur permet d'avoir confiance. Avec les Bitcoins, ils n'ont même pas ça, d'où une confiance moindre (voire nulle).
Rends-toi compte : il a fallu plus d'un siècle pour que les gens arrêtent de stocker leur argent dans des bas de laine planqués sous le matelas. Et là, on leur parle de crypto devise ! Le concept risque de devoir attendre quelques générations avant de se répandre…
Alors là, une source est bienvenue sur qui sont ces "certains". Le marché, c'est aussi la spéculation. Sans régulateur, c'est la foire. Et pour l'instant, je ne vois rien qui empêche la spéculation sur le Bitcoin, bien au contraire.
Et la BCE n'a certes pas réussi à maintenir le taux d'inflation, mais elle a limité les dégâts. Sans BCE, quelle aurait été la situation ?
Encore un contre exemple. Même le cours USD/RUB, qui a effectivement été très perturbé, n'a pas connu une volatilité aussi forte que le Bitcoin. Et pourtant, le Bitcoin n'a pas encore été confronté à une utilisation massive - ça ne laisse pas présager le meilleur…
USD/RUB sur 2 ans :
http://www.xe.com/fr/currencycharts/?from=USD&to=RUB&view=2Y
La courbe sur 2 ans de USD/XBT (le "pseudo" code ISO pour Bitcoin) fait nettement plus peur :
http://www.xe.com/fr/currencycharts/?from=USD&to=XBT&view=2Y
# Un peu trop facile...
Posté par Dring . En réponse au journal Que répondre quand on vous dit que Bitcoin n’est pas une vraie monnaie ?. Évalué à 10.
Déjà, je vois contradiction entre deux choses.
Dans la partie "Réserve de valeur", tu expliques que tu veux pouvoir garder de l'argent de côté en ayant un bon niveau de confiance sur le fait que sa valeur ne variera pas trop d'ici à ton achat.
Et tu dis après que ça n'implique pas qu'un organisme se charge de gérer la devise ? Mais c'est exactement à ça que sert une banque centrale : à trouver des compromis entre risques déflationnistes et inflationnistes. En jouant sur les taux d'intérêt. En créant/supprimant de la monnaie. Si on enlève la banque centrale, c'est la seule loi de l'offre et de la demande qui définit la valeur de la monnaie.
Et l'histoire récente a bien montré cela : les variations BitCoins vs. devise XYZ (quel que soit XYZ) ont été bien plus importantes qu'entre n'importe quelles devises traditionnelles. Et ce malgré les crises rencontrées (et on est quand même dans une période bien agitée…). Et ce malgré l'usage encore restreint des BitCoins.
Quand le cours EUR/USD varie de 50% sur 2 ans, les marchés sont bouleversés ; le coût de la vie d'un côté et/ou de l'autre de l'Atlantique s'en ressent fortement. Or, pour le BitCoin, ce sont des variations de 400% sur quelques mois qu'on a pu voir.
Perso, l'argent pour ma maison, je vais continuer à le mettre de côté sur un compte traditionnel, quitte à mettre une petite partie en BitCoin pour respecter le principe de diversification. Bref, le BitCoin va venir en plus et ne va rien remplacer.
Pour continuer, ton exemple sur la création de la banque d'Angleterre est un contre-exemple. Les billets avaient une valeur faciale avec un cours fixe équivalent or. Il y avait un intermédiaire unique - certes, pas l'état, mais dont l'intérêt était que la valeur des billets ne soit jamais remise en doute. Quel est le parallèle avec le BitCoin ?
Par ailleurs, et c'est très important : cette correspondance billet/quantité d'or était un concept compréhensible par tous et qui inspirait confiance (ce qui ne veut pas dire qu'il méritait cette confiance, la nuance est importante) ; la crypto devise, c'est un concept moins accessible au commun des mortels. Dès que tu parles de blockchain tu as perdu 99% de ton auditoire, et pourtant c'est un des concepts indispensables pour appréhender le fonctionnement.
Comment demander à des gens de faire confiance à un truc alors qu'ils n'en maîtrisent même pas le concept de base ET qu'ils s'en rendent compte ?
A mon sens, les crypto devises ont de l'avenir, mais aujourd'hui je ne parierai pas grand chose sur le BitCoin. Il y a encore bien des aspects non techniques à gérer.
[^] # Re: Les dealers, les [:pedobear] et les nigerians vont être contents
Posté par Dring . En réponse au journal Le réseau Tor a besoin de vous !. Évalué à 2.
Attention lecteur : humour potache et inutile !
Tu as retiré le "s" à la fin de "blanche" parce qu'on aurait pu lire "sexiste" ?
Sinon, pourquoi que les blanches ?