Plébicité? Tu plaisante! Ce changement vient des vendeurs de portables qui voulaient baisser les coûts (bin oui, quand tu utilise le même aspect ratio pour des TV et des portables il y a moins de pertes).
Le "plébicite" vient seulement du fait que les gens n'achètent pas si c'est trop cher: il n'y a qu'à voir le prix d'un portable avec un écran 1900*1200: ça calme..
Note pour tant premier cas, mettre à jour le noyau c'est, paradoxalement, probablement ce qu'il y a de moins risqué Linus prenant très au sérieux la compatibilité ascendante.
Enfin il y a des gros loupés parfois quand même: je me souviens qu'il a intégré des changements dans les options de montage par défaut des FS, ce qui me parait plutôt malsain.
Ça renforce les idées d'Ingo Molnar, maintenant à partir du moment ou les distributions Linux ne sont pas fichu de se mettre d'accord sur un (et un seul) jeux d'outil pour le packaging, j'ai comme un doute pour maintenir une API "desktop" commune.
J'ai la solution à ton problème: Arrête les mises à jour !
Oui, enfin vu la stabilité des API desktops sur Linux, le jour où il voudra utiliser une nouvelle application ça risque fort de ne pas marcher!
Je pense que son problème est d'avoir utiliser Kubuntu: un exemple Kubuntu est passé en KDE4 par défaut avec la version 4.1.2, PCLinuxOS est passé à KDE4 avec la version 4.4.2 ET ils ont désactivé Nepomuk par défaut.
Bref, il y a des distributions qui se prétendent "grand public" et d'autres qui le sont..
Soit dit en passant, c'est quand même malheureux que le projet KDE ne soit pas fichu de définir par eux-même un sous-ensemble stable de leur projet mais que ce sont les distributions qui fassent le boulot..
Tiens oui, homoiconique et fonctionnel ça correspond bien à XSLT, un des langages les plus pourris que j'ai jamais vu (si, si, le langage que j'ai du utiliser avec des noms de variable restreint a 1 caractère était plus lisible).
Et qu'on fasse ça ne changera pas.
Personnellement je préfère le bulletin à case ou tu peux cocher de 0 à tout les candidats: simple et n'a pas les défauts du scrutin majoritaire.
L'unité de récompense dans les universités c'est le papier publiés, pas le patch dans le kernel.
Donc ce n'est pas tellement surprenant qu'il y ait peu de contributions académiques.
Ceci dit, il y a aussi des recherches très intéressante par exemple il y a http://blog.regehr.org/ (qui montre d'ailleurs a quel point le C c'est pourri) qui peuvent aider beaucoup (parce que les bugs des compilateurs ça fait mal), même s'il n'y a pas de patch dans Linux..
Posté par reno .
En réponse au journal Go 1.
Évalué à 2.
Enfin un descendant de C qui se départit des maladresses de son aïeul,
Bof, tu ne peux toujours pas supposer que x est inférieur à x + 1 est vrai, ni que abs(x) retourne un entier positif (enfin je pense, je n'ai pas trouvé la version pour un entier).
Pas terrible pour un "descendant de C qui se départit des maladresses de son aïeul"!
Posté par reno .
En réponse au journal Go 1.
Évalué à 10.
Personnellement je déteste ces précédences stupides (je parle du C ET de Go): les seules précédences qui ont un sens c'est celle qu'on a appris en math (+ - * /),
le reste ça devrait échouer a la compilation pour forcer a mettre des parenthèses!
3 | 2 + 1 --> erreur de compilation: le programmeur doit mettre '(3 | 2) + 1' ou '3 | (2 + 1)'.
Regarde ce qu'il se passent avec X, plus personne ne veut le faire évoluer pour gérer des trucs qui existent comme deux cartes graphiques
Si Wayland avait existé avant les dual GPUs, je me demande si ça aurait été plus simple de le changer qu'X? Pas si sûr..
ou corriger des bugs visuels comme les fenêtres qui clignotes quand ont les redimensionnent.
Là, c'est un compromis: redimensionner une fenêtre coté serveur fluide mais moche(1) ou bien redimensionner coté client/application: joli mais saccadé(1), franchement pas sûr que 'joli mais saccadé' soit mieux!
Le kernel a beaucoup plus de main d'œuvre que les desktops
Bah, c'est surtout une question de volonté: si tu ajoute la compatibilité ascendante dans les desktop ça va ralentir les nouveaux developpement et les dev desktop ne veulent pas s’embêter avec ça.. Je comprends: ça doit être pénible, mais bon on en est à la combientième ré-invention majeure des desktops KDE et Gnome? 3 chacun?
Et c'est loin d'être fini..
Et puis tu peux faire tourner des applis avec des version de lib différentes
Heuh:
1) il me semble que ça ne marche pas si facilement que ça
2) s'il n'y a pas compatibilité avec le bureau, pourquoi avoir un bureau intégré dans ce cas?
Autant rester au gestionnaire de fenêtre simple..
[^] # Re: stable != up-to-date
Posté par reno . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 3.
Oui, enfin Fedora comme distribution pour avoir la stabilité, ça ne compte pas trop..
Une question: pourquoi RedHat/CentOS ne t'a pas convenu?
Coté stabilité ça marche pas mal je trouve..
[^] # Re: Windows
Posté par reno . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 2.
Plébicité? Tu plaisante! Ce changement vient des vendeurs de portables qui voulaient baisser les coûts (bin oui, quand tu utilise le même aspect ratio pour des TV et des portables il y a moins de pertes).
Le "plébicite" vient seulement du fait que les gens n'achètent pas si c'est trop cher: il n'y a qu'à voir le prix d'un portable avec un écran 1900*1200: ça calme..
[^] # Re: If it ain't broken, don't fix it.
Posté par reno . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 2.
Note pour tant premier cas, mettre à jour le noyau c'est, paradoxalement, probablement ce qu'il y a de moins risqué Linus prenant très au sérieux la compatibilité ascendante.
Enfin il y a des gros loupés parfois quand même: je me souviens qu'il a intégré des changements dans les options de montage par défaut des FS, ce qui me parait plutôt malsain.
[^] # Re: If it ain't broken, don't fix it.
Posté par reno . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 2.
Compréhensible, mais triste non?
Ça renforce les idées d'Ingo Molnar, maintenant à partir du moment ou les distributions Linux ne sont pas fichu de se mettre d'accord sur un (et un seul) jeux d'outil pour le packaging, j'ai comme un doute pour maintenir une API "desktop" commune.
[^] # Re: If it ain't broken, don't fix it.
Posté par reno . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 3.
Compréhensible, mais triste non?
[^] # Re: If it ain't broken, don't fix it.
Posté par reno . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 2.
Oui, enfin vu la stabilité des API desktops sur Linux, le jour où il voudra utiliser une nouvelle application ça risque fort de ne pas marcher!
Je pense que son problème est d'avoir utiliser Kubuntu: un exemple Kubuntu est passé en KDE4 par défaut avec la version 4.1.2, PCLinuxOS est passé à KDE4 avec la version 4.4.2 ET ils ont désactivé Nepomuk par défaut.
Bref, il y a des distributions qui se prétendent "grand public" et d'autres qui le sont..
Soit dit en passant, c'est quand même malheureux que le projet KDE ne soit pas fichu de définir par eux-même un sous-ensemble stable de leur projet mais que ce sont les distributions qui fassent le boulot..
[^] # Re: donc en gros
Posté par reno . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 9.
Ce qui revient à dire que KDE n'est pas stable..
[^] # Re: Philosophie du hack
Posté par reno . En réponse au journal L'anthropologie des hackers. Évalué à 2.
La faim c'est une valeur?
[^] # Re: Langages XML
Posté par reno . En réponse au message Recherche d'un langage dit fonctionnel et homo-iconique.. Évalué à 2.
Tiens oui, homoiconique et fonctionnel ça correspond bien à XSLT, un des langages les plus pourris que j'ai jamais vu (si, si, le langage que j'ai du utiliser avec des noms de variable restreint a 1 caractère était plus lisible).
# Fedora s'est posé la question récemment
Posté par reno . En réponse au journal Chaine(s) de compilation ARM. Évalué à 1.
Le problème vient des temps de compilations en natif très long: http://lwn.net/Articles/487622/
# Julia?
Posté par reno . En réponse au message Recherche d'un langage dit fonctionnel et homo-iconique.. Évalué à 2.
Homo-iconique et typage fort en option: http://linuxfr.org/news/version-1-0-de-julia
# Voter *est* stratégique
Posté par reno . En réponse au journal Voter autrement. Évalué à 4.
Et qu'on fasse ça ne changera pas.
Personnellement je préfère le bulletin à case ou tu peux cocher de 0 à tout les candidats: simple et n'a pas les défauts du scrutin majoritaire.
# C'est sûr que mouler c'est beaucoup mieux!
Posté par reno . En réponse au journal La télé nous a rendu con!. Évalué à 1.
NT
[^] # Re: Contributeurs académiques
Posté par reno . En réponse au journal Microsoft, un sacré contributeur au noyau Linux !. Évalué à 3.
L'unité de récompense dans les universités c'est le papier publiés, pas le patch dans le kernel.
Donc ce n'est pas tellement surprenant qu'il y ait peu de contributions académiques.
Ceci dit, il y a aussi des recherches très intéressante par exemple il y a http://blog.regehr.org/ (qui montre d'ailleurs a quel point le C c'est pourri) qui peuvent aider beaucoup (parce que les bugs des compilateurs ça fait mal), même s'il n'y a pas de patch dans Linux..
[^] # Re: Quel avenir?
Posté par reno . En réponse au journal Go 1. Évalué à 2.
Le possessif n'est pas obligatoire en Anglais: a pointer to an array of 4 int.
Il y a probablement des langues où ce n'est pas le bon ordre, mais l'Anglais est la langue de l'informatique..
[^] # Re: Gni???
Posté par reno . En réponse au journal Munich économise 4 Millions par an avec Linux. Évalué à 2.
Uhm, je suis un peu sceptique: tu utilisais quoi comme navigateur web?
Ça bouffe ces engins!
[^] # Re: Quel avenir?
Posté par reno . En réponse au journal Go 1. Évalué à 8.
C'est moche mais ça se lit très bien: un pointeur vers un tableau de 4 entiers.
Beaucoup plus simple a comprendre que la version en C!
[^] # Deuxième essai
Posté par reno . En réponse au journal Go 1. Évalué à 2.
Bof, tu ne peux toujours pas supposer que x est inférieur à x + 1 est vrai, ni que abs(x) retourne un entier positif (enfin je pense, je n'ai pas trouvé la version pour un entier).
Pas terrible pour un "descendant de C qui se départit des maladresses de son aïeul"!
[^] # Re: Quel avenir?
Posté par reno . En réponse au journal Go 1. Évalué à 2.
Si tous le monde respectait ces règles oui..
Mais alors dans ce cas pourquoi ne pas avoir un langage qui force a respecter ces regles?
[^] # Re: Quel avenir?
Posté par reno . En réponse au journal Go 1. Évalué à 1.
Bof, tu ne peux toujours pas supposer que 'x Pas terrible pour un "descendant de C qui se départit des maladresses de son aïeul".
[^] # Re: Quel avenir?
Posté par reno . En réponse au journal Go 1. Évalué à 10.
Personnellement je déteste ces précédences stupides (je parle du C ET de Go): les seules précédences qui ont un sens c'est celle qu'on a appris en math (+ - * /),
le reste ça devrait échouer a la compilation pour forcer a mettre des parenthèses!
3 | 2 + 1 --> erreur de compilation: le programmeur doit mettre '(3 | 2) + 1' ou '3 | (2 + 1)'.
[^] # Re: A eux de jouer
Posté par reno . En réponse au journal Kernel en 32 bits ou en 64 bits (un journal bookmark). Évalué à 2.
Des toolkits avec beaucoup de fonctionnalités OK mais: il leur a fallu combien de temps pour supporter XCB? Supportent-ils le redémarrage d'X?
# La NImage de l'article ..
Posté par reno . En réponse au journal Le retour de MeeGo. Évalué à 7.
.. est juste énorme!
[^] # Re: A eux de jouer
Posté par reno . En réponse au journal Kernel en 32 bits ou en 64 bits (un journal bookmark). Évalué à 3.
Si Wayland avait existé avant les dual GPUs, je me demande si ça aurait été plus simple de le changer qu'X? Pas si sûr..
Là, c'est un compromis: redimensionner une fenêtre coté serveur fluide mais moche(1) ou bien redimensionner coté client/application: joli mais saccadé(1), franchement pas sûr que 'joli mais saccadé' soit mieux!
1: si le client est lent a repeindre.
[^] # Re: A eux de jouer
Posté par reno . En réponse au journal Kernel en 32 bits ou en 64 bits (un journal bookmark). Évalué à 3.
Bah, c'est surtout une question de volonté: si tu ajoute la compatibilité ascendante dans les desktop ça va ralentir les nouveaux developpement et les dev desktop ne veulent pas s’embêter avec ça.. Je comprends: ça doit être pénible, mais bon on en est à la combientième ré-invention majeure des desktops KDE et Gnome? 3 chacun?
Et c'est loin d'être fini..
Heuh:
1) il me semble que ça ne marche pas si facilement que ça
2) s'il n'y a pas compatibilité avec le bureau, pourquoi avoir un bureau intégré dans ce cas?
Autant rester au gestionnaire de fenêtre simple..