j'ai eu le truc que j'ai compilé from sources sans soucis,
Mme Michu, qui veut son appli pour la cuisson des oeufs a la coque, ne sait pas compiler. Elle ne sait même pas ce qu'est une ligne de commande, et ne veut pas savoir.
Qu'est-ce qu'il y a de compliqué à comprendre dans cette phrase?
Je te dis que Mme Michu veut pouvoir avoir son application (pour a cuisson des oeufs a la coque), tu sors l'artillerie lourde "compilation", super, dans le genre je ne comprend pas pourquoi ce con d'utilisateur va sous Windows parce qu'au moins, il peut utiliser son appli. Ta solution n'est pas une solution.
Ce que tu appelles le bâton dans les roues du dev, c'est justement cette diversité
On peut avoir une diversité sans mettre des bâton dans les roues.
Il peut y avoir des standards commun pour des choses communes, sans pour autant casser la diversité.
Mais c'est tellement plus facile de se dire que la liberté est à ce prix plutôt que de regarder en face les problèmes... Non, la liberté n'est pas à ce prix, il est tout à fait possible d'être libre sans pour autant faire chier l'utilisateur et le développeur, mais encore faut-il penser à l'utilisateur ou au développeur, c'est parfois oublié...
En attendant, tu n'apportes aucune explications sur comment faire pour que le posteur du journal puisse avoir son applibre pour la cuisson des oeufs a la coque... Il n'y a pas de problème!
Ce n'est pas parce que je n'aime pas la GPL sur un point précis que je suis aveugle sur les problèmes de la CDDL.
De plus, je considère toute licence non compatible GPL comme pas correcte, car je cherche à avoir des compatibilités maximales entre les licences, et je pense que les développeurs potentiels de Solaris cherchaient la même chose.
Il y a mes idéaux, et il y a des explications aux manques de Solaris, tu veux mélanger les deux, trop bizarre quand même de transformer une explication du problème en ce que je pense. Il n'est pas possible de différencier les deux?
Attends, je regarde : licence incompatible avec la GPL, et ce volontairement.
Et après il s'étonne que personne ne veuille faire du développement pour eux? SUN l'a bien cherché quand même à demander une communauté tout en la faisant fuir...
Pour HTML, les développeurs de navigateurs HTML (Opera, Microsoft, Mozilla, Apple...) se mettent autour d'une table et font des specs communes, qu'ils proposent ensuite aux développeurs.
Avoir une "API" commune comme HTML n'empêche pas la guerre des navigateurs, les différences, au contraire. Et les développeurs de site sont très peu présents.
Et ça marche. HTML est standard, partout.
Bizarrement, impossible de faire la même chose pour les gestionnaires de bureau ou les packages Linux, et c'est la faute des développeurs, va comprendre...
En attendant, aucune autre explication a été donnée au fait bien factuel du manque de petites applis pour Mme Michu sous Linux... Linux est tellement parfait qu'on ne trouve aucune raison pour ce manque?
Il l'ont fait : autopackage.
Mais ça ne plait pas aux mainteneurs de distro qui crachent dessus plus qu'autre chose.
Sans la bonne volonté des mainteneur de distro, ça ne mène pas loin, puisqu'il faut un accord de tout le monde.
De plus, un développeur s'occupe de développer son appli, et prend ce qu'on lui donne, et si il n'y a rien, ben il ne porte pas.
On critique Microsoft ou Apple, mais eux, ils ont compris que proposer des plate-forme de développement correctes aide à avoir des développeurs, et donc des utilisateurs par ricochet.
c'est un choix, mais alors il ne faut pas venir se plaindre qu'on a pas d'app pour la cuisson des oeufs a la coque quand on fait (pas) le nécessaire pour inciter à développer pour sa plate-forme.
Mais lorsque tu dis que les sources qui compilent ne suffisent pas pour se retrouver partout c'est faux.
J'ai pourtant donné des exemples.
De plus, l'auteur du journal demande pourquoi il n'y a pas d'app pour la cuisson des oeufs a la coque sous Linux mais sous Windows, iPhone et compagnie, et personne n'a pu donner une meilleure explication. D'après toi alors, si ce n'est pas ce que je raconte, que'est-ce qui fait que les autres OS ont plus de petites applis que les gens aiment?
Je suis presque persuadé que Médiainfo serait repris dans les grandes distributions sans aucun soucis, et c'est comme cela que ca marche dans la vrai vie de linux.
Je tiens le pari, mais je te laisse faire alors : un mec a essayé pour Ubuntu, il s'est fait envoyer bouler car ça ne respectait pas les bonnes règles, il a abandonné. La vraie vie de Linux, c'est une minuscule partie des logiciels qui sont repris dans les dépôts. Le chiffre affiché par chaque distro (y compris Debian) peut paraitre grand, mais en réalité chaque utilisateur a sa petite appli adorée qui n'est pas la même (j'éviterai de parler de l'age de certaines versions des logiciels dans les dépôts...), et que celle-ci n'est pas dans les dépots.
Le système de dépôt montre ses limites : c'est génial (un clic, et tout est MAJ) pour un serveur qui a des logiciels "standards", mais ça ne marche pas pour Mme Michu dont l'appli n'est pas mise dans les dépôts faute de mainteneur et de personnes le faisant.
Alors sous linux, tu fais un jolie package de source, comme tu à l'air de si bien le faire (avec même les spécificités debian) et tu le soumets aux distributions qui le packageront comme des grands en l'intégrant à leurs système de packaging.
Non cf plus haut : package abandonné car personne intéressé pour maintenir la chose. MediaInfo n'est pas assez populaire pour que ta théorie marche. Alors je n'ose imaginer pour des plus petites applis encore...
Bref, je tiens le pari : le package source contient le .spec et Debian, tu me démontres que quand on a fait le boulot "développeur" ça roule tout seul? Moi, j'ai abandonné l'idée, car j'ai vu que tu parles de theorie, et pas de pratique. J'ai fait une bonne partie du boulot (.spec et debian faits), j'abandonne. Tu a l'air de dire que c'est simple, ça devrait donc te prendre très peu de ton temps non? Il faudra aussi veiller à mettre à jour le package, pas envie de me coltiner des bugs de vieilles versions.
Je fais un constat simple : plein de monde pour dire que c'est simple, personne pour le démontrer.
Moi j'utilise plutôt kde, chez des potes j'utilise gnome, j'install du icewm, fluxbox, fvwm, jvm, suivant le public à qui je destine la machine que j'installe
Cette diversité est excellente! Il ne faut pas l'enlever!
Mais je ne vois pas le rapport entre la diversité dont tu parles et les bâtons dans les roues mis aux développeurs.
Vouloir uniformiser, c'est la mort,
Uniformiser e nom du package Qt est-il la mort? Ca apporte quoi à part faire chier les développeurs?
Il y a un an, ?mandriva_version (mdv_version?) marchait pas, ça a progressé?
La, ça tombe en marche pour pour Mandriva 2009.0 i586+x86_64, 2009.1 i586 et 2010.0 i586+x86_64, tu noteras que 2009.1 x86_64 n'est pas dedans car ça marche pas. J'ai beau faire toutes les incantations vaudou, ça ne marche pas pour cette version spécifique.
Ca (des fois, ça marche, ou pas + faire un .spec acceptable par tous + le debian), c'est la réalité des développeurs, pas la théorie "le code source c'est suffisant et génial ça compile partout"... (parce que des blagues sur les spécificités par plate forme de GCC, j'en ai aussi puisque je développe aussi pour GCC Solaris ou microlibC ou MinGW, avec des problèmes d'implémentation manquante de la lib C/C++ standard suivant l'humeur...)
Je râle, ce n'est pas pour "casser du Linux", mais pour faire comprendre les points faibles, ce qui est améliorable, sans pour autant casser les spécificités de chaque distro (parce que bon, ça apporte quoi à la spécificité de la distro de changer le nom du package Qt?)
Je croyais me souvenir que tu pouvais uploadé une bonne fois pour toute les paquet sources, et même faire un seul fichier spec pour plusieurs distros
Ben non. Il y a bien un .spec pour les RPM, mais voila ce qu'on doit faire :
BuildRequires: libqt4-devel
%if 0%{?suse_version}
BuildRequires: update-desktop-files
%endif
%if 0%{?centos_version} || 0%{?rhel_version} || 0%{?fedora_version}
Requires: qt4 >= 4.0.0
%endif
%if 0%{?mandriva}
Requires: libqtgui4 >= 4.0.0
%endif
%if 0%{?suse_version} || 0%{?opensuse_version}
Requires: libqt4 >= 4.0.0
Requires: libqt4-x11 >= 4.0.0
%endif
Ca donne envie hein? Juste pour pouvoir avoir Qt! Et ça, avant de tout trouver, on se paluche les erreurs remontées par OBS...
Et c'est sans compter qu'il faut aussi encore faire le répertoire Debian pour Debian et Ubuntu!
OBS simplifie des choses très complexes, ça les rends moins complexes, mais toujours complexes.
genre il y a main de mandriva mais pas contrib dans le OBS officiel?
Mal compris : une fois que tu as tous tes fichiers, ben il faut quand même orienter l'utilisateur vers le bon paquet. Sous Windows, c'est relativement simple : 1 paquet pour tous, on arrive à faire compatible pour toutes les versions (en plus le 32 bits fonctionne pour sûr sur tous les Windows 64-bits, on s'emmerde pas pour une petite appli, sous Linux il n'y a pas toujours la partie 32-bits)
Note : bon point pour les distros Linux sur une partie : le user-agent contient le nom de la distrib, sa version, et le CPU, ce qui permet de détecter automatiquement le paquet à offrir. Sous Windows, il n'y a pas le CPU dans le user-agent.
– tu ne peux pas faire des binaires statiques ? C'est ce que fait par exemple Firefox et ça le mérite d'être portable (?).
Il y a effectivement la solution binaire statique, avec les inconvénients :
- L'intérêt de Linux n'est-il pas la modularité? Avec du statique, faut transporte par la même occasion le toolkit graphique complet (Wx, GTK, ou Qt, d'alleurs ça n'enlève pas le pb que d u GTP ne passe pas bien dans KDE etc), comme pour windows ou Mac tu me diras, mais du coup on a les inconvénients d'un Linux pas homogène et aucun avantage avec.
- le tar.bz2 de firefox, c'est fait pour les geeks : Mmm michu avec son applibre pour la cuisson des oeufs a la coque, elle va lancer le .tar.bz2, et... Ne rien comprendre. Le tar.bz2 c'est pas pour Mme Michu!
- L'intégration dans le bureau. Je ne sais pas si FF le fait, mais Mme michu, elle a envie d'avoir un accès rapide à sa petite appli ensuite, le menu doit donc être créé. Bon, ça, si ça ne se fait pas à l'install, ça peut se faire au pire à l'exécution... Le binaire statique ne résoud que quelques problèmes, il en reste encore beaucoup ensuite.
- Personnellement, je suis peut-être une burne, j'ai abandonné les binaires statiques car j'avais des problèmes avec, crash
– quel serait selon toi la solution (mise à part "on utilise tous la même distribution") ? Par exemple un rpm à le mérite d'être lisible par de nombreuses distributions (red hat, fedora, mandriba, debian, *buntu). Est ce que cela pourrait être un standard ?
Qu'est-ce qui pourrait être un standard, la réponse du développeur est : j'en ai rien à foutre, prenez celui que vous voulez, du moment où il y en a un seul.
Le développeur de base ne veut pas s'immiscer dans les choix, il veut juste une chose : réduire le temps de développement de la partie "compatibilité Linux". Il s'en fout qu'après Gnome ou KDE ou tout ce que tu veux fasse la gestion, il veut juste communiquer avec une seule langue, ça n'enlève en rien l'hétérogénéité des Linux, des bureaux etc... Il veut juste un pivot commun, tout comme HTML l'est pour le web : qui imaginerait développer deux fois une page, une fois eh HTML et une fois en langue y, pour être dispo partout? Bizarrement, c'est acceptable pour les bureaux Linux.
Pour ça, il y a LSB par exemple qui se veut essayer de réunir tout le monde, mais plein de distro refusent d'être LSB-compliant, va comprendre...
C'est ce que j'utilise, sinon je mourrai.
Ca automatise pas mal de choses, mais ça n'enlève pas :
- avoir 1 paquet par version de chaque distro (faut se coltiner la gestion des fichiers ensuite, tu peux pas dire "télécharge xxx", mais "tu as quoi? distro x? quelle version? y? OK, alors le fichier à télécharger c'est z, oui, parce que bon, ton upstream n'a pas tous les logiciels, et je n'ai pas pris la peine de me palucher toutes les règles et passer plein de temps à essayer d'être accepté dans le repository offciel, donc faut faire avec")
- faire les /debian et le .spec (avec des #if qui se baladent pour adapter à chaque distro), autotools tout seul ne fait rien avec OBS.
- Qu'OBS ne dispose pas de Slackware, PCLinuxOS, Archlinux et autre distribution "exotiques" que mes utilisateurs ont le malheur d'utiliser.
OBS est une solution de contournement à un problème, mais ne résout pas le problème.
Canonical n'a fait que reprendre GNOME et le customiser;
Mais si c'était si simple, pourquoi les autres ne l'ont pas fait?
Je me permet de donner une idée : parce que ce n'est pas si simple, et que du coup Canonical apporte quelque chose. Qui ne te plait pas peut-être, mais c'est quelque chose.
mais Canonical ressemble pour beaucoup à une boîte opportuniste, et j'ai l'impression que c'est surtout les autres qui développent.
Attend, je regarde... Libre, 4 libertés... Et merde, Canonical qui utilise les libertés du libre, vraiment celui-la, quelle idée d'utiliser ce que les autres donnent!
Tant que Canonical ne sera pas rentable, je ne pense pas qu'on puisse parler de succès.
Tu feras rire tout le monde en disant que Youtube, Facebook et Twitter n'ont pas de succès (aucun des 3 n'est rentable).
Tu as une drôle de définition (ta définition répond plus au mot "rentabilité"), qui n'est pas acceptée par les "autres".
le DRM (vidéo/audio) a un travers : on essaye de crypter quelque chose sur la machine de l'utilisateur (aberration, mais bon...)
Résultat : le contenu chiffré et la clé de déchiffrage sont exactement au même endroit, et on te demande juste de ne pas regarder quand la clé est utilisée pour déchiffrer. Par définition, il y a un problème.
Pour ton mail, on n'essaye pas de t'empêcher toi, destinataire du mail, de lire le contenu, mais ceux sur le chemin. A la différence de l'audio et vidéo des majors, sur le chemin la clé n'est pas disponible, seulement le contenu chiffré. Celui qui récupère le contenu ne peut pas déchiffrer car il n'a pas la clé.
Bref, deux situation incomparables :
- D'un côté, on a le contenu chiffré + la clé au même endroit
- de l'autre, on a juste le contenu chiffré, la clé est ailleurs.
Du coup, dans le cas du mail, que tu mette un hook dans le code pour récupérer le contenu déchiffré ne dérange pas, tu es sur ta machine, le hook ne te servira qu'à toi.
Dans le cas de l'audio et la vidéo, le hook te servira tout autant à toi que dans le cas du mail, mais les majors te considèrent comme le "pirate".
Bien faire la différence : d'un côté tu es l'utilisateur normal, de l'autre tu es le pirate sur ta propre machine (si si il y en a que ça ne dérange pas de considérer le client comme un pirate)
Red Hat "n'est que" l'employeur de Chris Montgomery, développeur principal du conteneur ogg, et des formats Vorbis et Theora (et fondateur de la fondation Xiph),
Arghh... Me voila bien dépourvu d'un coup. OK, je retire donc, ils ont fait plus (beaucoup plus même), je dormirai plus informé ce soir (bémol tout de même : le dépêche ne dit pas si RH paye pour qu'il développer OGG/Theora ou si il fait autre chose, et que OGG/Theora est un hobby seulement)
'est plutôt injuste de mettre Debian dans le même sac, Debian est une organisation à but non-lucratif et dédié aux logiciels libres, elle n'a pas les mêmes moyens que les sociétés mentionnées.
De mon point de vue, la façon de fonctionner d'une entité la regarde, à elle de trouver le meilleur moyen pour financer des développeurs, sa façon de fonctionner ne doit pas être prise en compte quand on fait le bilan de qui a dépensé quoi pour faire avancer une technologie.
Comme je l'ai écrit plus haut, c'est faux pour Red Hat. Relis-moi, j'ai énuméré des faits réels de la part de Red Hat.
PAs de soucis, Redhat fait énormément pour le libre, c'est un très gros contributeur.
Mais pas pour Theora précisément.
Canonical fait tout autant beaucoup pour le libre, avec des choses moins appréciées par les "puristes" comme faire attention à l'expérience utilisateur, mais c'est ce qui fait que bon nombre d'utilisateur de Linux sont sous Linux (et parfois avec une autre distribution qu'Ubuntu qui a été juste transitoire)
C'est trop facile : parce que Canonical fait des choses "moins pures", une minorité tape dessus, pendant qu'une majorité utilise.
Canonical a fait beaucoup pour le libre, lui refuser ça est bizarre.
Entre un Red Hat rentable et un Canonical qui perd du pognon chaque jour, je me demande si je tape réellement sur celui qui a le plus de succès...
En nombre d'utilisateurs, Canonical a plus de succès que RedHat (facile, avec le grand public ça monte vite). Peu de gens ont entendu parlé d'Ubutnu, mais encore moins de Redhat.
Succès ne veut pas dire rentabilité financière (Qui oserai dire que Facebook, Twitter, Youtube n'ont pas de succès? Ils sont dans le rouge financièrement autant que Canonical...)
D'ailleurs, je t'ai répondu en affirmant qu'en effet, Red Hat n'a rien fait pour Theora, mais qu'ils ne peuvent pas tout faire
Comme Canonical ne peut pas tout faire non plus.
Les faits sont bien tristes : Redhat, Novell, Debian, etc... Ont fait tout autant que Canonical (=rien).
Mais bon, c'est le sport (inter)national de frapper sur celui qui a le plus de succès... Et surtout prendre un argument valide pour 2 entités, et argumenter avec cet argument pour une entité, et ne pas l'utiliser pour l'autre.
Disons qu'on a pas de chance et qu'on ne connaîtra pas ton génie sur nos machines
Avant de m'insulter, tu pourrais vérifier : http://mediainfo.sourceforge.net/fr/Download
Regarde le nombre de distributions supportées avant de dire n'importe quoi.
Pourquoi je fais ça? Car il y a des gens perdus qui trouve bien Linux sous certains côtés, mais qui pensent que le système de packaging "chacun à sa sauce" actuel, c'est la merde aussi, mais qu'ils doivent faire avec, et aiment qu'on s'occupent d'eux.
Désolé de me préoccuper des mes utilisateurs, qu'ils soient sous Windows, Linux ou Mac. Je pense à eux plutôt que de faire l'autiste "ouais, il y a autotools, vas-y" les pauvres...
Je parle de ce que je connais, de ce qui fait chier les développeurs, tu sais, les petits mecs qui produisent quelque chose, eux.
mais si tu pouvais juste arrêter de nous gonfler avec toujours les même remarques, cela _me_ ferait bien plaisir.
Le posteur du journal pose une question, j'y répond.
Je n'y peux rien si la réponse n'a pas changé depuis des lustres.
Ca ne te fait pas plaisir? Ne lit pas, ce n'est pas pour toi que j'écris.
Mais, si ton applis est potable et utile, un source qui "presque compile" est suffisant pour se retrouver partout
C'est faux, et c'est ce qui amène la question du journal d'ailleurs...
Personne ne te force à faire du linux, si tu n'aimes pas n'en fait pas, on ne t'en voudras pas, mais vient pas nous expliquer ici que c'est trop pourri.
C'est pourri, et c'est la réponse à la question du journal.
Mais si effectivement on a le droit de répondre que ce qui fait plaisir, ça ne va pas avancer.
Oui, je pointe du doigt ce qui fait mal, mais chut, faut surtout pas le dire... Faut rester dans l'idée que Linux c'est le rêve pour tout le monde, sans regarder ce que disent les utilisateurs, qui essayent Linux, puis assez souvent le fuis car "il y a rien comme logiciels sous Linux, contrairement aux mensonges de la publicité : les dépots ne contiennent pas grand chose par rapport à ce que j'aimerai" (=des petits softs idiots mais que les gens aiment...)
être libre c'est parfois difficile, c'est un choix.
On peut être libre, et savoir faire des standards entre gens civilisés. L'un n'empêche pas pas l'autre.
Chaque OS a ses défauts, Windows aussi, mais ce n'est pas parce que Windows a des défauts qu'il faut s'interdire de parler des défauts de Linux. Je te remonte les souffrances des utilisateurs et des développeurs de Linux, ceux qui développent des petites applis pour iPhone plutôt que pour Linux car Apple et Microsoft, eux, ont compris ce qui fait que ça marche : proposer un environnement de développement correct, déployable à grande échelle. Et les développeurs y vont, et les utilisateurs aussi.
Autruche, autruche... Ne surtout rien voir...
ca ne te plait pas? Moinsse moi, empêche-moi de poster sur LinuxFr, je ne ferai pas de multi pour continuer à faire ma prose. Mais en attendant, je considère le +10 du post initial plutôt comme une majorité silencieuse qui voit aussi les défauts plutôt que de faire l'autruche "il n'y a pas de problèmes avec mon OS que j'adule comme un Maqueux avec son Mac".
Car la, tu démontres une autre chose : en plus de faire l'autruche, tu ne souhaites pas qu'il y ai un respect de la liberté d'expression (je te "gonfle" comme tu dis, et tu aimerai bien me voir dégager d'ici) ni de la démocratie la plus élémentaire (les notes sont la pour montrer si oui ou non je suis "pertinent", et si je ne l'étai pas je n'aurai plus le droit de poster, malheureusement pour toi la moyenne de mes posts est largement supérieure à 2)
Pour exhausser ton souhait, une seule chose à faire : monter un kabale contre moi en mettant plus de monde qui me moinsse que de monde qui me plusse, et je partirai, en attendant je reste et je dis ce qui ne va pas, que ça te plaise ou non, et au passage, si ça ne te plait pas tu es autant libre que moi de partir.
A la "communauté Linux", où du moins ceux qui se plaignent de ne pas avoir d'applibre pour la cuisson des oeufs a la coque sous Linux, bref tous ceux qui demandent des applis compatibles avec leur OS : ils faut commencer à mettre la pressions sur les distros pour qu'elles proposent une API commune avant de demander aux développeurs de développer pour Linux des petites applis.
Mais bien sûr... T'es quand même fort toi : les constructeurs cherchent à miniaturiser en mettant le plus de choses dans le moins d'espace possible, mais pour toi c'est négligeable.
Pour les acheteurs, ça ne l'est pas, ils regardent la taille, et prennent le plus petit (qui a du microSD comme par hasard).
L'ajout de tous les éléments "négligeables" en taille amènent à du non négligeable, la microSD fait partie des choses pour réduire la tailles.
Que tu sois pas d'accord ne changera pas le regard des acheteurs, qui préfèrent les matériels avec microSD... Tu peux rester à vouloir de la SD partout, la réalité te rattrapera car on ne va pas faire un truc énorme rien que pour quelques personnes n'aimant pas la microSD.
A choisir entre un écran plus grand dans un appareil avec SD qui prend de la place, et un écran plus grand dans un appareil avec micro-SD qui prend moins de place à taille d'écran identique, le client achète celui qui est plus petit.
J'ai du mal à comprendre ce qui n'est pas compréhensible la dedans : si à caractéristiques égales (écran aussi grand), on arrive à faire plus petit (moins d'épaisseur car on a pris microSD à la place de SD), pourquoi continuer avec la SD qui n'apporte rien de plus que la MicroSD et prend plus de place?
. La µSD peut se justifier dans un tout petit appareil mais par exemple dans les APN c'est toujours de la SD et je n'entends pas les foules réclamer de la µSD...
La foule réclame des APN petits, et pour avoir des APN petits, il est préférable d'avoir de la microSD plutôt que de la SD.
Juste une question : quelque soit le matériel que je vais aller acheter au magasin du coin (bizarrement, le magasin vend des imprimantes, des scanners... Mais pas de cartes SCSI. Vraiment, ce magasin...), tu t'engages à ce que 10 minutes après l'installation je puisse scanner et imprimer par exemple, sous Linux? Car je peux m'engager pour Windows 7 (facile, tout ce qui est vendu dans le magasin est compatible Windows 7). Tu payes combien si j'achète un matériel que tu n'arrives pas à faire fonctionner? Tu t'engages à développer le pilote?
Bizarrement, on voit passer ici plein de question pour savoir si telle imprimante est compatible Linux, savoir quelle imprimante acheter pour pouvoir l'utiliser sous Linux...
J'adore : comme si Mr tout le monde avait une carte SCSI...
'est quoi les petits gadgets,
Surement pas une carte "pro" très peu utilisée.
Attend, qu'est-ce que j'appellerais "gadget":
- Téléphone mobile / smartphone
- APN
- Les trucs USB qui servent à rien sauf décorer
- Des manètes de jeux
- Des cartes vidéos récentes (avec de la 3D qui marche SVP)
- Des camescopes
- Les joujous de la carte-mère achetées qui montre la vitesse des ventilo, la température...
Mais surement pas une carte SCSI...
Sinon, ta carte fonctionne sous Windows 7: http://www.adaptec.com/en-US/support/scsi/u160/ASC-29160/
Donc pas un problème pour l'utilisateur : ça fonctionne, contrairement au gadgets, qui même en passant 2 jours dessus, ne fonctionnera pas sous Linux car le driver est dispo nul part (intégré à la distro, ou externe, non, nul part)...
Considérer une carte SCSI comme un gadget que les gens achètent en grand nombre, je rigole encore... Ca doit être une blague de linuxien!
Autotools, j'avais carrément zappé tellement l'idée est saugrenue : l'idée que les linuxiens savent tous ce qu'est une ligne de commande et savent installer un logiciel en ligne de commande est totalement faux! Sans compter que les autotools, sans customisation pour la distro chérie de l'utilisateur, compile (si l'utilisateur sait compiler!) à la condition d'avoir toutes les dépendances préalablement installées, mais n'est pas packagée.
Le côté positif c'est qu'ainsi le package est presque fait pour toutes les distributions Linux, et même d'autres systèmes Unix (*BSD, Solaris...).
Retour à la case départ : les autotools ne savent pas quelles sont les règles de nommage de fichier et les répertoires de chaque distro. J'utilise les autotools (sinon je mourrais), mais ça ne change rien au problèmes des distros : un autotools n'est pas le package de la distro, il faut le répertoire Debian ou le fichier .spec en plus sinon ça le fait pas, il faut trouver le répertoire KDE 3 ou 4 (pas forcement le même suivant la distro) pour y mettre les liens dans le menu etc...
Les autotools, c'est bien (c'est même nécessaire!) pour fournir des sources à des développeurs, et ça, c'es très très loin pour fournir une applibre pour la cuisson des oeufs a la coque à Mme Michu...
Le côté positif c'est qu'ainsi le package est presque fait pour toutes les distributions Linux,
Un package fait juste avec les autotools??? Euh... On n'a pas eu les mêmes contacts avec les règles de packaging des distros... Ce dont tu parles, c'est de la théorie pour logiciels n'ayant besoin d'aucune dépendance (donc surtout pas un GUI!) et avec aucune intégration possible dans le bureau...
c'était un mini usb (le même que pour mon tel android G1)
Euh... il me semblait que les mobiles avaient du Micro-USB plutôt?
C'est vraiment du mini, et pas du micro?
Ca ressemble vraiment au "mini" de cette image, et pas micro? http://upload.wikimedia.org/wikipedia/commons/c/cb/Types-usb(...)
(mon dernier achat, Archos 5i, bien plus gros qu'un smartphone, c'est du micro USB...)
Dommage d'ailleurs que ce soit de la MicroSD, qui n'apporte rien par rapport à la SD
Non, rien... juste un gain de taille, et c'est ce qu'on lui demande. Sont chiant c'est format à apporter ce qu'on leur demande, vraiment!
déjà bien assez petite.
Faut croire que les gens ne sont pas d'accord avec toi... Les gens achètent de plus en plus de la micro-SD, pour mettre partout : maison, ebook, téléphone portable, un seul format pour tout (essaye de mettre une carte SD dans un téléphone portable... Ca fait gigantesque!)
Pourquoi veux-tu avoir raison quand la réalité des courbes de vente te démontrent le contraire, que les gens demandent une taille plus petite, car contrairement à ce que tu affirmes, la forme SD n'est pas assez petite?
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 2.
Mme Michu, qui veut son appli pour la cuisson des oeufs a la coque, ne sait pas compiler. Elle ne sait même pas ce qu'est une ligne de commande, et ne veut pas savoir.
Qu'est-ce qu'il y a de compliqué à comprendre dans cette phrase?
Je te dis que Mme Michu veut pouvoir avoir son application (pour a cuisson des oeufs a la coque), tu sors l'artillerie lourde "compilation", super, dans le genre je ne comprend pas pourquoi ce con d'utilisateur va sous Windows parce qu'au moins, il peut utiliser son appli. Ta solution n'est pas une solution.
Ce que tu appelles le bâton dans les roues du dev, c'est justement cette diversité
On peut avoir une diversité sans mettre des bâton dans les roues.
Il peut y avoir des standards commun pour des choses communes, sans pour autant casser la diversité.
Mais c'est tellement plus facile de se dire que la liberté est à ce prix plutôt que de regarder en face les problèmes... Non, la liberté n'est pas à ce prix, il est tout à fait possible d'être libre sans pour autant faire chier l'utilisateur et le développeur, mais encore faut-il penser à l'utilisateur ou au développeur, c'est parfois oublié...
En attendant, tu n'apportes aucune explications sur comment faire pour que le posteur du journal puisse avoir son applibre pour la cuisson des oeufs a la coque... Il n'y a pas de problème!
[^] # Re: étudier le rachat d'une partie des actifs
Posté par Zenitram (site web personnel) . En réponse au journal Mandriva et Linagora. Évalué à 7.
De plus, je considère toute licence non compatible GPL comme pas correcte, car je cherche à avoir des compatibilités maximales entre les licences, et je pense que les développeurs potentiels de Solaris cherchaient la même chose.
Il y a mes idéaux, et il y a des explications aux manques de Solaris, tu veux mélanger les deux, trop bizarre quand même de transformer une explication du problème en ce que je pense. Il n'est pas possible de différencier les deux?
[^] # Re: étudier le rachat d'une partie des actifs
Posté par Zenitram (site web personnel) . En réponse au journal Mandriva et Linagora. Évalué à 2.
Attends, je regarde : licence incompatible avec la GPL, et ce volontairement.
Et après il s'étonne que personne ne veuille faire du développement pour eux? SUN l'a bien cherché quand même à demander une communauté tout en la faisant fuir...
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 2.
Avoir une "API" commune comme HTML n'empêche pas la guerre des navigateurs, les différences, au contraire. Et les développeurs de site sont très peu présents.
Et ça marche. HTML est standard, partout.
Bizarrement, impossible de faire la même chose pour les gestionnaires de bureau ou les packages Linux, et c'est la faute des développeurs, va comprendre...
En attendant, aucune autre explication a été donnée au fait bien factuel du manque de petites applis pour Mme Michu sous Linux... Linux est tellement parfait qu'on ne trouve aucune raison pour ce manque?
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 2.
Mais ça ne plait pas aux mainteneurs de distro qui crachent dessus plus qu'autre chose.
Sans la bonne volonté des mainteneur de distro, ça ne mène pas loin, puisqu'il faut un accord de tout le monde.
De plus, un développeur s'occupe de développer son appli, et prend ce qu'on lui donne, et si il n'y a rien, ben il ne porte pas.
On critique Microsoft ou Apple, mais eux, ils ont compris que proposer des plate-forme de développement correctes aide à avoir des développeurs, et donc des utilisateurs par ricochet.
c'est un choix, mais alors il ne faut pas venir se plaindre qu'on a pas d'app pour la cuisson des oeufs a la coque quand on fait (pas) le nécessaire pour inciter à développer pour sa plate-forme.
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 3.
J'ai pourtant donné des exemples.
De plus, l'auteur du journal demande pourquoi il n'y a pas d'app pour la cuisson des oeufs a la coque sous Linux mais sous Windows, iPhone et compagnie, et personne n'a pu donner une meilleure explication. D'après toi alors, si ce n'est pas ce que je raconte, que'est-ce qui fait que les autres OS ont plus de petites applis que les gens aiment?
Je suis presque persuadé que Médiainfo serait repris dans les grandes distributions sans aucun soucis, et c'est comme cela que ca marche dans la vrai vie de linux.
Je tiens le pari, mais je te laisse faire alors : un mec a essayé pour Ubuntu, il s'est fait envoyer bouler car ça ne respectait pas les bonnes règles, il a abandonné. La vraie vie de Linux, c'est une minuscule partie des logiciels qui sont repris dans les dépôts. Le chiffre affiché par chaque distro (y compris Debian) peut paraitre grand, mais en réalité chaque utilisateur a sa petite appli adorée qui n'est pas la même (j'éviterai de parler de l'age de certaines versions des logiciels dans les dépôts...), et que celle-ci n'est pas dans les dépots.
Le système de dépôt montre ses limites : c'est génial (un clic, et tout est MAJ) pour un serveur qui a des logiciels "standards", mais ça ne marche pas pour Mme Michu dont l'appli n'est pas mise dans les dépôts faute de mainteneur et de personnes le faisant.
Alors sous linux, tu fais un jolie package de source, comme tu à l'air de si bien le faire (avec même les spécificités debian) et tu le soumets aux distributions qui le packageront comme des grands en l'intégrant à leurs système de packaging.
Non cf plus haut : package abandonné car personne intéressé pour maintenir la chose. MediaInfo n'est pas assez populaire pour que ta théorie marche. Alors je n'ose imaginer pour des plus petites applis encore...
Bref, je tiens le pari : le package source contient le .spec et Debian, tu me démontres que quand on a fait le boulot "développeur" ça roule tout seul? Moi, j'ai abandonné l'idée, car j'ai vu que tu parles de theorie, et pas de pratique. J'ai fait une bonne partie du boulot (.spec et debian faits), j'abandonne. Tu a l'air de dire que c'est simple, ça devrait donc te prendre très peu de ton temps non? Il faudra aussi veiller à mettre à jour le package, pas envie de me coltiner des bugs de vieilles versions.
Je fais un constat simple : plein de monde pour dire que c'est simple, personne pour le démontrer.
Moi j'utilise plutôt kde, chez des potes j'utilise gnome, j'install du icewm, fluxbox, fvwm, jvm, suivant le public à qui je destine la machine que j'installe
Cette diversité est excellente! Il ne faut pas l'enlever!
Mais je ne vois pas le rapport entre la diversité dont tu parles et les bâtons dans les roues mis aux développeurs.
Vouloir uniformiser, c'est la mort,
Uniformiser e nom du package Qt est-il la mort? Ca apporte quoi à part faire chier les développeurs?
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 2.
La, ça tombe en marche pour pour Mandriva 2009.0 i586+x86_64, 2009.1 i586 et 2010.0 i586+x86_64, tu noteras que 2009.1 x86_64 n'est pas dedans car ça marche pas. J'ai beau faire toutes les incantations vaudou, ça ne marche pas pour cette version spécifique.
Ca (des fois, ça marche, ou pas + faire un .spec acceptable par tous + le debian), c'est la réalité des développeurs, pas la théorie "le code source c'est suffisant et génial ça compile partout"... (parce que des blagues sur les spécificités par plate forme de GCC, j'en ai aussi puisque je développe aussi pour GCC Solaris ou microlibC ou MinGW, avec des problèmes d'implémentation manquante de la lib C/C++ standard suivant l'humeur...)
Je râle, ce n'est pas pour "casser du Linux", mais pour faire comprendre les points faibles, ce qui est améliorable, sans pour autant casser les spécificités de chaque distro (parce que bon, ça apporte quoi à la spécificité de la distro de changer le nom du package Qt?)
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 2.
Pareil.
Je croyais me souvenir que tu pouvais uploadé une bonne fois pour toute les paquet sources, et même faire un seul fichier spec pour plusieurs distros
Ben non. Il y a bien un .spec pour les RPM, mais voila ce qu'on doit faire :
BuildRequires: libqt4-devel
%if 0%{?suse_version}
BuildRequires: update-desktop-files
%endif
%if 0%{?centos_version} || 0%{?rhel_version} || 0%{?fedora_version}
Requires: qt4 >= 4.0.0
%endif
%if 0%{?mandriva}
Requires: libqtgui4 >= 4.0.0
%endif
%if 0%{?suse_version} || 0%{?opensuse_version}
Requires: libqt4 >= 4.0.0
Requires: libqt4-x11 >= 4.0.0
%endif
Ca donne envie hein? Juste pour pouvoir avoir Qt! Et ça, avant de tout trouver, on se paluche les erreurs remontées par OBS...
Et c'est sans compter qu'il faut aussi encore faire le répertoire Debian pour Debian et Ubuntu!
OBS simplifie des choses très complexes, ça les rends moins complexes, mais toujours complexes.
genre il y a main de mandriva mais pas contrib dans le OBS officiel?
Mal compris : une fois que tu as tous tes fichiers, ben il faut quand même orienter l'utilisateur vers le bon paquet. Sous Windows, c'est relativement simple : 1 paquet pour tous, on arrive à faire compatible pour toutes les versions (en plus le 32 bits fonctionne pour sûr sur tous les Windows 64-bits, on s'emmerde pas pour une petite appli, sous Linux il n'y a pas toujours la partie 32-bits)
Note : bon point pour les distros Linux sur une partie : le user-agent contient le nom de la distrib, sa version, et le CPU, ce qui permet de détecter automatiquement le paquet à offrir. Sous Windows, il n'y a pas le CPU dans le user-agent.
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 3.
Il y a effectivement la solution binaire statique, avec les inconvénients :
- L'intérêt de Linux n'est-il pas la modularité? Avec du statique, faut transporte par la même occasion le toolkit graphique complet (Wx, GTK, ou Qt, d'alleurs ça n'enlève pas le pb que d u GTP ne passe pas bien dans KDE etc), comme pour windows ou Mac tu me diras, mais du coup on a les inconvénients d'un Linux pas homogène et aucun avantage avec.
- le tar.bz2 de firefox, c'est fait pour les geeks : Mmm michu avec son applibre pour la cuisson des oeufs a la coque, elle va lancer le .tar.bz2, et... Ne rien comprendre. Le tar.bz2 c'est pas pour Mme Michu!
- L'intégration dans le bureau. Je ne sais pas si FF le fait, mais Mme michu, elle a envie d'avoir un accès rapide à sa petite appli ensuite, le menu doit donc être créé. Bon, ça, si ça ne se fait pas à l'install, ça peut se faire au pire à l'exécution... Le binaire statique ne résoud que quelques problèmes, il en reste encore beaucoup ensuite.
- Personnellement, je suis peut-être une burne, j'ai abandonné les binaires statiques car j'avais des problèmes avec, crash
– quel serait selon toi la solution (mise à part "on utilise tous la même distribution") ? Par exemple un rpm à le mérite d'être lisible par de nombreuses distributions (red hat, fedora, mandriba, debian, *buntu). Est ce que cela pourrait être un standard ?
Qu'est-ce qui pourrait être un standard, la réponse du développeur est : j'en ai rien à foutre, prenez celui que vous voulez, du moment où il y en a un seul.
Le développeur de base ne veut pas s'immiscer dans les choix, il veut juste une chose : réduire le temps de développement de la partie "compatibilité Linux". Il s'en fout qu'après Gnome ou KDE ou tout ce que tu veux fasse la gestion, il veut juste communiquer avec une seule langue, ça n'enlève en rien l'hétérogénéité des Linux, des bureaux etc... Il veut juste un pivot commun, tout comme HTML l'est pour le web : qui imaginerait développer deux fois une page, une fois eh HTML et une fois en langue y, pour être dispo partout? Bizarrement, c'est acceptable pour les bureaux Linux.
Pour ça, il y a LSB par exemple qui se veut essayer de réunir tout le monde, mais plein de distro refusent d'être LSB-compliant, va comprendre...
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 3.
Ca automatise pas mal de choses, mais ça n'enlève pas :
- avoir 1 paquet par version de chaque distro (faut se coltiner la gestion des fichiers ensuite, tu peux pas dire "télécharge xxx", mais "tu as quoi? distro x? quelle version? y? OK, alors le fichier à télécharger c'est z, oui, parce que bon, ton upstream n'a pas tous les logiciels, et je n'ai pas pris la peine de me palucher toutes les règles et passer plein de temps à essayer d'être accepté dans le repository offciel, donc faut faire avec")
- faire les /debian et le .spec (avec des #if qui se baladent pour adapter à chaque distro), autotools tout seul ne fait rien avec OBS.
- Qu'OBS ne dispose pas de Slackware, PCLinuxOS, Archlinux et autre distribution "exotiques" que mes utilisateurs ont le malheur d'utiliser.
OBS est une solution de contournement à un problème, mais ne résout pas le problème.
[^] # Re: Licence OEM
Posté par Zenitram (site web personnel) . En réponse au journal Canonical achete une licence H264. Évalué à 2.
Mais si c'était si simple, pourquoi les autres ne l'ont pas fait?
Je me permet de donner une idée : parce que ce n'est pas si simple, et que du coup Canonical apporte quelque chose. Qui ne te plait pas peut-être, mais c'est quelque chose.
mais Canonical ressemble pour beaucoup à une boîte opportuniste, et j'ai l'impression que c'est surtout les autres qui développent.
Attend, je regarde... Libre, 4 libertés... Et merde, Canonical qui utilise les libertés du libre, vraiment celui-la, quelle idée d'utiliser ce que les autres donnent!
Tant que Canonical ne sera pas rentable, je ne pense pas qu'on puisse parler de succès.
Tu feras rire tout le monde en disant que Youtube, Facebook et Twitter n'ont pas de succès (aucun des 3 n'est rentable).
Tu as une drôle de définition (ta définition répond plus au mot "rentabilité"), qui n'est pas acceptée par les "autres".
[^] # Re: Bonne initiative
Posté par Zenitram (site web personnel) . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 7.
Résultat : le contenu chiffré et la clé de déchiffrage sont exactement au même endroit, et on te demande juste de ne pas regarder quand la clé est utilisée pour déchiffrer. Par définition, il y a un problème.
Pour ton mail, on n'essaye pas de t'empêcher toi, destinataire du mail, de lire le contenu, mais ceux sur le chemin. A la différence de l'audio et vidéo des majors, sur le chemin la clé n'est pas disponible, seulement le contenu chiffré. Celui qui récupère le contenu ne peut pas déchiffrer car il n'a pas la clé.
Bref, deux situation incomparables :
- D'un côté, on a le contenu chiffré + la clé au même endroit
- de l'autre, on a juste le contenu chiffré, la clé est ailleurs.
Du coup, dans le cas du mail, que tu mette un hook dans le code pour récupérer le contenu déchiffré ne dérange pas, tu es sur ta machine, le hook ne te servira qu'à toi.
Dans le cas de l'audio et la vidéo, le hook te servira tout autant à toi que dans le cas du mail, mais les majors te considèrent comme le "pirate".
Bien faire la différence : d'un côté tu es l'utilisateur normal, de l'autre tu es le pirate sur ta propre machine (si si il y en a que ça ne dérange pas de considérer le client comme un pirate)
[^] # Re: Licence OEM
Posté par Zenitram (site web personnel) . En réponse au journal Canonical achete une licence H264. Évalué à 2.
Arghh... Me voila bien dépourvu d'un coup. OK, je retire donc, ils ont fait plus (beaucoup plus même), je dormirai plus informé ce soir (bémol tout de même : le dépêche ne dit pas si RH paye pour qu'il développer OGG/Theora ou si il fait autre chose, et que OGG/Theora est un hobby seulement)
'est plutôt injuste de mettre Debian dans le même sac, Debian est une organisation à but non-lucratif et dédié aux logiciels libres, elle n'a pas les mêmes moyens que les sociétés mentionnées.
De mon point de vue, la façon de fonctionner d'une entité la regarde, à elle de trouver le meilleur moyen pour financer des développeurs, sa façon de fonctionner ne doit pas être prise en compte quand on fait le bilan de qui a dépensé quoi pour faire avancer une technologie.
[^] # Re: Licence OEM
Posté par Zenitram (site web personnel) . En réponse au journal Canonical achete une licence H264. Évalué à 2.
PAs de soucis, Redhat fait énormément pour le libre, c'est un très gros contributeur.
Mais pas pour Theora précisément.
Canonical fait tout autant beaucoup pour le libre, avec des choses moins appréciées par les "puristes" comme faire attention à l'expérience utilisateur, mais c'est ce qui fait que bon nombre d'utilisateur de Linux sont sous Linux (et parfois avec une autre distribution qu'Ubuntu qui a été juste transitoire)
C'est trop facile : parce que Canonical fait des choses "moins pures", une minorité tape dessus, pendant qu'une majorité utilise.
Canonical a fait beaucoup pour le libre, lui refuser ça est bizarre.
Entre un Red Hat rentable et un Canonical qui perd du pognon chaque jour, je me demande si je tape réellement sur celui qui a le plus de succès...
En nombre d'utilisateurs, Canonical a plus de succès que RedHat (facile, avec le grand public ça monte vite). Peu de gens ont entendu parlé d'Ubutnu, mais encore moins de Redhat.
Succès ne veut pas dire rentabilité financière (Qui oserai dire que Facebook, Twitter, Youtube n'ont pas de succès? Ils sont dans le rouge financièrement autant que Canonical...)
[^] # Re: Licence OEM
Posté par Zenitram (site web personnel) . En réponse au journal Canonical achete une licence H264. Évalué à 2.
Comme Canonical ne peut pas tout faire non plus.
Les faits sont bien tristes : Redhat, Novell, Debian, etc... Ont fait tout autant que Canonical (=rien).
Mais bon, c'est le sport (inter)national de frapper sur celui qui a le plus de succès... Et surtout prendre un argument valide pour 2 entités, et argumenter avec cet argument pour une entité, et ne pas l'utiliser pour l'autre.
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 8.
Avant de m'insulter, tu pourrais vérifier :
http://mediainfo.sourceforge.net/fr/Download
Regarde le nombre de distributions supportées avant de dire n'importe quoi.
Pourquoi je fais ça? Car il y a des gens perdus qui trouve bien Linux sous certains côtés, mais qui pensent que le système de packaging "chacun à sa sauce" actuel, c'est la merde aussi, mais qu'ils doivent faire avec, et aiment qu'on s'occupent d'eux.
Désolé de me préoccuper des mes utilisateurs, qu'ils soient sous Windows, Linux ou Mac. Je pense à eux plutôt que de faire l'autiste "ouais, il y a autotools, vas-y" les pauvres...
Je parle de ce que je connais, de ce qui fait chier les développeurs, tu sais, les petits mecs qui produisent quelque chose, eux.
mais si tu pouvais juste arrêter de nous gonfler avec toujours les même remarques, cela _me_ ferait bien plaisir.
Le posteur du journal pose une question, j'y répond.
Je n'y peux rien si la réponse n'a pas changé depuis des lustres.
Ca ne te fait pas plaisir? Ne lit pas, ce n'est pas pour toi que j'écris.
Mais, si ton applis est potable et utile, un source qui "presque compile" est suffisant pour se retrouver partout
C'est faux, et c'est ce qui amène la question du journal d'ailleurs...
Personne ne te force à faire du linux, si tu n'aimes pas n'en fait pas, on ne t'en voudras pas, mais vient pas nous expliquer ici que c'est trop pourri.
C'est pourri, et c'est la réponse à la question du journal.
Mais si effectivement on a le droit de répondre que ce qui fait plaisir, ça ne va pas avancer.
Oui, je pointe du doigt ce qui fait mal, mais chut, faut surtout pas le dire... Faut rester dans l'idée que Linux c'est le rêve pour tout le monde, sans regarder ce que disent les utilisateurs, qui essayent Linux, puis assez souvent le fuis car "il y a rien comme logiciels sous Linux, contrairement aux mensonges de la publicité : les dépots ne contiennent pas grand chose par rapport à ce que j'aimerai" (=des petits softs idiots mais que les gens aiment...)
être libre c'est parfois difficile, c'est un choix.
On peut être libre, et savoir faire des standards entre gens civilisés. L'un n'empêche pas pas l'autre.
Chaque OS a ses défauts, Windows aussi, mais ce n'est pas parce que Windows a des défauts qu'il faut s'interdire de parler des défauts de Linux. Je te remonte les souffrances des utilisateurs et des développeurs de Linux, ceux qui développent des petites applis pour iPhone plutôt que pour Linux car Apple et Microsoft, eux, ont compris ce qui fait que ça marche : proposer un environnement de développement correct, déployable à grande échelle. Et les développeurs y vont, et les utilisateurs aussi.
Autruche, autruche... Ne surtout rien voir...
ca ne te plait pas? Moinsse moi, empêche-moi de poster sur LinuxFr, je ne ferai pas de multi pour continuer à faire ma prose. Mais en attendant, je considère le +10 du post initial plutôt comme une majorité silencieuse qui voit aussi les défauts plutôt que de faire l'autruche "il n'y a pas de problèmes avec mon OS que j'adule comme un Maqueux avec son Mac".
Car la, tu démontres une autre chose : en plus de faire l'autruche, tu ne souhaites pas qu'il y ai un respect de la liberté d'expression (je te "gonfle" comme tu dis, et tu aimerai bien me voir dégager d'ici) ni de la démocratie la plus élémentaire (les notes sont la pour montrer si oui ou non je suis "pertinent", et si je ne l'étai pas je n'aurai plus le droit de poster, malheureusement pour toi la moyenne de mes posts est largement supérieure à 2)
Pour exhausser ton souhait, une seule chose à faire : monter un kabale contre moi en mettant plus de monde qui me moinsse que de monde qui me plusse, et je partirai, en attendant je reste et je dis ce qui ne va pas, que ça te plaise ou non, et au passage, si ça ne te plait pas tu es autant libre que moi de partir.
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 2.
[^] # Re: Mémoire
Posté par Zenitram (site web personnel) . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 3.
Pour les acheteurs, ça ne l'est pas, ils regardent la taille, et prennent le plus petit (qui a du microSD comme par hasard).
L'ajout de tous les éléments "négligeables" en taille amènent à du non négligeable, la microSD fait partie des choses pour réduire la tailles.
Que tu sois pas d'accord ne changera pas le regard des acheteurs, qui préfèrent les matériels avec microSD... Tu peux rester à vouloir de la SD partout, la réalité te rattrapera car on ne va pas faire un truc énorme rien que pour quelques personnes n'aimant pas la microSD.
[^] # Re: Mémoire
Posté par Zenitram (site web personnel) . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 2.
J'ai du mal à comprendre ce qui n'est pas compréhensible la dedans : si à caractéristiques égales (écran aussi grand), on arrive à faire plus petit (moins d'épaisseur car on a pris microSD à la place de SD), pourquoi continuer avec la SD qui n'apporte rien de plus que la MicroSD et prend plus de place?
[^] # Re: Mémoire
Posté par Zenitram (site web personnel) . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 1.
La foule réclame des APN petits, et pour avoir des APN petits, il est préférable d'avoir de la microSD plutôt que de la SD.
Pour info, ça commence à passer à la microSD côté APN...
http://www.samsung.com/fr/consumer/camera-camcorder/camera/s(...)
Dans un smartphone la µSD ne se justifie pas.
Si, pour le gain de place (en épaisseur, place pour d'autres choses, au final l'appareil est plus petit, et c'est ce que l'acheteur demande)
[^] # Re: Bienvenu en France
Posté par Zenitram (site web personnel) . En réponse au journal Linux : Mandriva à vendre. Évalué à 3.
Bizarrement, on voit passer ici plein de question pour savoir si telle imprimante est compatible Linux, savoir quelle imprimante acheter pour pouvoir l'utiliser sous Linux...
C'est con, c'est tellement factuel...
[^] # Re: Bienvenu en France
Posté par Zenitram (site web personnel) . En réponse au journal Linux : Mandriva à vendre. Évalué à 3.
J'adore : comme si Mr tout le monde avait une carte SCSI...
'est quoi les petits gadgets,
Surement pas une carte "pro" très peu utilisée.
Attend, qu'est-ce que j'appellerais "gadget":
- Téléphone mobile / smartphone
- APN
- Les trucs USB qui servent à rien sauf décorer
- Des manètes de jeux
- Des cartes vidéos récentes (avec de la 3D qui marche SVP)
- Des camescopes
- Les joujous de la carte-mère achetées qui montre la vitesse des ventilo, la température...
Mais surement pas une carte SCSI...
Sinon, ta carte fonctionne sous Windows 7:
http://www.adaptec.com/en-US/support/scsi/u160/ASC-29160/
Donc pas un problème pour l'utilisateur : ça fonctionne, contrairement au gadgets, qui même en passant 2 jours dessus, ne fonctionnera pas sous Linux car le driver est dispo nul part (intégré à la distro, ou externe, non, nul part)...
Considérer une carte SCSI comme un gadget que les gens achètent en grand nombre, je rigole encore... Ca doit être une blague de linuxien!
[^] # Re: Problème des petites applis et Linux
Posté par Zenitram (site web personnel) . En réponse au journal There is no app for it. Évalué à 1.
Oups...
Autotools, j'avais carrément zappé tellement l'idée est saugrenue : l'idée que les linuxiens savent tous ce qu'est une ligne de commande et savent installer un logiciel en ligne de commande est totalement faux! Sans compter que les autotools, sans customisation pour la distro chérie de l'utilisateur, compile (si l'utilisateur sait compiler!) à la condition d'avoir toutes les dépendances préalablement installées, mais n'est pas packagée.
Le côté positif c'est qu'ainsi le package est presque fait pour toutes les distributions Linux, et même d'autres systèmes Unix (*BSD, Solaris...).
Retour à la case départ : les autotools ne savent pas quelles sont les règles de nommage de fichier et les répertoires de chaque distro. J'utilise les autotools (sinon je mourrais), mais ça ne change rien au problèmes des distros : un autotools n'est pas le package de la distro, il faut le répertoire Debian ou le fichier .spec en plus sinon ça le fait pas, il faut trouver le répertoire KDE 3 ou 4 (pas forcement le même suivant la distro) pour y mettre les liens dans le menu etc...
Les autotools, c'est bien (c'est même nécessaire!) pour fournir des sources à des développeurs, et ça, c'es très très loin pour fournir une applibre pour la cuisson des oeufs a la coque à Mme Michu...
Le côté positif c'est qu'ainsi le package est presque fait pour toutes les distributions Linux,
Un package fait juste avec les autotools??? Euh... On n'a pas eu les mêmes contacts avec les règles de packaging des distros... Ce dont tu parles, c'est de la théorie pour logiciels n'ayant besoin d'aucune dépendance (donc surtout pas un GUI!) et avec aucune intégration possible dans le bureau...
[^] # Re: Port mini USB
Posté par Zenitram (site web personnel) . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 3.
Euh... il me semblait que les mobiles avaient du Micro-USB plutôt?
C'est vraiment du mini, et pas du micro?
Ca ressemble vraiment au "mini" de cette image, et pas micro?
http://upload.wikimedia.org/wikipedia/commons/c/cb/Types-usb(...)
(mon dernier achat, Archos 5i, bien plus gros qu'un smartphone, c'est du micro USB...)
[^] # Re: Mémoire
Posté par Zenitram (site web personnel) . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 0.
Non, rien... juste un gain de taille, et c'est ce qu'on lui demande. Sont chiant c'est format à apporter ce qu'on leur demande, vraiment!
déjà bien assez petite.
Faut croire que les gens ne sont pas d'accord avec toi... Les gens achètent de plus en plus de la micro-SD, pour mettre partout : maison, ebook, téléphone portable, un seul format pour tout (essaye de mettre une carte SD dans un téléphone portable... Ca fait gigantesque!)
Pourquoi veux-tu avoir raison quand la réalité des courbes de vente te démontrent le contraire, que les gens demandent une taille plus petite, car contrairement à ce que tu affirmes, la forme SD n'est pas assez petite?