Zenitram a écrit 29583 commentaires

Vu que ce n'était pas la question...

Désolé, c'était la question que je me posais devant les chiffres annoncés pour une "PME de 50 personnes".
Ca me parait déjà plus logiques comme chiffres, et c'est tout de suite moins "hors de prix", surtout que ça n'a absolument rien à voir avec le protocole utilisé (en FTPS avec ce qu'on veut au dessus, ça serait le même prix, ce n'est pas l'interface qui est facturée!), le prix peut très bien baisser tout en utilisant EBICS (pas de contraintes de son côté à lui...)

C'est tellement facile de trouver un bouc émissaire...

La plupart des banques sont tellement nulles que la majorité des entreprises qui font un CA correct ont plusieurs banques (et souvent plusieurs comptes par banque).

Ca ne dit toujours pas combien de ces comptes ont besoin d'un contrat pour les forts volumes.

4 comptes avec EBICS nécessaires pour 50 personnes???

Certes, je ne connais pas trop le domaine, mais ça me parait quand même délirant. Que tu ais 4 comptes pour des raisons x ou y (compétition entre banques), OK. Que tu ais besoin de 4 comptes avec un énorme volume d'ordres à passer, comprend pas.

En plus, 7000/50 = 140 €/personne. Un peu comme le prix annuel d'une fiche de paye donc, pas la mort non plus. Sans compter que j'ai du mal à croire 4 comptes avec forts volumes de transactions nécessaires (allez, hop, un compte pour les forts volumes genre salaires mensuels, les autres en ponctuel par l'interface web) donc au final encore moins cher...

Mais il n'y a aucun logiciel libre de transfert multibancaire vers tous pays via les canaux EBICS.

Est-ce qu'il y a quelque chose qui empêche techniquement la réalisation d'un logiciel libre de transfert multibancaire vers tous pays via les canaux EBICS?
- Oui : en quoi?
- Non : tu peux le faire, donc pas de problème, c'est ton choix, ton problème, code.

Et encore une fois, FTPS, c'est le transport, équivalent à HTTPS dans EBICS si j'ai bien compris, et tu as toujours l’achat de certificats à faire. Et des logiciels libres faisant HTTPS, il y en a à la pelle. Donc pareil, jusque que FTP(S) n'est pas du tout adapté au transactionnel, HTTPS est un bien meilleur choix, à moins que tu me démontre le contraire...

J'ai vraiment du mal à comprendre cette volonté de balancer un protocole inadapté pour la couche de transport... Et surtout de dire que FTPS ça remplace "tout", alors que ça rempalce que HTTPS de EBICS. Donc vous mettez quoi derrière votre FTPS? Le reste de la spec EBICS?

Tout décision qui vise à voler moins d'argent au contribuable est toujours bienvenue.

Ca tombe bien, ce n'est pas du vol.
Autant je ne suis pas forcément d'accord pour ce projet spécifique (j'en ai pris mon -10, et la contre argumentation soulevée ici était très enrichissante), autant la, ce que tu racontes, c'est du pur mensonge.

Qu'est ce qui n'est pas spécifié en c++? C'est une vrai question, je veux bien te croire, et ce serai intéressant d'avoir plus d'infos

Example : un "int" c'est minimum 16 bits. la spec ne dit pas le maximum. Du coup, suivant l'OS (c'est plus lié à l'OS qu'au compilo), un int peut être 16 bits (sur les CPU 16 bits qu'on ne voit plus de nos jours), 32 bits (classique), ou 64 bits (sur certains OS 64 bits, mais pas tous). un "long" est minimum 32 bits, la spec ne dit pas de maximum, ça peut être 64 bits sur un OS 64 bit, ou... Pas.
http://en.wikipedia.org/wiki/C_variable_types_and_declarations#Size
http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models

C'est une des conneries historiques du C, à trop vouloir être proche du CPU. Bon, ils ont corrigé le tir maintenant, la spec actuelle spécifie des int8_t, int16_t, int32_t, int64_t, mais tout les compilos ne sont pas à jour, et la fainéantise fait qu'on écrit plus facilement int que int32_t.

(bon, j'espère que cette fois-ci, je n'aurai pas écrit une connerie sur la spec C...)

Il te prévient pas si tu utilises l'opérateur [].

Ce que tu lui reproches, c'est de laisser le choix?
Salaud de langage qui laisse le choix, faudrait interdire le choix (après, si les programmeurs choisissent la version rapide sans faire attention aux limites, c'est la fautes à eux, pas au langage!)

Certes, il n'y a pas de compilo que je connaisse qui a une option "trucs sans tests de limites interdit", mais si il y a un besoin je ne pense pas que ce soit dur à faire.

Sinon, Java, les tableaux en version non escargot, tu fais comment?

Eeeeuh, tu es sûr de ton coup là ?

Non https://linuxfr.org/nodes/86730/comments/1251689
Parlé trop vite, j'étais persuadé que c'était défini, bon je suis sauvé pour mon code, j'évite ce genre de code (mettre du ++ ailleurs que dans une ligne seule) pour pas avoir ce genre de plaisanterie.

Comme quoi on en apprend tous les jours :
" An often-cited example is the C expression i=i++, which apparently both assigns i its previous value and increments i. The final value of i is ambiguous, because, depending on the order of expression evaluation, the increment may occur before, after, or interleaved with the assignment. The definition of a particular language might specify one of the possible behaviors or simply say the behavior is undefined. In C and C++, evaluating such an expression yields undefined behavior.[2]"

Moi qui était persuadé que l'ordre était défini dans la spec et donc que tous les compilateurs faisaient pareil... Bon, ben je saurai maintenant, lecture intéressante.

ou des "baisés"...
(après, réussir à faire faire un don avant que le donateur voit le produit, c'était vraiment un coup publicitaire fort réussi, bravo la dessus)

Diaspora il m'a semblé comprendre qu'il fallait leur "foutre une paix royale" en ce moment :-)

Dit merde à leur actionnaires, c'est sympa. Désolé, mais ils ont demandé du fric à la "communauté", "foutre une paix royale" n'est pas une bonne réponse. Fallait pas demander du fric sinon.

Je ne vois donc pas pourquoi on dit encore qu'il n'y a pas de chiffres permettant d'avoir une idée sur le sujet.

Parce qu'ils veulent faire de la politique, et se cacher la réalité quand elle ne va pas dans leur direction, et ne surtout pas discuter du problème qui en découle, juste faire croire que je suis un menteur parce que je leur met le nez dans le caca des stats linuxiennes.

Méthode Coué. Qui ne convainc qu'eux, les autres vivent sans Linux. Comment ensuite discuter si ils n'acceptent pas la réalité comme base de discussion? Comment regarder les problèmes qui en découlent si il "n'y a pas de problèmes"?

Tu veux dire C++ <= C ?

Non, C++ est vraiment < C
Pourquoi?
C++ veut dire "je prend le chiffre avec le quel je fais la comparaison, puis j'incrémente". Donc le C de gauche vaut C, le C de droite vaut C+1 (incrémenté par le ++ de gauche, la gauche est testé avant la droite)

Par contre +CC n'est pas < C
Car +CC veut dire "j'incrémente, puis je prend le chiffre avec le quel je fais la comparaison", donc le C de gauche vaut C+1, le C de droite vaut C+1.

Subtilité certes, il faut "juste" savoir ce que veut dire "++" en C++, et on fait jamais ça en pratique. "C++; if (C<C)" c'est plus sûr, plus compréhensible.
Oui, il y a des piège en C++, mais il y en a aussi en Java ou Python, juste pas les mêmes.

ça peut dépendre de l'ordre d'évaluation des expressions C++ et C qui peut varier d'un compilo à l'autre

Et puis quoi encore. C'est dans la norme C++, un compilo qui ne fait pas ce que tu la norme est un compilo buggué. Ce n'est pas un cas de résultat indéfini, au contraire, c'est un cas d'école très classique (dans le même style que le truc sur les float en PHP qu'on retrouve dans des tests à la con)

Allez savoir pourquoi sous Windows et Cygwin, ça s'initialisait tout le temps soit à NULL soit à zéro.

Parce que c'est plus rapide. Et c'est bien.
en C++, tu a le choix (soit tu utilises des objets à la Java et ce sera initialisé par le constructeur, soit tu définit la variable et tu la définit que si besoin, rapidité tout ça)

J'ai mes deux gagnants!

Ton programme Java va immédiatement te dire que ton accès est mauvais, alors qu'en C ou C++, dans le pire cas personne ne te dit quoi que ce soit et tu as l'impression que ça marche

Tout pareil avec C++ qu'avec Java:
http://www.cplusplus.com/reference/stl/vector/at/
"vector::at signals if the requested position is out of range by throwing an out_of_range exception."

Juste que C++ permet effectivement de programmer à l'ancienne (version C) pour une compatibilité ascendante (avec les risques qui voient avec), mais voila, C++ est critiqué non pas pour C++, mais pour sa compatibilité. Alors, que Java, il faut tout refaire (ou se faire chier pour faire un binding vers la lib C, ça marche certes, mais c'est chiant), ou c'est hyper lent (car Java ne permet pas de déactiver le test out of range, et parfois, ça fait ramer à mort par rapport à C++ et son [] qui ne teste pas, bref, avec C++, tu as le choix).

Bref, non, Java ne protège pas plus que C++, juste Java protège plus que C mal codé (comme C++ protège plus que C mal codé)

Une partie n'a pas d'adresse email

Je suis vraiment pas à jour, ça doit être un problème générationnel, trop vieux.
Alors qu'on m'a encore demandé dernièrement mon numéro de fax...

ils pourront plus utiliser cette image pour la prochaine devinette de Karambolage, désolé.

Argh souvenirs...
Bon, pour la forme, France ou Allemagne? 1 et 2

remplace par :

(c'est l'équivalent allemand sur la photo)

Donc 4 à 5 jours pour savoir que mon message n'a pas été délivré, c'est pas idéal pour un remplaçant du SMS.

2 jours pour le message d'abandon du SMS, c'est si mieux que ça? (c'est en tous cas le temps que ça met chez moi)

Sans compter qu'avec le mail, si les webmail faisaient correctement le boulot, il y a aussi l'accusé de réception (bon, d'accord, gmail, hotmail et compagnie l'ignorent royalement... Mais ça ne vient pas du protocole)

Donc si, le SMS peut très bien être remplacé par le mail, surtout que depuis un moment, les smartphones supportent très bien cette méthode, et le temps maximum que ça met entre moi et mon correspondant est moins d'une minute (durée minimale du pooling sous thunderbird, de toute façons le serveur OVH me jette si je fais trop souvent en dessous, aussi, mais ça reste de la configuration, on pourrait très bien configurer pour faire un pooling par seconde, pas optimal mais ça marche)

Bref, c'est quoi ton problème avec le mail, en pratique? Parce que moi, tous les jours, je l'utilise en mode SMS, et ça marche (très vite)

Bien pour toi. Mais le fait que pour toi, dans une utilisation limitée volontairement au libre, ça marche mieux, ne fait pas d'IPv6 un truc génial qui a sa killer feature pour être déployé.

Je répondais à Dorian qui dit qu'avec ta démo, IPv6 a sa killer feature, non elle ne l'a pas : pour toi oui, mais une killer feature, c'est un truc massivement utile qui va pouvoir être "vendable" partout. Et dans 99% des cas, ta killer feature, on va lui rire au nez en disant "chez moi ça marche sans IPv6".

Je persiste donc : IPv6 est toujours à la recherche de sa "killer-feature".

Il vient de prouver quoi? Qu'avec IPv6, c'est génial car ça marche du premier coup la VoIP?
Je lui donne un contre exemple : chez tous les utilisateurs d'un logiciel connu, ça marche du premier coup, en IPv4.

Alors pointe moi où il démontre que IPv6 propose mieux.
Pour info, le fait de pouvoir utiliser un logiciel libre à la place d'un logiciel proprio a une importance pour 1% de la population, bref aucune importance pour une killer feature.

C'est du foutage de gueule que de trouver une killer feature dans un truc qui fonctionne en IPv4 chez 99% des gens. Du Troll? Non, une réalité bien réelle chez les gens, qui ne s'emmerdent pas.

Du coup maintenant je vois très concrètement l'utilité et la nécessité d'IPv6 pour le réseau…

Il y a personne pour dire que le NAT n'est pas un pis-aller, oui IPv6 est bien. Mais... pourquoi changer toute la chaine de transport quand on arrive à faire évoluer ce bon vieux IPv4 pour que ça réponde au besoin? en IPV4, deux personnes derrière un NAT, ça marche très bien. Techniquement, c'est galère pour le développeur, oui, mais ça marche. Demander aux gens de changer pour aucun gain pour eux (juste moins de galère pour le développeur), ce n'est pas suffisant (et on le voit : tout le monde s'en fout d'IPv6).

IPv6 est toujours à la recherche de sa "killer-feature" qu'IPv4 ne peut pas remplir en bidouillant.

Bref y passer un peu de temps initialement, genre 1h plutôt que 10 min entre pulseaudio, la webcam, le firewall, la conf' de base et le temps au téléphone, un peu de patience quoi et quelques bugs report au passage ou l'écriture d'un tuto pour montrer que ça fonctionne...).

Skype, juste ça marche. Tu es masochiste, pas moi.

Bon, comme je suis curieux, j'ai testé, pour connaitre un peu la compétition :
- Install (sous Windows) du serveur et client facile
- 1er lancement, fail : il me demande des données techniques imbitable pour l'utilisateur moyen : faut que je choisisse mon périphérique audio (peut-être parce que j'en ai 2... Mais j'en ai rien à faire, Windows a un truc "périphérique par défaut", ce n'est pas pour rien, Skype balance sur le périphérique par défaut et permet de choisir dans les options si besoin par par défaut. Ah testé sur une autre machine avec un périphérique, il me demande quel périphérique utiliser, double fail), puis me demande d’optimiser moi-même à la mano le ratio latence/buffer, puis me demande de faire des tests audio (qu'est-ce qu'il m'emmerde avec ça? Skype sait s'adapter en quelques secondes lors du premier coup de fil). Ceci est certainement acceptable pour moi, mais certainement pas pour mes interlocuteurs.
- Lancé, fail : par défaut, j'ai une fenêtre de log qui me parle chinois, c'est quoi ce bordel?
- Manque la vidéo, Skype un bouton et j'ai la vidéo.
- Manque la partie texte (fenêtre de message globale, ridicule), Skype offre ça directement.
- Manque toute la partie présence, Skype offre ça.

Bref, sur ce qu'il a pour objectif (les parties de jeu en réseau avec quelques utilisateurs prêt à passer un peu de temps et connaissant un peu leur machine), il a l'air pas mal au niveau technique. Mais il est d'une techniquement et au niveau GUI pas prêt pour Mme Michu (mes contacts principaux sont des pros qui n'ont aucune envie de tester leur micro si Skype fait pareil sans test), et très mono-tache (pas de messagerie instantanée, pas possible de se connecter sur plus d'un serveur à la fois alors que Skype j'ai tout le monde Skype d'un coup car un réseau, quand on permet l’utilisateur de plusieurs réseau ben vaut mieux permettre la connexion à plusieurs réseau pour la présence, ah zut pas fait pour la présence c'est vrai, pas de vidéo)

Bref, si tu proposes Mumble pour remplacer Skype, c'est que tu n'as vraiment aucune idée du besoin rempli par Skype, ce qui fait que Skype est utilisé et est connu par beaucoup de monde.

Je serai moins idiot (bien que j'avais déjà lu Mumble ici en tant que remplaçant potentiel de Skype, ça ressort parfois), mais je ne remplacerait certainement pas Skype. Regardez un minimum ce que fait Skype avant de proposer un logiciel qui ne remplit pas le besoin, vous passez pour juste frustrés car Skype est proprio et vous passez pour des gens prêt à filer n'importe quel nom pour dire que le libre sait faire (non, il ne sait pas faire)

Les gens veulent un logiciel intégré, pas un "alors pour le besoin d'IM, il y a Pidgin, pour le besoin d'audio il y a Mumble, mais bon, faut dire aux gens de se connecter sur le même serveur que toi, vous vous donnez rendez-vous quoi, pour la vidéo attend je dois avoir un VLC dans le coin, ah oui pour chacun faut un login différent", Skype juste ça marche. Et je les comprend : pourquoi s'emmerder quand un logiciel répond au besoin? Pourquoi s'amuser à manipuler 36 trucs pas agréables? (juste parce que c'est libre? Pas suffisant). Les libristes ont un gros problème : ils ne veulent pas voir le besoin des gens, et pensent que pour mériter un truc qui marche, il faut connaitre la technique sinon on ne mérite pas. (Bon, pas tous, par exemple Firefox déchire car justement, ils ont mis l'analyse du besoin utilisateur très en avant, c'est leur priorité, quitte à faire gueuler les libristes)

En attendant, les logiciels proprios ont de beaux jours devant eux.

Combien de comptes ont besoin d'avoir un truc automatisé?