Ce programme était-il diffusé? Si oui, c'est une autre histoire, la GPL répond à ce problème.
Mais si ce programme était utilisé que en interne, comme de plus en plus de projets "web service" (genre... Un serveur SMTP, exemple pris par l'auteur), pourquoi aurais-tu acheté une licence qui ne change rien? Quel "utilité" apporté par la GPL par rapport à la BSD qui t'aurais poussé à acheter? rien.
La GPL répond au besoin que dans un cas qui devient de plus en plus minoritaire, l'AGPL pourrait la remplacer alors mais elle ne fait pas l'humanité comme la GPL...
la GPL est souvent utilisée pour de mauvaises raisons.
Trop facile.
La GPL est faite pour lutter contre le propriétaire. C'est une licence de combat ou d'évangélisation.
Non. Elle est ce qu'on en fait, rien de plus.
Linus T., moi ;-), n'avons rien à faire de l'évangélisation. On fait parce que c'est la meilleure licence pour faire le meilleur logiciel (et en bonus, en vivre).
On laisse le combat ou l'évangélisation à d'autres.
Ne fait pas de la GPL ce qu'elle n'est pas : c'est un outil, c'est tout. Certains l'utilisent pour le combat ou l'évangélisation, d'autres pour d'autres choses.
En moyenne j'ai précisé, pas la peine de me sortir 2 contre-exemples, car il y a des centaines d'exemples positifs.
Ben si, j'ai sorti que 2 exemples, mais il y a plein de monde qui font de la GPL pour d'autres choses que ce que toi tu veux en faire. "En moyenne"? Tu as une démonstration que la moyenne est pour l'évangélisation? Personnellement, je ne crois absolument pas que la vision de Stallman est celle des la moyenne des développeurs du libre. Que la moyenne de ceux qui trollent, c'est possible, que ceux qui développent, la majorité silencieuse, j'ai un gros doute.
Moi je comprends qu'il a un problème, non pas avec l'utilisateur final, mais plutôt avec l'industrie informatique en général.
Euh... Dans le cas d'un serveur SMTP par exemple, l'industrie informatique en général est l'utilisateur final
S'il développe du code utile sous une licence trop permissive, celui-ci peut être réutilisé de manière silencieuse par l'industrie informatique.
De la même manière qu'une serveur SMTP en GPL : la GPL n'empêche pas d'utiliser le serveur SMTP de manière silencieuse (sans le dire aux clients)
Avec du code sous GPL, l'entreprise qui réutilise son code est obligée de le reconnaître (en interne), ce qui pourrait l'inciter à travailler avec l'auteur (achat de licence, consulting...).
En quoi le fait qu'il ne soit pas en BSD change ça?
Si quelqu'un a un besoin, il va remonter à l'origine pour en demander le développement. La licence BSD ou GPL ne change rien.
Si le code sous GPL ne règle pas le problème de reconnaissance de la part du public, est-ce qu'il ne permet pas d'ouvrir des opportunités commerciales ?
Toutes les opportunités commerciale que j'ai eu sont parce que je suis le plus expert sur mon logiciel (logique ;-) ) pour faire un développement.
La licence n'a pas changé grand chose...
BSD ou GPL, pour les logiciels utilisés en interne, ça ne change pas grand chose... Surtout qu'en interne, celui qui reçoit le code ne va pas attaquer en justice son collègue si le code n'est pas fourni.
Tu es exactement dans ce qu'il critique, et pour le paraphraser : tu préfèrerais à la limite ne pas utiliser son logiciel, plutôt que de te trouver dans une situation où tu l’utilises et que tu doives l'admettre.
Des personnes comme toi, les développeurs du libre n'en ont pas besoin, bon vent, ça ne changera rien dans la vie du développeur du libre.
L'argumentation se tient, mais se heurte à un gros problème : la GPL ne résout pas son problème.
En effet, de plus en plus de logiciels sont utilisés en interne, on peut prendre un gros exemple : Google. Combien de code GPL adaptent-ils mais ne livrent rien à la communauté parce que la GPL ne les obligent pas?
La GPL résout le problème pour les logiciels distribués, mais qui deviennent de plus en plus rare, web service oblige.
Est-ce que l'AGPL va prendre plus de place alors? Rien n'est moins sûr...
Bref, ce n'est pas parce qu'on fait de la GPL que ça va changer quelque chose, surtout dans son exemple (un serveur SMTP? Utilisé en interne, pas besoin de diffuser les modifs ou dire qu'on l'utilise).
La problématique est la bonne (j'ai exactement le même problème dans mon entreprise : je suis à plein d'endroits sympa, mais les entreprises ne veulent pas le dire), mais la GPL n'y répond pas (je suis en GPL, ça n'empêche pas les entreprises de ne rien dire). Je cherche encore la bonne réponse (mettre en AGPL? Malheureusement, je perdrai plus de client payeurs potentiels que je gagnerai, car l'AGPL n'est pas acceptée facilement comme référence, c'est aussi un problème)
Arghhh... Si ils avaient ça officiellement sur leur site constructeur, supporté officiellement par le constructeur, ben ils auraient gagné une vente...
Si c'est utilisable au moment de l'achat dans TES conditions, alors c'est bon.
Mon pb est que dans mes conditions (pilote officiel libre + pas cher), ben il n'y avait pas.
Après, on priorise... Étant encore sous Windows, j'aurai pu aussi prioriser le prix et prendre une imprimante Windows-only, bon je ne suis pas allé jusqu'à la, mais d'autres le font sans doute.
Bref, tout ça pour dire que c'est loin d'être simple, et qu'on ne trouve pas forcement chaussure à son pied.
(et encore je suis pas sur que la connexion data soit ouverte dès le début)
Non, puisqu'ils négocient le port lors du dialogue.
Tu oublie pas mal d'échanges en FTP...
plusieurs secondes pour ça me parait aberrant
Plusieurs secondes, c'est peut-être beaucoup.
Mais dans le genre 5x plus lent que HTTP, sans aucun doute.
Pense aux aller-retour login/pass inutiles, allez je suis gentil je te fais un listing :
Connexion
USER
réponse
PASS
réponse
TYPE I
réponse
PASV
réponse
RETR
réponse avec adresse/port passif
2ème connexion
transfert
en HTTP :
Connexion
GET blabla en 1 fois
réponse + transfert en une fois
Et après tu oses dire que FTP est simple, rapide???
FTP permet de faire du transfert de fichier de manière simple,
Non (cf Firewall, NAT, Ca casse pas mal la simplicité)
et avec peu d'overhead
Non dans 99.999% des cas (celui d'un download de fichier unique), FTP a 2-3 fois plus d'overhead que HTTP (compte les connexion TCP, la couche IP...). Dire que FTP consomme moins de BP/CPU, c'est un peu rigolo...
alors pourquoi s'en passer ?
Parce qu'il ne convient pas dans 99.999% des cas.
Non, on ne peut pas s'en passer quand on est développer/uploader/échange de plusieurs fichiers, je l'utilise moi-même tous les jours (FTP/SFTP), mais je suis réaliste : c'est pour un besoin précis.
Pour transférer un fichier de manière simple dont on a l'URL, soit 99.999% des demandes, FTP est une horreur que ce soit en connexion, overhead, simplicité etc...
C'est effectivement certainement pas un hasard si les uploaders (0.001% des utilisateurs) utilisent FTP pour l'upload mais que les admins ont mis une surcouche HTTP pour les downloaders (99.999% des autres utilisateurs) pour le download.
Arrête, tu t'enfonces... FTP est bien pour l'upload, mais reste pourri pour le download, quoique tu cherches à inventer quand on te met le nez dedans.
HTTP n'apporte rien par rapport a son surcout BP/CPU dans ce cas
Surcout que tu n'arrives pas à prouver, les exemples que tu donnes étant en faveur de HTTP... Mais bon, si tu veux absolument croire qu'un protocole qui ouvre deux ports est moins consommateur qu'un protocole qui ouvre un port... (sans parler de la simplicité de mise en œuvre, firewall, NAT... non, c'est vrai quoi, HTTP n'apporte rien, sauf des avantages que tu refuses de lire)
Je crois que je me suis mal fait comprendre : je demandais pourquoi il voulait que Setup ne gère pas HTTP alors que ça ne lui coûte rien de le supporter. C'est tout l'avantage d'avoir choisit QtNetwork (bon, même si pour juste le besoin de réseau, libcurl aurait suffit, mais quitte à utiliser QtCore pour le reste, QtNetwork était évident)
Y'a pas de header dans ftp, une fois la connexion ouverte,
Tu peux me dire comment tu fais du FTP avec une connexion, ça m'interesse.
Je ne sais pas faire avec moins de 2.
Et entre la fourniture de PASV, 2 init TCP, et j'en passe, l'overhead FTP est énorme par rapport à HTTP... Ne parlons même pas du temps de réponse avec ces commandes et ouvertures de port séquentielles
FTP, c'est pourri pour un transfert de fichier public!
Je vois pas pourquoi tu n'aurais pas accès à la documentation de sa carte graphique qu'il a acheté avec son argent.
Parce que l'acheteur, il veut le moins cher, et que dans 99.9% des cas il s'en fout de la documentation. Comme la documentation publique (une documentation interne n'a pas un niveau de qualité pour être publique comme ça) ça coûte cher à faire, et que le consommateur s'en fout, on limite les coûts --> Pas de doc.
Après c'est deux vues économiques qui s'opposent : les libéraux et les conservateurs
Certainement pas. C'est uniquement une histoire d'argent : si la doc publique rapporte plus d'argent que pas de doc, la doc sera fournie.
Il ne te reste plus qu'à faire le nécessaire pour que ce soit le cas, car aujourd'hui faire une doc publique coûte beaucoup et ne rapporte presque rien.
Autre possibilité : faire une loi pour que la doc soit obligatoire. De ce côté, ce n'est pas gagné non plus.
Les gens qui se sont jetés dessus sont les geeks de la première heure.
Il y a plus de geeks Windows 7 que de linuxiens toute population confondue : Avant son lancement, Win7 (piraté donc...) avait entre 2 et 5% de PPM, contre 1 à 2 % de PPM pour Linux toutes versions...
Il n'y a pas à dire, les Linuxiens sont en très forte minorité, derrière les geeks de la première heure Windowsien... Alors ça ne fait pas vraiment le poid devant un constructeur pour lui demander sa doc, très très loin.
– pouvoir avoir des pilotes libres pour exploiter le matériel.
Donc tu ne t'en fous pas des part de marché, car la réalité est méchante : seules les parts de marché comptent pour ça.
Fournir un matériel non documenté ça ne devrais même pas exister,
Si tu es prêt à payer pour cette doc... Bizarrement, quand il faut passer à la caisse, il n'y a plus grand monde.
Une doc publique, ça coûte de l'argent, il faut que le constructeur y voit un intérêt, et avec 1% de part de marché à gagner, il s'en fout.
Et on revient à la case "part de marché".
Ta théorie est belle "je veux", il y a la réalité du monde d'aujourd'hui : ton "tu veux", on s'en fout, on le fera que si il y a une part de marché.
Donc si tu veux ton "je veux", ben il faut faire le nécessaire...
Les windowsiens ont une myriade de logiciels appelés "Download managers" pour gérer même avec des sources multiples (le même fichier sur 10 URL en HTTP différentes, et hop c'est parti). Très pratique au début de l'ADSL lorsque le débit du client était plus gros que le débit du serveur. Ton proz -k=10 fait petit joueur à côté.
Un player Youtube (par exemple) peut faire un seek dans une vidéo qui n'a pas fini de télécharger, tu penses qu'il peut faire comment?
Bref, oui, ça peut, c'est utilisé depuis plus de 10 ans par des centaines de logiciels. HTTP est très fort, et il ne reste pas grand chose à FTP (listing de répertoires, upload... Et encore, on peut uploader en HTTP aussi) qui se traine de grosses casseroles (2 connexions dont parfois une dans l'autre sens que l'initialisation etc...)
Je te retourne la question : quelle est l'avantage du HTTP par rapport au FTP ?
Tu prends le message précédent, tu lis les inconvénients donnés au FTP, et hop tu as les avantage de HTTP par déduction, s'est-il pas beau?
Plus sérieusement, HTTP est tellement plus simple pour faire du transfert de fichier que FTP (qui malgré son nom, ne rend pas le transfert de fichier simple) que quand on réfléchi à implémenter, on voit rapidement qu'il faut plus de temps pour FTP, et quand on teste FTP a grande échelle on s'aperçoit que c'est une horreur sans nom (firewall, NAT etc...)
Mais ici, pour bâcher un peu tout le monde, pourquoi ne pas proposer FTP en plus de HTTP? Qui peut le plus peut le moins, et Qt offre une manière transparente de gérer les 2 protocoles.
J'ai du coup préféré prendre Samsung.
HP est loin d'être parfait (aucun support officiel), Samsung non plus (binaires), ce n'est pas aussi simple que tu le dis de choisir une imprimante.
De cœur uniquement, et le cul entre les deux pays.
Disons qu'au niveau politique, même si j'ai encore la barrière de la langue, je note que les politiques ne sont pas des rois, ils ne sont pas adulés comme en France, il font juste un métier. Même si ça n'empêche pas tous les dérapages (loi style HADOPI mais en plus fort qui a failli passé mais passé à la trappe merci les élections, président de la banque centrale qui dit que les turcs sont juste bon à vendre des fruits et légumes etc...)
Ah la manie française de vouloir des rois aux pleins pouvoirs aussi... Et personne pour assumer et dire "'j'ai voté pour lui"
D'un coté, il y a HP, qui fournit les docs et participe activement au développement des drivers pour Linux. Ça nous donne HPLIP et autre projets qui permettent d'utiliser pleinement leurs imprimantes et autres multifonctions.
Et il y en a une de chez HP qui m'intéressait, mais c'était bien écrit sur la boite : "Windows only".
J'estime qu'aujourd'hui il y a suffisamment de sources d'information pour choisir du matériel pour ne pas aller s'emmerder avec du matos non supporté, et ensuite se plaindre que son imprimante ne fonctionne pas sous Linux.
Malheureusement, la réalité est loin d'être aussi idyllique... Même chez HP, la marque d'imprimante avec le plus de matériel compatible, les imprimantes "intéressantes" pour certains ne sont pas compatibles.
[^] # Re: La GPL ne résout pas son problème
Posté par Zenitram (site web personnel) . En réponse au journal Pourquoi j'utilise la GPL. Évalué à 5.
Oui, c'était le mot recherché!
[^] # Re: La GPL ne résout pas son problème
Posté par Zenitram (site web personnel) . En réponse au journal Pourquoi j'utilise la GPL. Évalué à 3.
Mais si ce programme était utilisé que en interne, comme de plus en plus de projets "web service" (genre... Un serveur SMTP, exemple pris par l'auteur), pourquoi aurais-tu acheté une licence qui ne change rien? Quel "utilité" apporté par la GPL par rapport à la BSD qui t'aurais poussé à acheter? rien.
La GPL répond au besoin que dans un cas qui devient de plus en plus minoritaire, l'AGPL pourrait la remplacer alors mais elle ne fait pas l'humanité comme la GPL...
[^] # Re: Ego trip
Posté par Zenitram (site web personnel) . En réponse au journal Pourquoi j'utilise la GPL. Évalué à 3.
Trop facile.
La GPL est faite pour lutter contre le propriétaire. C'est une licence de combat ou d'évangélisation.
Non. Elle est ce qu'on en fait, rien de plus.
Linus T., moi ;-), n'avons rien à faire de l'évangélisation. On fait parce que c'est la meilleure licence pour faire le meilleur logiciel (et en bonus, en vivre).
On laisse le combat ou l'évangélisation à d'autres.
Ne fait pas de la GPL ce qu'elle n'est pas : c'est un outil, c'est tout. Certains l'utilisent pour le combat ou l'évangélisation, d'autres pour d'autres choses.
En moyenne j'ai précisé, pas la peine de me sortir 2 contre-exemples, car il y a des centaines d'exemples positifs.
Ben si, j'ai sorti que 2 exemples, mais il y a plein de monde qui font de la GPL pour d'autres choses que ce que toi tu veux en faire. "En moyenne"? Tu as une démonstration que la moyenne est pour l'évangélisation? Personnellement, je ne crois absolument pas que la vision de Stallman est celle des la moyenne des développeurs du libre. Que la moyenne de ceux qui trollent, c'est possible, que ceux qui développent, la majorité silencieuse, j'ai un gros doute.
[^] # Re: La GPL ne résout pas son problème
Posté par Zenitram (site web personnel) . En réponse au journal Pourquoi j'utilise la GPL. Évalué à 2.
Euh... Dans le cas d'un serveur SMTP par exemple, l'industrie informatique en général est l'utilisateur final
S'il développe du code utile sous une licence trop permissive, celui-ci peut être réutilisé de manière silencieuse par l'industrie informatique.
De la même manière qu'une serveur SMTP en GPL : la GPL n'empêche pas d'utiliser le serveur SMTP de manière silencieuse (sans le dire aux clients)
Avec du code sous GPL, l'entreprise qui réutilise son code est obligée de le reconnaître (en interne), ce qui pourrait l'inciter à travailler avec l'auteur (achat de licence, consulting...).
En quoi le fait qu'il ne soit pas en BSD change ça?
Si quelqu'un a un besoin, il va remonter à l'origine pour en demander le développement. La licence BSD ou GPL ne change rien.
Si le code sous GPL ne règle pas le problème de reconnaissance de la part du public, est-ce qu'il ne permet pas d'ouvrir des opportunités commerciales ?
Toutes les opportunités commerciale que j'ai eu sont parce que je suis le plus expert sur mon logiciel (logique ;-) ) pour faire un développement.
La licence n'a pas changé grand chose...
BSD ou GPL, pour les logiciels utilisés en interne, ça ne change pas grand chose... Surtout qu'en interne, celui qui reçoit le code ne va pas attaquer en justice son collègue si le code n'est pas fourni.
# NdM
Posté par Zenitram (site web personnel) . En réponse à la dépêche Sortie d'UltraCopier 0.2 et Catchcopy. Évalué à 4.
Qt4 n'est pas KDE.
[^] # Re: Etat d'esprit
Posté par Zenitram (site web personnel) . En réponse au journal Pourquoi j'utilise la GPL. Évalué à 4.
Des personnes comme toi, les développeurs du libre n'en ont pas besoin, bon vent, ça ne changera rien dans la vie du développeur du libre.
# La GPL ne résout pas son problème
Posté par Zenitram (site web personnel) . En réponse au journal Pourquoi j'utilise la GPL. Évalué à 8.
En effet, de plus en plus de logiciels sont utilisés en interne, on peut prendre un gros exemple : Google. Combien de code GPL adaptent-ils mais ne livrent rien à la communauté parce que la GPL ne les obligent pas?
La GPL résout le problème pour les logiciels distribués, mais qui deviennent de plus en plus rare, web service oblige.
Est-ce que l'AGPL va prendre plus de place alors? Rien n'est moins sûr...
Bref, ce n'est pas parce qu'on fait de la GPL que ça va changer quelque chose, surtout dans son exemple (un serveur SMTP? Utilisé en interne, pas besoin de diffuser les modifs ou dire qu'on l'utilise).
La problématique est la bonne (j'ai exactement le même problème dans mon entreprise : je suis à plein d'endroits sympa, mais les entreprises ne veulent pas le dire), mais la GPL n'y répond pas (je suis en GPL, ça n'empêche pas les entreprises de ne rien dire). Je cherche encore la bonne réponse (mettre en AGPL? Malheureusement, je perdrai plus de client payeurs potentiels que je gagnerai, car l'AGPL n'est pas acceptée facilement comme référence, c'est aussi un problème)
[^] # Re: Comparaison avec Seven
Posté par Zenitram (site web personnel) . En réponse à la dépêche Test d'Ubuntu 9.10 (Karmic Koala). Évalué à 2.
[^] # Re: Comparaison avec Seven
Posté par Zenitram (site web personnel) . En réponse à la dépêche Test d'Ubuntu 9.10 (Karmic Koala). Évalué à 2.
Mon pb est que dans mes conditions (pilote officiel libre + pas cher), ben il n'y avait pas.
Après, on priorise... Étant encore sous Windows, j'aurai pu aussi prioriser le prix et prendre une imprimante Windows-only, bon je ne suis pas allé jusqu'à la, mais d'autres le font sans doute.
Bref, tout ça pour dire que c'est loin d'être simple, et qu'on ne trouve pas forcement chaussure à son pied.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 2.
FTP simple???
(et encore je suis pas sur que la connexion data soit ouverte dès le début)
Non, puisqu'ils négocient le port lors du dialogue.
Tu oublie pas mal d'échanges en FTP...
plusieurs secondes pour ça me parait aberrant
Plusieurs secondes, c'est peut-être beaucoup.
Mais dans le genre 5x plus lent que HTTP, sans aucun doute.
Pense aux aller-retour login/pass inutiles, allez je suis gentil je te fais un listing :
Connexion
USER
réponse
PASS
réponse
TYPE I
réponse
PASV
réponse
RETR
réponse avec adresse/port passif
2ème connexion
transfert
en HTTP :
Connexion
GET blabla en 1 fois
réponse + transfert en une fois
Et après tu oses dire que FTP est simple, rapide???
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 3.
Non (cf Firewall, NAT, Ca casse pas mal la simplicité)
et avec peu d'overhead
Non dans 99.999% des cas (celui d'un download de fichier unique), FTP a 2-3 fois plus d'overhead que HTTP (compte les connexion TCP, la couche IP...). Dire que FTP consomme moins de BP/CPU, c'est un peu rigolo...
alors pourquoi s'en passer ?
Parce qu'il ne convient pas dans 99.999% des cas.
Non, on ne peut pas s'en passer quand on est développer/uploader/échange de plusieurs fichiers, je l'utilise moi-même tous les jours (FTP/SFTP), mais je suis réaliste : c'est pour un besoin précis.
Pour transférer un fichier de manière simple dont on a l'URL, soit 99.999% des demandes, FTP est une horreur que ce soit en connexion, overhead, simplicité etc...
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 3.
C'est effectivement certainement pas un hasard si les uploaders (0.001% des utilisateurs) utilisent FTP pour l'upload mais que les admins ont mis une surcouche HTTP pour les downloaders (99.999% des autres utilisateurs) pour le download.
Arrête, tu t'enfonces... FTP est bien pour l'upload, mais reste pourri pour le download, quoique tu cherches à inventer quand on te met le nez dedans.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 2.
Surcout que tu n'arrives pas à prouver, les exemples que tu donnes étant en faveur de HTTP... Mais bon, si tu veux absolument croire qu'un protocole qui ouvre deux ports est moins consommateur qu'un protocole qui ouvre un port... (sans parler de la simplicité de mise en œuvre, firewall, NAT... non, c'est vrai quoi, HTTP n'apporte rien, sauf des avantages que tu refuses de lire)
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 1.
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 3.
Tu peux me dire comment tu fais du FTP avec une connexion, ça m'interesse.
Je ne sais pas faire avec moins de 2.
Et entre la fourniture de PASV, 2 init TCP, et j'en passe, l'overhead FTP est énorme par rapport à HTTP... Ne parlons même pas du temps de réponse avec ces commandes et ouvertures de port séquentielles
FTP, c'est pourri pour un transfert de fichier public!
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 3.
Il y a plus de lien FTP que HTTP? Problème de mathématique? Ou inversion de nom de protocoles?
284 HTTP vs 238 FTP.
[^] # Re: Comparaison avec Seven
Posté par Zenitram (site web personnel) . En réponse à la dépêche Test d'Ubuntu 9.10 (Karmic Koala). Évalué à 1.
Parce que l'acheteur, il veut le moins cher, et que dans 99.9% des cas il s'en fout de la documentation. Comme la documentation publique (une documentation interne n'a pas un niveau de qualité pour être publique comme ça) ça coûte cher à faire, et que le consommateur s'en fout, on limite les coûts --> Pas de doc.
Après c'est deux vues économiques qui s'opposent : les libéraux et les conservateurs
Certainement pas. C'est uniquement une histoire d'argent : si la doc publique rapporte plus d'argent que pas de doc, la doc sera fournie.
Il ne te reste plus qu'à faire le nécessaire pour que ce soit le cas, car aujourd'hui faire une doc publique coûte beaucoup et ne rapporte presque rien.
Autre possibilité : faire une loi pour que la doc soit obligatoire. De ce côté, ce n'est pas gagné non plus.
Les gens qui se sont jetés dessus sont les geeks de la première heure.
Il y a plus de geeks Windows 7 que de linuxiens toute population confondue : Avant son lancement, Win7 (piraté donc...) avait entre 2 et 5% de PPM, contre 1 à 2 % de PPM pour Linux toutes versions...
Il n'y a pas à dire, les Linuxiens sont en très forte minorité, derrière les geeks de la première heure Windowsien... Alors ça ne fait pas vraiment le poid devant un constructeur pour lui demander sa doc, très très loin.
[^] # Re: Beau...
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 5.
Quand on ne connait pas, on évite de parler : QtCore (le seul module utilisé) ne dépend jamais de X.
[^] # Re: Comparaison avec Seven
Posté par Zenitram (site web personnel) . En réponse à la dépêche Test d'Ubuntu 9.10 (Karmic Koala). Évalué à 0.
Donc tu ne t'en fous pas des part de marché, car la réalité est méchante : seules les parts de marché comptent pour ça.
Fournir un matériel non documenté ça ne devrais même pas exister,
Si tu es prêt à payer pour cette doc... Bizarrement, quand il faut passer à la caisse, il n'y a plus grand monde.
Une doc publique, ça coûte de l'argent, il faut que le constructeur y voit un intérêt, et avec 1% de part de marché à gagner, il s'en fout.
Et on revient à la case "part de marché".
Ta théorie est belle "je veux", il y a la réalité du monde d'aujourd'hui : ton "tu veux", on s'en fout, on le fera que si il y a une part de marché.
Donc si tu veux ton "je veux", ben il faut faire le nécessaire...
[^] # Re: Beau...
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 2.
Question de point de vue : en:DRY
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 3.
Les windowsiens ont une myriade de logiciels appelés "Download managers" pour gérer même avec des sources multiples (le même fichier sur 10 URL en HTTP différentes, et hop c'est parti). Très pratique au début de l'ADSL lorsque le débit du client était plus gros que le débit du serveur. Ton proz -k=10 fait petit joueur à côté.
Un player Youtube (par exemple) peut faire un seek dans une vidéo qui n'a pas fini de télécharger, tu penses qu'il peut faire comment?
Bref, oui, ça peut, c'est utilisé depuis plus de 10 ans par des centaines de logiciels. HTTP est très fort, et il ne reste pas grand chose à FTP (listing de répertoires, upload... Et encore, on peut uploader en HTTP aussi) qui se traine de grosses casseroles (2 connexions dont parfois une dans l'autre sens que l'initialisation etc...)
[^] # Re: FTP
Posté par Zenitram (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 8.
Tu prends le message précédent, tu lis les inconvénients donnés au FTP, et hop tu as les avantage de HTTP par déduction, s'est-il pas beau?
Plus sérieusement, HTTP est tellement plus simple pour faire du transfert de fichier que FTP (qui malgré son nom, ne rend pas le transfert de fichier simple) que quand on réfléchi à implémenter, on voit rapidement qu'il faut plus de temps pour FTP, et quand on teste FTP a grande échelle on s'aperçoit que c'est une horreur sans nom (firewall, NAT etc...)
Mais ici, pour bâcher un peu tout le monde, pourquoi ne pas proposer FTP en plus de HTTP? Qui peut le plus peut le moins, et Qt offre une manière transparente de gérer les 2 protocoles.
[^] # Re: Comparaison avec Seven
Posté par Zenitram (site web personnel) . En réponse à la dépêche Test d'Ubuntu 9.10 (Karmic Koala). Évalué à 2.
D'un coté, il y a HP, qui fournit les docs et participe activement au développement des drivers pour Linux.
J'ai hésité entre deux imprimantes:
* HP Color LaserJetCP1515n
http://www.openprinting.org/show_printer.cgi?recnum=HP-Color(...)
http://h10025.www1.hp.com/ewfrf/wc/softwareCategory?product=(...)
Pas de support officiel sur le site officiel, pas de support officiel sur openprinting
* Samsung CLP-315
http://www.openprinting.org/show_printer.cgi?recnum=Samsung-(...)
http://www.samsung.com/fr/support/download/supportDown.do?ty(...)
Support officiel sur le site officiel, pas de support officiel sur openprinting. C'est pas libre (binaire), mais c'est officiel.
J'ai du coup préféré prendre Samsung.
HP est loin d'être parfait (aucun support officiel), Samsung non plus (binaires), ce n'est pas aussi simple que tu le dis de choisir une imprimante.
[^] # Re: IPoT + Busiris
Posté par Zenitram (site web personnel) . En réponse au journal [HS Logiciels libres] Les parlementaires UMP soutiennent officiellement le protocole IPoT. Évalué à 3.
Disons qu'au niveau politique, même si j'ai encore la barrière de la langue, je note que les politiques ne sont pas des rois, ils ne sont pas adulés comme en France, il font juste un métier. Même si ça n'empêche pas tous les dérapages (loi style HADOPI mais en plus fort qui a failli passé mais passé à la trappe merci les élections, président de la banque centrale qui dit que les turcs sont juste bon à vendre des fruits et légumes etc...)
Ah la manie française de vouloir des rois aux pleins pouvoirs aussi... Et personne pour assumer et dire "'j'ai voté pour lui"
[^] # Re: Comparaison avec Seven
Posté par Zenitram (site web personnel) . En réponse à la dépêche Test d'Ubuntu 9.10 (Karmic Koala). Évalué à 2.
Ah? Bizarrement tout n'est pas vert pour les imprimantes HP :
http://www.openprinting.org/printer_list.cgi?make=HP
(et pas mal sont avec un *, disant que c'est pas garanti, juste un utilisateur a dit que)
Et il y en a une de chez HP qui m'intéressait, mais c'était bien écrit sur la boite : "Windows only".
J'estime qu'aujourd'hui il y a suffisamment de sources d'information pour choisir du matériel pour ne pas aller s'emmerder avec du matos non supporté, et ensuite se plaindre que son imprimante ne fonctionne pas sous Linux.
Malheureusement, la réalité est loin d'être aussi idyllique... Même chez HP, la marque d'imprimante avec le plus de matériel compatible, les imprimantes "intéressantes" pour certains ne sont pas compatibles.