Hum à mon avis les 1.12% de "other" contiennent une bonne portion de Linux mal détectés.
Peut-être. Peut-être pas. On ne sait pas. Mais pourquoi ce serait seulement pour Linux et pas les autres OS pour toi? Pourquoi dans le sens qui t'arrangerai et pas 1.12% qui ont une bonne portion de Windows mal détectés?
Sinon il y a plus de gens qui utilisent un OS qui n'est ni Windows, Mac OS ou Linux que de gens qui utilisent Linux.
Mais ceux-la, les efforts mis pour Linux ne sont pas utiles, donc non comptabilisés pour voir si développer pour Linux est rentable.
Le décideur, lui, voit un chiffre : 0.79%. Et pour que ce soit rentable, il y a intérêt que ce 0.79% il soit vachement plus lucratif que les autres. Certes, le matos est fait, donc partageable, reste à voir si le coût de développement et de support vaut le coup... Pas facile avec un nombre si petit.
Non parce qu'il y a des gens très intelligents (bien plus que moi en tout cas) qui s'y sont penchés, et on a toujours pas de réponse.
Faut croire qu'il y en a qui ont la réponse, car ils sont sur que le programme "Webb" est utile et que l'annuler est catastrophique.
Faudrait un peu de cohérence : si pas de réponse, pas de raison que ce soit catastrophique, on peut juste dire qu'on ne sait pas.
Pourquoi m'attaquer moi car je ne sais pas et pas l'auteur du journal qui sait que c'est utile?
qu'une partie des impôts que tu payes soit allouée à des salaires de gens plutôt que dans leur indemnité de chômage.
Super argument. Bon, ben plutôt que de payer des allocation chômage, mettons tout le monde fonctionnaire à faire ce qu'il a envie, hop 0% de chômage. Désolé, mais ce genre d'argument est inacceptable, c'est juste faire l'apologie des emplois inutiles.
Sinon, pour info, mes impôts ne vont pas dans les indemnité chômage, car ils sont payés par l'assurance chômage (qui ne vient pas des impôts, c'est le paiement de l'assurance par les uns qui paye les allocations des autres)
Je serai tenté de dire que le niveau de sécurité demandé aujourd'hui n'est pas le même : combien de personnes sont mortes il y a 50 ans pour y arriver? Aujourd'hui, un mort, une explosion, et le programme s'arrête (hyper-médiatisation tout ça)
Donc plus de travaux de sécurisation à prévoir? Après, je dis ça, mais c'est seulement la seule idée qui me vient à l’esprit, d'autres trouveront sans doute de meilleurs réponses.
Tout le monde réagit "bouh le méchant qui sait pas que la recherche fondamentale c'est important", mais personne ne démontre que l'argent investit dans tout ça valait le coup par rapport à mettre cet argent dans autre chose (qui serait une recherche fondamentale, ou pas), ni que Webb vaut le coup par rapport à une autre recherche (fondamentale, ou pas).
Bref, vous mélangez une critique sur la recherche fondamentale (que je n'ai pas fait) avec ma critique de cette recherche fondamentale, précisément.
Malheureusement je crois qu'il est sérieux. (...) Bon j'avais déjà pondu un argumentaire pro-recherche à l'époque.
Pour quelqu'un qui traite Debian/kFreeBSD de jouet, ça fait sourire ;-)
Qu'est-ce qui te dit que Debian/kFreeBSD ne serait pas l'OS de killer de demain? Pourquoi es-tu d'accord pour tuer cette recherche et pas celle de Hubble/Webb (dans les deux cas, c'est un frein pour d'autres choses : systemd pour Debian, à décider de quoi faire du fric pour Webb)
Il est évident qu'annuler Hubble aurait été catastrophique,
Ah bon? ça aurait changé quelque chose dans les produits que j'utilise tous les jours pour manger, avoir un toit, ma sécurité, mes loisirs (technologique ou autre)?
C'est bien mignon tout ça, mais à part se la péter (comme pour aller sur la Lune, ça a apporté quoi de concret à part quelques images, la réputation, se faire bien voir "moi je l'ai fait" dans les dîners mondains? Parce que depuis qu'on a marché sur la lune, bizarrement on n'y est pas retourné, rien d’intéressant à faire la-bas en fait), ça reste de l'argent qui pourrait être utilisé pour d'autres choses, plus utile qui sait. L'argent n'est pas infini, et personnellement je trouve complètement acceptable de ne pas prioriser ce qu'il y a à des millions d'années lumière de chez nous, on a déjà plein de problème chez nous à régler.
Alors, oui, les scientifique vont hurler, je ne vais pas aller dans la ligne du parti, mais non, ce n'est pas catastrophique pour l'état américain, loin de là.
La France est le centre du monde? LinuxFr est limité aux français vivant en France? Il y a des français, et des francophones, ayant des élus républicains.
Tu as fait une étude de marché pour nous pondre ca ou c'est encore un énième troll a la noix a base de 99% et de 1% ?
Tu peux sérieusement oser affirmer que Linux a plus de 1% de PdM sur le desktop? va regarder les moindres stats sur les OS (tu vas quand même pas me sortir que les linuxiens font moins de net que les autres?), tu verras que Linux c'est que dalle. Déjà, ne pas accepter ce fait précis, faire semblant de ne pas savoir, ça montre la non envie de regarder la réalité en face.
Laisser la liberté de choix de l'OS, ca concerne 100% des utilisateurs,
C'est bien, tu es libre. Les autres sont aussi libres (tant qu'il n'y a pas de loi pour obliger à supporter tous les OS de la terre) de ne pas balancer de l'argent par la fenêtre pour faire plaisir à quelques rares personnes pas prêtes à payer pour leur petit plaisir. A moins que tu me dise que tu es prêt à payer de ta poche les dèv'? Si tu es prêt à payer, je n'ai rien à dire. En attendant, ce n'est pas aux utilisateur Windows de subventionner les autres OS.
Tiens, je vais me plaindre, je vais faire un OS avec un API graphique spécifique utilisé par moi-même uniquement, et vais dire que ce n'est pas normal que 100% des utilisateurs ne puisse pas avoir de driver AMD...
On en revient au commentaire initial : AMD met de l'argent dedans quand il y a un besoin, un vrai, pas celui de quelques illuminés pas prêts à y mettre le fric. Maintenant, il y en a, il met le fric.
Sans doute, mais le driver libre Intel est vraiment excellent.
Vaut-il mieux avoir un driver libre pour un matériel lent ou un driver pas libre pour un matériel rapide, euh... Perso, je choisi le driver pas libre car j'ai besoin d'avoir une carte graphique qui me permette de jouer, mais après, chacun ses priorités certes.
Si, il l'est, ou alors dit-moi de quel besoin pas nouveau tu veux parler. Ne me sort pas celui de 1% de PdM de Linux sur le desktop, ce n'était pas un besoin (pas suffisant pour rentabiliser l'investissement)
Pour info, Intel participe aux drivers libres de ses CG.
Quelles cartes graphiques? Celles que je ne peux pas acheter en retail? Celles qui font tourner des jeux, à conditions qu'ils aient plus de 5 ans? C'est un marché, oui, mais il est assez restreint. De plus, Intel est connu pour ne pas facilement permettre aux autres de coder (rétention des specs), et d'abandonner certaines cartes il me semble, tout n'est pas rose.
Sinon c'est que ta boîte te paye pour participer à un ou des projets plus ou moins libres. C'est le cas ici.
Parce qu'il y a un besoin de la part d'AMD, donc investissement pour répondre au besoin qui pourra être ensuite amorti. CQFD.
Pourquoi?
Si tu es prêt à bosser pour moi gratos, ça m’intéresse. En attendant, ben c'est normal qu'on puisse payer des gens quand on a un marché pour vendre (bref, "qu'il y a des sous à se faire"), dépenser (payer un dèv qui ne veut pas bosser gratos, le salaud) sans sous à se faire, c'est un peu idiot pour l'investisseur.
Bref, c'est normal. Libre != gratuit, libre != je code sans être payé.
0.1ms est le temps que le son met à parcourir 4cm.
Hors sujet.
Reprenons : si il te faut 0.1ms pour envoyer un paquet d'un sample et que tu attends une validation avant d’envoyer le suivant, combien de temps mettras-tu à envoyer 48 000 samples (1 secondes)? plus de 4.8 secondes suivant mes calculs, pour le temps réel c'est mort.
Donc tu dois envoyer plus d'un sample à la fois. Donc délai (buffering). Donc problème.
Problème que tu n'as pas en PCI par exemple (temps beaucoup plus court pour envoyer un paquet).
(bon, ça reste de la théorie, en pratique on envoie rarement un sample à la fois, c'est juste une démo que ça pose un problème si tu cherches à avoir un délai minimal, du temps réel, tu arrives vite à des problèmes de temps de réponse avec des périphérique USB)
Mmm... 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, donc avec XOT qui est au dessus de TCP ce sera dans l'ordre), et lui pense IP (oui, c'est dans le désordre, mais on ne parle pas de IP, on parle de TCP).
Rappel : je réagissais sur "Le protocole XOT (x25 over tcpip) est là pour faciliter les migrations." puis "Oui, enfin sauf que l'ordre d'arrivée des paquets n'est pas garantie, ni leur unicité.". Si les XOT se base sur TCP, ben il ne m'a toujours pas expliqué comment ça pouvait être dans le désordre, il se borne à parler d'IP (et comme XOT est indiqué comme au dessus de TCP, je m'en fou d'IP, c'est le problème de TCP).
Donc ma question est toujours : comment XOT peut être dans le désordre si ça se base sur TCP? Bizarrement, la réponse est pas sur ça, mais sur IP la couche dont on se fout complet pour l'ordre et l'unicité. J'attend toujours une réponse compréhensible.
Au niveau TCP (IP ou autre chose) la couche de transport ne garantie pas l'ordre ni la non duplication des paquets.
Je te cites : "et ils seront remis dans le bon ordre par TCP"
Faudrait savoir.
Et si cette cohérence n'est pas respectée, on reprend tout depuis l'erreur. (ie si le paquet 5 arrive avant le paquet 4 il faut réemettre les paquets 4, 5, 6 etc...
Et? Ce qui compte c'est qu'à la fin j'ai mes données dans l'ordre sans duplication. Et je l'ai tant que tu me démontres pas le contraire (ce qui va être dur car j'ai déjà dit que je transmet des paquets par milliards dans l'ordre et non dupliqué).
Donc si on a besoin d'une synchro x25 fait 95% du boulot, TCP 0%.
Je veux bien te croire. Mais ça n'a pas grand chose à voir avec l'ordre ni la non duplication. Tu ne m'as toujours pas démontré pour l'ordre et la non duplication, c'est ça dont on parle! La synchro n'est pas dans la demande de démonstration, je te demande de me démontrer comment on fait pour avoir des données dans le désordre avec TCP, ce que tu n'as toujours pas démontré (ou alors oui, je suis bête au point de ne pas comprendre... Mais continuerai à vivre avec mes données dans l'ordre et non dupliquées en TCP)
Il ne relève plus de la catégorie des trucs marrants qu'on fait parce qu'on en a envie et qui n'ont pas de conséquences. Cela devient une contrainte pour tout le reste.
La compatibilité des matériels avec Linux ne relève plus de la catégorie des trucs marrants qu'on fait parce qu'on en a envie et qui n'ont pas de conséquences. Cela devient une contrainte pour tout le reste (faut prendre en compte les spécificité de cet OS, c'est chiant)
Tu bondis? C'est exactement ce que tu dis à propose de Debian/kFreeBSD.
Comme quoi, ne rien avoir à faire des petits hobby (Linux il y a 20 ans, c'était un truc marrant qu'on fait parce qu'on a envie!) n'est pas le monopole des utilisateurs de Windows ;-).
Je vois : en gros tu vires la couche TCP qui fait le boulot d'unicité et d'ordre d'arrivée, et après tu dis "l'ordre d'arrivée des paquets n'est pas garantie, ni leur unicité." quand on parle de TCP/IP, euh... Désolé, mais non, c'est pas comme ça qu'on regarde un protocole et qu'on dit qu'il y a un ordre ou une unicité, on ne vire pas une couche comme on a envie, TCP fait partie de la règle du jeu, et
"p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2"
arrive bien comme ça :
"p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2"
de l'autre côté.
Qu'il y a un désordre au niveau IP, oui c'est connu (mais on s'en fou, on a TCP, c'est son objet même)
qu'il y ai une latence, oui, c'est connu.
Mais dans le cas d'une transmission SEPA, on s'en fout de la latence non? Alors certes X25 mais surtout ATM (grace aux contrats) vont encore exister pour des cas hyper mega spécifiques, mais le fait que TCP/IP ne t'offre pas une garantie de latence ne te permet pas d'affirmer que l'ordre et l'unicité ne sont pas gérés par TCP/IP : ils le sont.
Tout ce que ça te permet de dire est qu'il y a des problèmes de latence avec TCP/IP, du fait de la couche qui va bien pour réordonner le bazar en dessous (bazar qui n'existe pas avec X25 donc plus de latence introduite par TCP/IP, on est d'accord sur ce point je pense)
Bon, j'ai été un peu méchant avec la latence USB2, elle est à 0.1 ms :
quand même. Loin des 0.005ms du PCI-E toutefois, ça ne permet pas d'envoyer 48000 paquets acquittés par seconde ;-).
Je dois être idiot, mais le lien que tu me files dit justement que ce sera dans l'ordre. Alors, certes, tu peux envoyer 2^32 paquets et la j'aurai un problème, mais ça se voit légèrement si 2^32 paquets sont perdus.
"Grâce aux numéros de séquence et d'acquittement, les systèmes terminaux peuvent remettre les données reçues dans l'ordre à l'application destinataire."
C'est ton lien. Dans l'ordre.
Oui, je suis idiot, mais j'ai besoin d'une meilleure argumentation, car les Terra-octets transmis par moi-même ont toujours été dans l'ordre en TCP.
Sinon ta comparaison usb est foireuse : il l'usb high speed tu peux faire passé de la vidéo non compressé (le débit théorique est autour de 480Mbps).
Relit STP avant de poster. Le débit, c'est pas un problème. Le problème est la latence (si tu me trouves une latence <20 ms en USB, bravo), la capacité à traiter des paquets. 10 paquets de 1 000 000 octets par seconde, ça passe, 1 000 000 paquets de 10 octets je demande à voir en USB. Et plus tu as besoin d'une faible latence, plus il te faut un nombre de paquets par seconde acceptable.
Pareil pour une Sound Blaster, c'est mignon les sound blaster, mais tu compares de choux et des carottes : les "voix" de la Sound Blaster ne sont pas les canaux (je demande à voir une Sound Blaster à 8 canaux, je suis resté à 2 dans ce que j'ai vu, et en 16-bits maxi). Et surtout, ça coûtait 3€ la SB? (prix d'une sortie audio 8 canaux aujourd'hui)?
Ne te base pas sur les vielles technos pour comparer, tu te trompes dans la comparaison (le débit en octets par seconde, l'audio n'en a rien à faire, ce qui l’intéresse est le nombre de paquets par seconde et la latence).
Pour pousser, imagine juste une connexion Internet capable de balancer 1 Go par seconde, mais que 1 paquet (de 60 Go) par minute. Avec ton raisonnement, 1 Go par seconde c'est génial, mais moi je ne veux pas attendre 1 minute avant d'afficher une page web sans image (1er paquet), puis 1 autre minute pour la moindre image (2ème paquet). Le débit de ta connexion Internet ne fait pas tout.
Non, TCP te garantie que les paquets seront remis dans l'ordre au final.
Re-gni???
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Network_function
"Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the application program. Thus, TCP abstracts the application's communication from the underlying networking details."
Je ne comprend toujours pas : syncronizer, gérer les pertes de paquets, les doublons, c'est justement le boulot de TCP. Et vu les Terra-octets de connexions TCP qui se passent dans le monde en garantissant que ce sera dans l'ordre (comme par exemple LinuxFr en HTTP(S), imagine que ce soit dans le désordre...), je me permet de mettre en doute ton assertion. TCP c'est du FIFO, je demande une démo que ce n'est pas du FIFO (j'ouvre une connexion, j'envoie un octet A puis un octet B, je veux donc une démo que de l'autre côté il peut recevoir B avant A)
[^] # Re: L'argent
Posté par Zenitram (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à -1.
Peut-être. Peut-être pas. On ne sait pas. Mais pourquoi ce serait seulement pour Linux et pas les autres OS pour toi? Pourquoi dans le sens qui t'arrangerai et pas 1.12% qui ont une bonne portion de Windows mal détectés?
Mais ceux-la, les efforts mis pour Linux ne sont pas utiles, donc non comptabilisés pour voir si développer pour Linux est rentable.
Le décideur, lui, voit un chiffre : 0.79%. Et pour que ce soit rentable, il y a intérêt que ce 0.79% il soit vachement plus lucratif que les autres. Certes, le matos est fait, donc partageable, reste à voir si le coût de développement et de support vaut le coup... Pas facile avec un nombre si petit.
[^] # Re: Il est évident qu'annuler Hubble aurait été catastrophique,
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à -2.
Faut croire qu'il y en a qui ont la réponse, car ils sont sur que le programme "Webb" est utile et que l'annuler est catastrophique.
Faudrait un peu de cohérence : si pas de réponse, pas de raison que ce soit catastrophique, on peut juste dire qu'on ne sait pas.
Pourquoi m'attaquer moi car je ne sais pas et pas l'auteur du journal qui sait que c'est utile?
[^] # Re: Il est évident qu'annuler Hubble aurait été catastrophique,
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à 0.
Je ne sais pas chez toi, mais moi c'est dans la partie "mes loisirs". ;-)
(c'est d'ailleurs bien pour ça que ça marche)
[^] # Re: L'argent
Posté par Zenitram (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à -2.
http://gs.statcounter.com/#os-ww-monthly-201006-201106
J'ai été trop gentil : 0.79%.
[^] # Re: EBICS
Posté par Zenitram (site web personnel) . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 4.
C'est si compliqué d'aller sur le site adéquat (je t'aide : http://www.ebics.org ) et de récupérer les specs? (je t'aide : http://www.ebics.org/index.php?id=30 ).
Ca a l'air plus compliqué que de FUDer pour le plaisir, ça devient un mensonge à partir d'un moment.
Ah, parait que ça a déjà été dit :
https://linuxfr.org/nodes/86690/comments/1249831
(premier commentaire du journal!)
[^] # Re: Il est évident qu'annuler Hubble aurait été catastrophique,
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à -3.
Super argument. Bon, ben plutôt que de payer des allocation chômage, mettons tout le monde fonctionnaire à faire ce qu'il a envie, hop 0% de chômage. Désolé, mais ce genre d'argument est inacceptable, c'est juste faire l'apologie des emplois inutiles.
Sinon, pour info, mes impôts ne vont pas dans les indemnité chômage, car ils sont payés par l'assurance chômage (qui ne vient pas des impôts, c'est le paiement de l'assurance par les uns qui paye les allocations des autres)
[^] # Re: HS
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à 1.
Je serai tenté de dire que le niveau de sécurité demandé aujourd'hui n'est pas le même : combien de personnes sont mortes il y a 50 ans pour y arriver? Aujourd'hui, un mort, une explosion, et le programme s'arrête (hyper-médiatisation tout ça)
Donc plus de travaux de sécurisation à prévoir? Après, je dis ça, mais c'est seulement la seule idée qui me vient à l’esprit, d'autres trouveront sans doute de meilleurs réponses.
[^] # Re: Il est évident qu'annuler Hubble aurait été catastrophique,
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à 4.
Tout le monde réagit "bouh le méchant qui sait pas que la recherche fondamentale c'est important", mais personne ne démontre que l'argent investit dans tout ça valait le coup par rapport à mettre cet argent dans autre chose (qui serait une recherche fondamentale, ou pas), ni que Webb vaut le coup par rapport à une autre recherche (fondamentale, ou pas).
Bref, vous mélangez une critique sur la recherche fondamentale (que je n'ai pas fait) avec ma critique de cette recherche fondamentale, précisément.
[^] # Re: Il est évident qu'annuler Hubble aurait été catastrophique,
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à 1.
Pour quelqu'un qui traite Debian/kFreeBSD de jouet, ça fait sourire ;-)
Qu'est-ce qui te dit que Debian/kFreeBSD ne serait pas l'OS de killer de demain? Pourquoi es-tu d'accord pour tuer cette recherche et pas celle de Hubble/Webb (dans les deux cas, c'est un frein pour d'autres choses : systemd pour Debian, à décider de quoi faire du fric pour Webb)
# Il est évident qu'annuler Hubble aurait été catastrophique,
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à -10.
Ah bon? ça aurait changé quelque chose dans les produits que j'utilise tous les jours pour manger, avoir un toit, ma sécurité, mes loisirs (technologique ou autre)?
C'est bien mignon tout ça, mais à part se la péter (comme pour aller sur la Lune, ça a apporté quoi de concret à part quelques images, la réputation, se faire bien voir "moi je l'ai fait" dans les dîners mondains? Parce que depuis qu'on a marché sur la lune, bizarrement on n'y est pas retourné, rien d’intéressant à faire la-bas en fait), ça reste de l'argent qui pourrait être utilisé pour d'autres choses, plus utile qui sait. L'argent n'est pas infini, et personnellement je trouve complètement acceptable de ne pas prioriser ce qu'il y a à des millions d'années lumière de chez nous, on a déjà plein de problème chez nous à régler.
Alors, oui, les scientifique vont hurler, je ne vais pas aller dans la ligne du parti, mais non, ce n'est pas catastrophique pour l'état américain, loin de là.
[^] # Re: Nos ?
Posté par Zenitram (site web personnel) . En réponse au journal Les élus républicains tuent le successeur de Hubble. Évalué à -3.
La France est le centre du monde? LinuxFr est limité aux français vivant en France? Il y a des français, et des francophones, ayant des élus républicains.
[^] # Re: L'argent
Posté par Zenitram (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à -1.
Tu peux sérieusement oser affirmer que Linux a plus de 1% de PdM sur le desktop? va regarder les moindres stats sur les OS (tu vas quand même pas me sortir que les linuxiens font moins de net que les autres?), tu verras que Linux c'est que dalle. Déjà, ne pas accepter ce fait précis, faire semblant de ne pas savoir, ça montre la non envie de regarder la réalité en face.
C'est bien, tu es libre. Les autres sont aussi libres (tant qu'il n'y a pas de loi pour obliger à supporter tous les OS de la terre) de ne pas balancer de l'argent par la fenêtre pour faire plaisir à quelques rares personnes pas prêtes à payer pour leur petit plaisir. A moins que tu me dise que tu es prêt à payer de ta poche les dèv'? Si tu es prêt à payer, je n'ai rien à dire. En attendant, ce n'est pas aux utilisateur Windows de subventionner les autres OS.
Tiens, je vais me plaindre, je vais faire un OS avec un API graphique spécifique utilisé par moi-même uniquement, et vais dire que ce n'est pas normal que 100% des utilisateurs ne puisse pas avoir de driver AMD...
On en revient au commentaire initial : AMD met de l'argent dedans quand il y a un besoin, un vrai, pas celui de quelques illuminés pas prêts à y mettre le fric. Maintenant, il y en a, il met le fric.
[^] # Re: L'argent
Posté par Zenitram (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 0.
Vaut-il mieux avoir un driver libre pour un matériel lent ou un driver pas libre pour un matériel rapide, euh... Perso, je choisi le driver pas libre car j'ai besoin d'avoir une carte graphique qui me permette de jouer, mais après, chacun ses priorités certes.
[^] # Re: L'argent
Posté par Zenitram (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 0.
Si, il l'est, ou alors dit-moi de quel besoin pas nouveau tu veux parler. Ne me sort pas celui de 1% de PdM de Linux sur le desktop, ce n'était pas un besoin (pas suffisant pour rentabiliser l'investissement)
Quelles cartes graphiques? Celles que je ne peux pas acheter en retail? Celles qui font tourner des jeux, à conditions qu'ils aient plus de 5 ans? C'est un marché, oui, mais il est assez restreint. De plus, Intel est connu pour ne pas facilement permettre aux autres de coder (rétention des specs), et d'abandonner certaines cartes il me semble, tout n'est pas rose.
Parce qu'il y a un besoin de la part d'AMD, donc investissement pour répondre au besoin qui pourra être ensuite amorti. CQFD.
[^] # Re: À l'heure actuelle ?
Posté par Zenitram (site web personnel) . En réponse au journal Qt ? GTK+ ?.... Évalué à 6.
D'une tu n'es pas obligé de les utiliser, et de deux tu peux très bien utiliser le réseau de Qt et l'UI de GTK si tu as envie.
Bref, tu as le choix.
[^] # Re: L'argent
Posté par Zenitram (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 10.
Pourquoi?
Si tu es prêt à bosser pour moi gratos, ça m’intéresse. En attendant, ben c'est normal qu'on puisse payer des gens quand on a un marché pour vendre (bref, "qu'il y a des sous à se faire"), dépenser (payer un dèv qui ne veut pas bosser gratos, le salaud) sans sous à se faire, c'est un peu idiot pour l'investisseur.
Bref, c'est normal. Libre != gratuit, libre != je code sans être payé.
[^] # Re: quel est le besoin en matière de son?
Posté par Zenitram (site web personnel) . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 4.
Hors sujet.
Reprenons : si il te faut 0.1ms pour envoyer un paquet d'un sample et que tu attends une validation avant d’envoyer le suivant, combien de temps mettras-tu à envoyer 48 000 samples (1 secondes)? plus de 4.8 secondes suivant mes calculs, pour le temps réel c'est mort.
Donc tu dois envoyer plus d'un sample à la fois. Donc délai (buffering). Donc problème.
Problème que tu n'as pas en PCI par exemple (temps beaucoup plus court pour envoyer un paquet).
(bon, ça reste de la théorie, en pratique on envoie rarement un sample à la fois, c'est juste une démo que ça pose un problème si tu cherches à avoir un délai minimal, du temps réel, tu arrives vite à des problèmes de temps de réponse avec des périphérique USB)
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 4.
Mmm... 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, donc avec XOT qui est au dessus de TCP ce sera dans l'ordre), et lui pense IP (oui, c'est dans le désordre, mais on ne parle pas de IP, on parle de TCP).
Rappel : je réagissais sur "Le protocole XOT (x25 over tcpip) est là pour faciliter les migrations." puis "Oui, enfin sauf que l'ordre d'arrivée des paquets n'est pas garantie, ni leur unicité.". Si les XOT se base sur TCP, ben il ne m'a toujours pas expliqué comment ça pouvait être dans le désordre, il se borne à parler d'IP (et comme XOT est indiqué comme au dessus de TCP, je m'en fou d'IP, c'est le problème de TCP).
Donc ma question est toujours : comment XOT peut être dans le désordre si ça se base sur TCP? Bizarrement, la réponse est pas sur ça, mais sur IP la couche dont on se fout complet pour l'ordre et l'unicité. J'attend toujours une réponse compréhensible.
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 3.
Je te cites : "et ils seront remis dans le bon ordre par TCP"
Faudrait savoir.
Et? Ce qui compte c'est qu'à la fin j'ai mes données dans l'ordre sans duplication. Et je l'ai tant que tu me démontres pas le contraire (ce qui va être dur car j'ai déjà dit que je transmet des paquets par milliards dans l'ordre et non dupliqué).
Je veux bien te croire. Mais ça n'a pas grand chose à voir avec l'ordre ni la non duplication. Tu ne m'as toujours pas démontré pour l'ordre et la non duplication, c'est ça dont on parle! La synchro n'est pas dans la demande de démonstration, je te demande de me démontrer comment on fait pour avoir des données dans le désordre avec TCP, ce que tu n'as toujours pas démontré (ou alors oui, je suis bête au point de ne pas comprendre... Mais continuerai à vivre avec mes données dans l'ordre et non dupliquées en TCP)
[^] # Re: toy OS
Posté par Zenitram (site web personnel) . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 3.
La compatibilité des matériels avec Linux ne relève plus de la catégorie des trucs marrants qu'on fait parce qu'on en a envie et qui n'ont pas de conséquences. Cela devient une contrainte pour tout le reste (faut prendre en compte les spécificité de cet OS, c'est chiant)
Tu bondis? C'est exactement ce que tu dis à propose de Debian/kFreeBSD.
Comme quoi, ne rien avoir à faire des petits hobby (Linux il y a 20 ans, c'était un truc marrant qu'on fait parce qu'on a envie!) n'est pas le monopole des utilisateurs de Windows ;-).
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 6.
Je vois : en gros tu vires la couche TCP qui fait le boulot d'unicité et d'ordre d'arrivée, et après tu dis "l'ordre d'arrivée des paquets n'est pas garantie, ni leur unicité." quand on parle de TCP/IP, euh... Désolé, mais non, c'est pas comme ça qu'on regarde un protocole et qu'on dit qu'il y a un ordre ou une unicité, on ne vire pas une couche comme on a envie, TCP fait partie de la règle du jeu, et
"p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2"
arrive bien comme ça :
"p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2"
de l'autre côté.
Qu'il y a un désordre au niveau IP, oui c'est connu (mais on s'en fou, on a TCP, c'est son objet même)
qu'il y ai une latence, oui, c'est connu.
Mais dans le cas d'une transmission SEPA, on s'en fout de la latence non? Alors certes X25 mais surtout ATM (grace aux contrats) vont encore exister pour des cas hyper mega spécifiques, mais le fait que TCP/IP ne t'offre pas une garantie de latence ne te permet pas d'affirmer que l'ordre et l'unicité ne sont pas gérés par TCP/IP : ils le sont.
Tout ce que ça te permet de dire est qu'il y a des problèmes de latence avec TCP/IP, du fait de la couche qui va bien pour réordonner le bazar en dessous (bazar qui n'existe pas avec X25 donc plus de latence introduite par TCP/IP, on est d'accord sur ce point je pense)
[^] # Re: quel est le besoin en matière de son?
Posté par Zenitram (site web personnel) . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 5.
Bon, j'ai été un peu méchant avec la latence USB2, elle est à 0.1 ms :
quand même. Loin des 0.005ms du PCI-E toutefois, ça ne permet pas d'envoyer 48000 paquets acquittés par seconde ;-).
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 3.
Je dois être idiot, mais le lien que tu me files dit justement que ce sera dans l'ordre. Alors, certes, tu peux envoyer 2^32 paquets et la j'aurai un problème, mais ça se voit légèrement si 2^32 paquets sont perdus.
"Grâce aux numéros de séquence et d'acquittement, les systèmes terminaux peuvent remettre les données reçues dans l'ordre à l'application destinataire."
C'est ton lien. Dans l'ordre.
Oui, je suis idiot, mais j'ai besoin d'une meilleure argumentation, car les Terra-octets transmis par moi-même ont toujours été dans l'ordre en TCP.
[^] # Re: quel est le besoin en matière de son?
Posté par Zenitram (site web personnel) . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
Relit STP avant de poster. Le débit, c'est pas un problème. Le problème est la latence (si tu me trouves une latence <20 ms en USB, bravo), la capacité à traiter des paquets. 10 paquets de 1 000 000 octets par seconde, ça passe, 1 000 000 paquets de 10 octets je demande à voir en USB. Et plus tu as besoin d'une faible latence, plus il te faut un nombre de paquets par seconde acceptable.
Pareil pour une Sound Blaster, c'est mignon les sound blaster, mais tu compares de choux et des carottes : les "voix" de la Sound Blaster ne sont pas les canaux (je demande à voir une Sound Blaster à 8 canaux, je suis resté à 2 dans ce que j'ai vu, et en 16-bits maxi). Et surtout, ça coûtait 3€ la SB? (prix d'une sortie audio 8 canaux aujourd'hui)?
Ne te base pas sur les vielles technos pour comparer, tu te trompes dans la comparaison (le débit en octets par seconde, l'audio n'en a rien à faire, ce qui l’intéresse est le nombre de paquets par seconde et la latence).
Pour pousser, imagine juste une connexion Internet capable de balancer 1 Go par seconde, mais que 1 paquet (de 60 Go) par minute. Avec ton raisonnement, 1 Go par seconde c'est génial, mais moi je ne veux pas attendre 1 minute avant d'afficher une page web sans image (1er paquet), puis 1 autre minute pour la moindre image (2ème paquet). Le débit de ta connexion Internet ne fait pas tout.
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . En réponse au journal Transmissions bancaires : toujours pas dans un format ouvert, et encore plus cher !. Évalué à 4.
Re-gni???
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Network_function
"Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the application program. Thus, TCP abstracts the application's communication from the underlying networking details."
Je ne comprend toujours pas : syncronizer, gérer les pertes de paquets, les doublons, c'est justement le boulot de TCP. Et vu les Terra-octets de connexions TCP qui se passent dans le monde en garantissant que ce sera dans l'ordre (comme par exemple LinuxFr en HTTP(S), imagine que ce soit dans le désordre...), je me permet de mettre en doute ton assertion. TCP c'est du FIFO, je demande une démo que ce n'est pas du FIFO (j'ouvre une connexion, j'envoie un octet A puis un octet B, je veux donc une démo que de l'autre côté il peut recevoir B avant A)