Il me semble que la licence, libre ou non libre, ne pourra jamais rien changé quant à l'incompétence de l'utilisateur lambda.
La différence, cependant, c'est que dans le cas d'un logiciel (ou format) propriétaire, seul l'éditeur originel peut aider/permettre à l'utilisateur de récupérer ses données, de les convertir, etc, alors que dans le cas libre, il suffit de demander de l'aide à quasiment n'importe quel informaticien.
Peut-être cela sera-t-il moyennant finance, mais comme la concurrence existe, d'une part il y a aura bien une personne disposée à aider, et d'autre part le tarif ne sera pas abusif.
C'est en cela qu'on ne dépend pas d'une "tierce personne" (= une tierce personne en particulier, pas un ensemble de personnes compétentes et indépendantes).
Mwai, ... mais dans le cas d'OOo, il y a antériorité (comme on l'a remarqué plus haut) ... ça va être difficile de leur demander des royalties, voire même de faire accepter le brevet.
C'est presque l'inverse qui devrait se passer. Sun (StarOffice) aurait dû déposer ce brevet, et demander des royalties à Microsoft. Mais là ce serait un peu gros, vu comme la suite est bien pompée sur celle de Microsoft (fonctionnellement), qui lui même n'a inventé ni le traitement de texte, ni le tableur, ni grand chose dans sa suite bureautique.
D'ailleurs tout ça illustre bien le danger que pourrait représenter le brevet logiciel : si personne ne pouvait piquer les idées des autres, on ne ferait plus un seul logiciel !
Lu sur http://www.dynebolic.org/index.php?show=features(...) :
# handcrafted by experienced software artisans making their own applications since years: dyne:bolic is not based on any other distribution, is unique!
Il me semble donc que cette distribution n'est pas basée sur Gentoo ...
Ou alors des archis massivement parallèles où les communications entre processeurs (qui seront de petite taille, comme tu le suggères) seront elles asynchrones.
Mais vu comme tout le monde s'arrache les cheveux à essayer de comprendre ce qui se passe dès qu'il y a du parallélisme, ça ne va pas être une partie de plaisir !!!
Ou alors des processeurs classiques munis de co-processeurs reconfigurables dynamiquement (on peut penser au FPGA, mais on m'a fait voir un truc bien plus sympa en cours d'archi : le XPP, développé par PACT Corp ... c'est plutôt conçu pour de l'informatique embarquée, mais le principe de programmer en faisant se succéder des configurations au lieu de donner des instructions séquentielles me parait excellent, un bon moyen de faire des calculs efficaces avec le peu de moyens qu'on a).
Enfin, je pense qu'augmenter la fréquence ne sera bientôt plus la solution la plus agréable.
100 GHz = 10^11 Hz --> soit une longueur d'onde de 3.10^(-3) m = 3mm
donc pour des problèmes de transmission, on sera obligé (comme aujourd'hui) d'avoir des circuits de taille bien inférieure à ceci .... allez, disons un cur de 1mm x 1mm pour être (très) gentil, contre un peu plus de 1cm x 1cm aujourd'hui.
On devra donc graver environ 10 fois plus fin, soit environ 0.01µm = 10 nm = 100 å .... soit quelques dixaines d'atomes !!!
Avec les technologies d'aujourd'hui, on est très loin d'atteindre une telle précision (où l'on commence à être embêté avec des phénomènes de nature quantique), sauf pour de petits assemblages (pas 100 millions de transistors !!!), et même là, on ne passe pas à l'échelle industrielle.
Bref ... faut arrêter d'appliquer bêtement la loi de Moore. On ne pourra obtenir de tels résultats sans une vraie rupture technologique (qui n'est pas impossible ... mais on ne peut pas la prévoir, en tout cas pas avec la loi de Moore !!!).
Et ça ne m'étonnerait pas que d'ici là, le GHz ne soit plus le critère de performance : on aura cherché, et sans doute trouvé des moyens d'améliorer la performance sans avoir à franchir ce mur. (Les idées ne manquent pas, mais tant que les procédés habituels fonctionnent, on se dit qu'il n'y a pas urgence).
(ah mais je vois que des commentaires plus loin soulèvent la même objection que moi ... allez, je poste quand-même, vu tout ce que j'ai écrit !)
Je ne suis pas spécialement d'accord avec ce post (allez, puisqu'il est à -7, je vous précise que c'est une remarque désobligeante sur l'esthétique de KDE ...), bien que ce soit une question de goût, et que cela dépende complètement du thème utilisé.
Cependant, je me rends compte d'un truc, très subjectif aussi : maintenant que OOo est "uniformisé" avec l'interface de KDE, on n'a plus l'impression d'être en face de la super appli à 36 milliards de ligne de code et 455 446 136 hommes-années de développement (ce qui justifierait son apparence "différente" dans l'esprit des gens), mais seulement d'une appli légère développée "à la va vite" en 3 clics sous QT-designer (<- que je ne critique pas, ne l'ayant jamais utilisé ;-) ).
Je précise aussi que je ne l'ai pas encore installé, et que je ne me fais guère d'illusions sur la lenteur de chargement de l'engin (j'imagine sensiblement la même que pour la version standard d'OOo).
Voilà tout ça pour dire que le rendu graphique d'une appli, ça change du tout au tout pour son image, et que ça vaut le coup d'être soigné. D'ailleurs, qui ne se dit jamais, en lançant une appli développée avec le toolkit Motif, "Mais qu'est-ce que c'est que ce vieux bouzin des années 70 ?". Je pense à pas mal d'incontournables du monde Unix, ainsi qu'à une flopée d'applications propriétaires portées des mondes Windows ou Mac, à commencer par Acrobat. Alors qu'au contraire les outils fournis par KDE, bien que moins complets, moins mâtures, et éventuellment moins fonctionnels que leurs aînés, qui font leurs preuves depuis l'enfance d'Unix, sont bien plus attrayants.
Enfin, je salue l'initiative qui permet enfin, à nous, de profiter d'un environnement à l'allure uniforme, et, à GNU/Linux, de ne plus avoir l'air d'un OS bricolé fait de brique et de broc. (Bientôt plus un Gnulinux qu'un GNU/Linux !!!). Très bon pour l'image.
P.S. : pour vous éviter de marcher dans le troll : il est clair que la plupart de ce que je dis pour KDE je le pense aussi pour Gnome, peut-être dans une moindre mesure, vu le nombre imposant de projets indépendants (souvent très complets) pour Gnome, et le peu d'applis officielles livrées directement avec gnome.
Non, non, c'est pas ça, ils tournent tous sous MultiDeskOS (145 votes!) , or XFree86, pour d'obscures histoires de licences, n'a pas été porté sur cet OS.
Dis-moi, comment c'est dehors ? Ah, tu penses que je devrais aller te rejoindre ?
Exacte certes. Ce qui n'empêche pas les multiples conventions.
"o" long -> "ou" ou "oo" ou "oh" ou "ô"
"o" long -> "uu" ou "uh" ou "û"
La convention des manuels en Français, c'est bien avec les "^".
La convention utilisée par les fansubs US, c'est plutôt celle avec les "ou" ou "uu". (Peut-être sont-ils fâchés avec les caractères non-ASCII, avec leurs claviers QWERTY-US de primitifs ;-) ). Cette représentation a l'avantage d'être proche de l'orthographe originelle avec les kanas.
De même l'orthographe française est une science exacte (difficile mais exacte), ce qui n'empêche pas de représenter le Français de plein de manières différentes en informatique (ISO latin-1, ISO latin-9, Unicode version x, Windows CP xxx ....).
Mes deux centimes d' (<-- mais comment ce dernier caractère a-t-il été codé ???).
Exemple : Ocaml peut-être au choix compilé en bytecode (~interprété) ou en native code. Et il ne me semble pas dire de bêtise en affirmant que le native code est bien le code natif de ton CPU, soit du vrai code compilé, non ?
En suite je ne vois absolument pas de limitation théorique qui empêcherait la vraie compilation d'un langage haut niveau. (Et au fait, la technologie JIT de Java, c'est pas du compilé ???)
Eclipse est un très bon logiciel qui plus est est très évolutif. J'y vois presque la nouvelle usine qui devrait remplacer Emacs (euh ... pas tapper !!!).
Bref, tout ça pour dire que si tu aimes Eclipse, c'est très bien, mais ça ne force aucunement à utiliser Java, pas plus qu'Emacs ne t'oblige à développer en elisp, car il existe de nombreux modes Eclipse pour divers langages. (même pour Eiffel !!!)
Quant à l'intérêt de Java pour la communauté libre, voir les nombreux trolls qui n'ont pas manqué de hanter les lieux --> il en ressort que développer du libre en Java n'a pas trop d'intérêt en général, même le jour où le monde propriétaire entier l'utilisera.
En effet, la principale "killer feature" est la portabilité du "bytecode", argument qui devient caduc dès que le source est disponible. Tu pointes quelques autres avantages, mais je pense qu'on peut trouver l'équivalent dans d'autres langages plus "libres". (La communauté open source connaît bien d'autres langages que "C/C++" ou "python et [...] autres langages interprétés" !!!).
Voilà pourquoi je pense que de notre point de vue, Java ne peut être guère plus qu'un langage parmi d'autres.
Voilà, c'est comme pour les autres paquetages ... sauf que là ça prend beaucoup, beaucoup de temps, et beaucoup, beaucoup d'espace disque (<ma vie> donc pas top quand on a son répertoire temporaire dans une petite partition ... </ma vie>).
Il y a un ebuild pour la version fr sous Gentoo ?
Je ne le vois pas quand je fais un "emerge -s openoffice".
Que je sache, le paquetage openoffice-bin est bien uniquement en anglais ?
(Alors, tu t'es tappé toute la compilation d'OpenOffice.org ?)
Il me semble quand même que l'on ne peut pas comparer les ordinateurs aux voitures sur ce point : en effet, un PC qui supporte un périphérique sous Windows, est tout à fait bien constitué physiquement pour accueillir ce même périphérique sous Linux (changer la personne derrière le volant ne change pas le carburant utilisé, hein ?).
D'autant plus que si le constructeur faisait preuve d'un minimum de bonne volonté en rendant disponibles ses specs d'interfaçage, le support officieux pour Linux ne lui coûterait pas un rond, tant les développeurs libres seront "heureux" de se jeter dessus.
Effectivement, ce n'est pas compliqué de ne pas se tromper (quoiqu'on aie souvent l'espoir qu'un périph acheté sans support officiel de Linux se retrouve supporté dans un avenir proche, ou déjà supporté officieusement ... c'est comme ça que je me suis fait @#!!# en achetant une Logitech Quickcam Messenger), mais il y a quand même de quoi râler de se retrouver restreint dans le choix de son matos par des raisons aussi superficielles que celles-ci.
Voilà mes deux centimes ... (déjà beaucoup plus que le coût du support d'un périph sous Linux ;-) )
Je pense que l'idée de Philippe de réaliser une doc accessible au commun des mortels sur tous ces sujets brûlants serait une très bonne chose.
Le problème c'est que ce n'est pas chose facile et personne ne sait par où commencer ni ne sait comment être exhaustif.
Que penseriez-vous donc d'un wiki animé par la communauté du libre, le tout sur un site sur le modèle de Wikipedia ?
La doc au début incomplète se bonifierait et se clarifierait au fur et à mesure des contributions, et aurait l'immense avantage de ne jamais tomber dans l'obsolescence.
Quelqu'un aurait entendu parler d'un embryon de projet dans le genre ?
Le Caml parait difficile si tu as été habitué à programmer dans d'autres langages. N'étant pas habitué à programmer lorsque j'ai appris le Caml, celui-ci ne pas spécialement choqué. Pire, on finit par prendre du plaisir à implémenter des algos complexes en une poignée de lignes de code, le tout de manière tout à fait élégante.
Mais mon principal point de désaccord porte sur la lisibilité. A l'heure d'aujourd'hui je dois avoir autant (voire un chouilla plus) d'expérience en Java qu'en Caml, et le sens d'un programme Caml me saute toujours bien plus vite aux yeux (concision, approche fonctionnelle ...).
Je crois que le problème c'est d'arrêter deux secondes de penser itératif pour penser fonctionnel (on oublie les variables, les séquences, les for et les while .... ).
Ma seule conclusion objective : la "non-lisibilté" de Caml ne peut que provenir des habitudes bien trop répandues de programmation impérative (ou alors objet).
[^] # Re: Pourquoi le Libre va changer le monde
Posté par Aldoo . En réponse à la dépêche Pourquoi le Libre va changer le monde. Évalué à 3.
La différence, cependant, c'est que dans le cas d'un logiciel (ou format) propriétaire, seul l'éditeur originel peut aider/permettre à l'utilisateur de récupérer ses données, de les convertir, etc, alors que dans le cas libre, il suffit de demander de l'aide à quasiment n'importe quel informaticien.
Peut-être cela sera-t-il moyennant finance, mais comme la concurrence existe, d'une part il y a aura bien une personne disposée à aider, et d'autre part le tarif ne sera pas abusif.
C'est en cela qu'on ne dépend pas d'une "tierce personne" (= une tierce personne en particulier, pas un ensemble de personnes compétentes et indépendantes).
[^] # Re: Je crois que tu as mal compris la news
Posté par Aldoo . En réponse à la dépêche Microsoft, les brevets et les formats ouverts.... Évalué à 2.
C'est presque l'inverse qui devrait se passer. Sun (StarOffice) aurait dû déposer ce brevet, et demander des royalties à Microsoft. Mais là ce serait un peu gros, vu comme la suite est bien pompée sur celle de Microsoft (fonctionnellement), qui lui même n'a inventé ni le traitement de texte, ni le tableur, ni grand chose dans sa suite bureautique.
D'ailleurs tout ça illustre bien le danger que pourrait représenter le brevet logiciel : si personne ne pouvait piquer les idées des autres, on ne ferait plus un seul logiciel !
# Re: Du nouveau du coté des live distros : LinuxConsole 0.4, Dynebolic GNU/Linux 1.3 Stable et Agnula/Demudi 1.1.1 à la Linux Audio 2004
Posté par Aldoo . En réponse à la dépêche Du nouveau du coté des live distros : LinuxConsole 0.4, Dynebolic GNU/Linux 1.3 Stable et Agnula/Demudi 1.1.1 à la Linux Audio 2004. Évalué à 1.
# handcrafted by experienced software artisans making their own applications since years: dyne:bolic is not based on any other distribution, is unique!
Il me semble donc que cette distribution n'est pas basée sur Gentoo ...
[^] # Re: OpenOffice.org 1.1.1 pour kde
Posté par Aldoo . En réponse à la dépêche OpenOffice.org 1.1.1 pour KDE. Évalué à 1.
Est-ce qu'on perd beaucoup de fonctionnalités en lui demandant de ne pas l'utiliser ?
[^] # Re: 100 Ghz.....pour écrire son CV ?
Posté par Aldoo . En réponse au journal 100 Ghz.....pour écrire son CV ?. Évalué à 1.
Mais vu comme tout le monde s'arrache les cheveux à essayer de comprendre ce qui se passe dès qu'il y a du parallélisme, ça ne va pas être une partie de plaisir !!!
Ou alors des processeurs classiques munis de co-processeurs reconfigurables dynamiquement (on peut penser au FPGA, mais on m'a fait voir un truc bien plus sympa en cours d'archi : le XPP, développé par PACT Corp ... c'est plutôt conçu pour de l'informatique embarquée, mais le principe de programmer en faisant se succéder des configurations au lieu de donner des instructions séquentielles me parait excellent, un bon moyen de faire des calculs efficaces avec le peu de moyens qu'on a).
Enfin, je pense qu'augmenter la fréquence ne sera bientôt plus la solution la plus agréable.
[^] # La loi de Moore fait long feu ...
Posté par Aldoo . En réponse au journal 100 Ghz.....pour écrire son CV ?. Évalué à 5.
donc pour des problèmes de transmission, on sera obligé (comme aujourd'hui) d'avoir des circuits de taille bien inférieure à ceci .... allez, disons un cur de 1mm x 1mm pour être (très) gentil, contre un peu plus de 1cm x 1cm aujourd'hui.
On devra donc graver environ 10 fois plus fin, soit environ 0.01µm = 10 nm = 100 å .... soit quelques dixaines d'atomes !!!
Avec les technologies d'aujourd'hui, on est très loin d'atteindre une telle précision (où l'on commence à être embêté avec des phénomènes de nature quantique), sauf pour de petits assemblages (pas 100 millions de transistors !!!), et même là, on ne passe pas à l'échelle industrielle.
Bref ... faut arrêter d'appliquer bêtement la loi de Moore. On ne pourra obtenir de tels résultats sans une vraie rupture technologique (qui n'est pas impossible ... mais on ne peut pas la prévoir, en tout cas pas avec la loi de Moore !!!).
Et ça ne m'étonnerait pas que d'ici là, le GHz ne soit plus le critère de performance : on aura cherché, et sans doute trouvé des moyens d'améliorer la performance sans avoir à franchir ce mur. (Les idées ne manquent pas, mais tant que les procédés habituels fonctionnent, on se dit qu'il n'y a pas urgence).
(ah mais je vois que des commentaires plus loin soulèvent la même objection que moi ... allez, je poste quand-même, vu tout ce que j'ai écrit !)
[^] # Re: OpenOffice.org 1.1.1 pour kde
Posté par Aldoo . En réponse à la dépêche OpenOffice.org 1.1.1 pour KDE. Évalué à 6.
Cependant, je me rends compte d'un truc, très subjectif aussi : maintenant que OOo est "uniformisé" avec l'interface de KDE, on n'a plus l'impression d'être en face de la super appli à 36 milliards de ligne de code et 455 446 136 hommes-années de développement (ce qui justifierait son apparence "différente" dans l'esprit des gens), mais seulement d'une appli légère développée "à la va vite" en 3 clics sous QT-designer (<- que je ne critique pas, ne l'ayant jamais utilisé ;-) ).
Je précise aussi que je ne l'ai pas encore installé, et que je ne me fais guère d'illusions sur la lenteur de chargement de l'engin (j'imagine sensiblement la même que pour la version standard d'OOo).
Voilà tout ça pour dire que le rendu graphique d'une appli, ça change du tout au tout pour son image, et que ça vaut le coup d'être soigné. D'ailleurs, qui ne se dit jamais, en lançant une appli développée avec le toolkit Motif, "Mais qu'est-ce que c'est que ce vieux bouzin des années 70 ?". Je pense à pas mal d'incontournables du monde Unix, ainsi qu'à une flopée d'applications propriétaires portées des mondes Windows ou Mac, à commencer par Acrobat. Alors qu'au contraire les outils fournis par KDE, bien que moins complets, moins mâtures, et éventuellment moins fonctionnels que leurs aînés, qui font leurs preuves depuis l'enfance d'Unix, sont bien plus attrayants.
Enfin, je salue l'initiative qui permet enfin, à nous, de profiter d'un environnement à l'allure uniforme, et, à GNU/Linux, de ne plus avoir l'air d'un OS bricolé fait de brique et de broc. (Bientôt plus un Gnulinux qu'un GNU/Linux !!!). Très bon pour l'image.
P.S. : pour vous éviter de marcher dans le troll : il est clair que la plupart de ce que je dis pour KDE je le pense aussi pour Gnome, peut-être dans une moindre mesure, vu le nombre imposant de projets indépendants (souvent très complets) pour Gnome, et le peu d'applis officielles livrées directement avec gnome.
[^] # Re: Pierre Tramo
Posté par Aldoo . En réponse au journal Pierre Tramo. Évalué à 1.
[^] # Re: Mon projet libre préféré
Posté par Aldoo . En réponse au sondage Mon projet libre préféré. Évalué à 1.
Dis-moi, comment c'est dehors ? Ah, tu penses que je devrais aller te rejoindre ?
[^] # Re: Pierre Tramo
Posté par Aldoo . En réponse au journal Pierre Tramo. Évalué à 1.
[^] # Re: Kiki, la petite sorcière
Posté par Aldoo . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 1.
[^] # Re: Kiki, la petite sorcière
Posté par Aldoo . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 1.
"o" long -> "ou" ou "oo" ou "oh" ou "ô"
"o" long -> "uu" ou "uh" ou "û"
La convention des manuels en Français, c'est bien avec les "^".
La convention utilisée par les fansubs US, c'est plutôt celle avec les "ou" ou "uu". (Peut-être sont-ils fâchés avec les caractères non-ASCII, avec leurs claviers QWERTY-US de primitifs ;-) ). Cette représentation a l'avantage d'être proche de l'orthographe originelle avec les kanas.
De même l'orthographe française est une science exacte (difficile mais exacte), ce qui n'empêche pas de représenter le Français de plein de manières différentes en informatique (ISO latin-1, ISO latin-9, Unicode version x, Windows CP xxx ....).
Mes deux centimes d' (<-- mais comment ce dernier caractère a-t-il été codé ???).
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Aldoo . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Ok, je veux bien, mais dans ce cas, il faudra attendre au moins 2007 ;-)
(et ça, c'est seulement si tout le monde à compris d'ici là que ce n'est pas possible avec l'équipe qui nous gouverne aujourd'hui !!!)
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Aldoo . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Exemple : Ocaml peut-être au choix compilé en bytecode (~interprété) ou en native code. Et il ne me semble pas dire de bêtise en affirmant que le native code est bien le code natif de ton CPU, soit du vrai code compilé, non ?
En suite je ne vois absolument pas de limitation théorique qui empêcherait la vraie compilation d'un langage haut niveau. (Et au fait, la technologie JIT de Java, c'est pas du compilé ???)
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Aldoo . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
Bref, tout ça pour dire que si tu aimes Eclipse, c'est très bien, mais ça ne force aucunement à utiliser Java, pas plus qu'Emacs ne t'oblige à développer en elisp, car il existe de nombreux modes Eclipse pour divers langages. (même pour Eiffel !!!)
Quant à l'intérêt de Java pour la communauté libre, voir les nombreux trolls qui n'ont pas manqué de hanter les lieux --> il en ressort que développer du libre en Java n'a pas trop d'intérêt en général, même le jour où le monde propriétaire entier l'utilisera.
En effet, la principale "killer feature" est la portabilité du "bytecode", argument qui devient caduc dès que le source est disponible. Tu pointes quelques autres avantages, mais je pense qu'on peut trouver l'équivalent dans d'autres langages plus "libres". (La communauté open source connaît bien d'autres langages que "C/C++" ou "python et [...] autres langages interprétés" !!!).
Voilà pourquoi je pense que de notre point de vue, Java ne peut être guère plus qu'un langage parmi d'autres.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Aldoo . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à -3.
oops, je m'emporte.
Bon, fallait pas ouvrir si grand la ----->[] !
[^] # Re: Dictionnaire des idées reçues
Posté par Aldoo . En réponse au journal Dictionnaire des idées reçues. Évalué à 1.
[^] # Re: Dictionnaire des idées reçues
Posté par Aldoo . En réponse au journal Dictionnaire des idées reçues. Évalué à 1.
[^] # Re: OpenOffice 1.1.1 française est sortie
Posté par Aldoo . En réponse à la dépêche OpenOffice 1.1.1 française est sortie. Évalué à 1.
Mode d'emploi :
http://www.gentoo.org/doc/fr/guide-localization.xml(...)
Voilà, c'est comme pour les autres paquetages ... sauf que là ça prend beaucoup, beaucoup de temps, et beaucoup, beaucoup d'espace disque (<ma vie> donc pas top quand on a son répertoire temporaire dans une petite partition ... </ma vie>).
[^] # Re: OpenOffice 1.1.1 française est sortie
Posté par Aldoo . En réponse à la dépêche OpenOffice 1.1.1 française est sortie. Évalué à 1.
Je ne le vois pas quand je fais un "emerge -s openoffice".
Que je sache, le paquetage openoffice-bin est bien uniquement en anglais ?
(Alors, tu t'es tappé toute la compilation d'OpenOffice.org ?)
[^] # Re: respect lois US, licence France
Posté par Aldoo . En réponse à la dépêche Microsoft se met à l'open-source. Évalué à 5.
license (en_US)
licence (fr/en_UK)
J'ai dû démêler cette histoire l'autre jour en écrivant mon CV ;)
[^] # Re: Sortie du redressement judiciaire de MandrakeSoft
Posté par Aldoo . En réponse à la dépêche Sortie du redressement judiciaire de MandrakeSoft. Évalué à 1.
[^] # Re: Tentative de support des Webcams USB basées sur les puces ZC030X
Posté par Aldoo . En réponse à la dépêche Tentative de support des Webcams USB basées sur les puces ZC030X. Évalué à 2.
D'autant plus que si le constructeur faisait preuve d'un minimum de bonne volonté en rendant disponibles ses specs d'interfaçage, le support officieux pour Linux ne lui coûterait pas un rond, tant les développeurs libres seront "heureux" de se jeter dessus.
Effectivement, ce n'est pas compliqué de ne pas se tromper (quoiqu'on aie souvent l'espoir qu'un périph acheté sans support officiel de Linux se retrouve supporté dans un avenir proche, ou déjà supporté officieusement ... c'est comme ça que je me suis fait @#!!# en achetant une Logitech Quickcam Messenger), mais il y a quand même de quoi râler de se retrouver restreint dans le choix de son matos par des raisons aussi superficielles que celles-ci.
Voilà mes deux centimes ... (déjà beaucoup plus que le coût du support d'un périph sous Linux ;-) )
[^] # Re: EUCD, LEN, LIL : offensive annoncée après les régionales
Posté par Aldoo . En réponse à la dépêche EUCD, LEN, LIL : offensive annoncée après les régionales. Évalué à 2.
Le problème c'est que ce n'est pas chose facile et personne ne sait par où commencer ni ne sait comment être exhaustif.
Que penseriez-vous donc d'un wiki animé par la communauté du libre, le tout sur un site sur le modèle de Wikipedia ?
La doc au début incomplète se bonifierait et se clarifierait au fur et à mesure des contributions, et aurait l'immense avantage de ne jamais tomber dans l'obsolescence.
Quelqu'un aurait entendu parler d'un embryon de projet dans le genre ?
[^] # Re: On oublie toujours OCaml
Posté par Aldoo . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 2.
Mais mon principal point de désaccord porte sur la lisibilité. A l'heure d'aujourd'hui je dois avoir autant (voire un chouilla plus) d'expérience en Java qu'en Caml, et le sens d'un programme Caml me saute toujours bien plus vite aux yeux (concision, approche fonctionnelle ...).
Je crois que le problème c'est d'arrêter deux secondes de penser itératif pour penser fonctionnel (on oublie les variables, les séquences, les for et les while .... ).
Ma seule conclusion objective : la "non-lisibilté" de Caml ne peut que provenir des habitudes bien trop répandues de programmation impérative (ou alors objet).