CrEv a écrit 4577 commentaires

pourtant, il n'y a pas si longtemps (la 4.2 c'est pas vraiment loin...) la config la plus courante était justement celle avec le dock (et c'est franchement la plus pratique je trouve).
En tout cas c'est l'impression que j'ai.

Le passage vers une interface ala gnome ne viendrait pas de certaines distribs voulant tout uniformiser ? (à ce moment je ne vois plus du tout l'intérêt)
J'ai souvent entendu par exemple que Xubuntu était en fait très portée gnome, que ce soit dans le style ou dans le choix des applis.

(maintenant, avoir peur de cde ça ne m'étonne pas, mais bon ça fait quand même un moment que c'est plus trop utilisé....)

Dans ce cas, j'ai une suggestion justement (mais tout d'abord, merci à tous ceux qui ont permis cette live XFCE !)

Pourquoi utiliser par défaut cette configuration très "gnomiène" ?
Pourquoi ne pas utiliser une configuration plus "xfce", comme ont la trouvait il n'y a pas si longtemps (un screenshot de la 4.2 qui reprend un peu ce que je veux dire : http://www.xfce.org/images/about/screenshots/4.2-5.jpg ) ?

En fait, je trouve que l'accent est (visuellement tout du moins) beaucoup trop mis sur un gnome light alors que xfce est beaucoup plus que ça. Le dock avec son système de tiroirs est vraiment intéressant et mérite je pense de s'y attarder.
De même, la barre d'applications n'est pas si utile si on prend en compte l'applet permettant d'avoir les icones de programmes ouverts (plus parlant que la barre je trouve).

M'enfin voilà, je trouve que ce point n'est pas très bon, à part ça longue vie à XFCE ;-)

tout comme les softs sous BSD...
Un code publié sos BSD sera a jamais disponible sous BSD
Il n'est possible de changer la licence que pour les versions futures

Si j'écris un code sous GPL (en ayant donc le "copyright") je peux très bien le refermer pour les prochaines versions ... tout comme la BSD

Et d'un côté plus "trollesque", heureusement pour l'ecosystème linux que certaines personnes codent sous licences BSD, MIT, ... pour pouvoir intégrer ces codes sans se poser trop de question en GPL (oui je sais, le raccourcis linux gpl est un peu rapide...)

ha mais je comprend bien que les développeurs se sentent lésés.
Mais c'est bien le principe de la GPL (pas de se sentir lésé) que de permetre de modifier le programme y compris sous d'autres os.
Mais là où je pense que tu fais erreur c'est que tu y vois comme solution d'avoir une licence encore plus restrictive.
Alors que pour ma part, le problèmes est qu'il n'a jamais été garanti que ça marche sur un os libre (je parle bien de garantie, d'obligations)
Et il serait même possible de remplacer tous les développement par d'autres logiciels, non ? (s'ils sont capable de virer linux pour mettre xp, je vois pu trop le problème)

Mais comme tu le dis, contrairement à firefox, openoffice, ... où C'est clair au départ ici rien n'était définitivement clair...

heureusement que les gars de openoffice, firefox et tous les autres projets ne réfléchissent pas comme ça...

Pour moi le logiciel libre est un vecteur de ... liberté.
Qu'ils soient sous un os ou un autre, un logiciel libre est libre et permet à l'utilisateur d'être plus libre.
Qu'il y ait des choix d'os sur critères techniques, je le comprend tout à fait.
Qu'il y ait des préférences d'OS sur des choix étiques, je le comprend tout à fait.
Mais de là à vouloir empêcher une application de tourner sur un autre système...

Le truc c'est que tu confond la licence du logiciel avec le but du projet.

Dans le cas de l'olpc, ça devrait être au niveau du projet que les règles devraient être définis, par exemple : tous les développements doivent être sous licence libre, et le système d'exploitation également.
Et ça suffirait pour que ça marche, mais surtout ça n'enlèverait pas la possibilité à d'autres personnes de porter les applications sur d'autres systèmes et de l'offrir par la même à plus de monde, ce que je trouverais très bien.

C'était l'argument tordu utilisé par ces $@%£! de KDE

Et heureusement que ces $@%£! de KDE ont fait ça pour booster un peu les environnements de bureau qui était juste un petit peu à la traine.
Et heureusement que ces $@%£! de KDE ont fait ça pour que GNOME puisse exister (qui n'est, à la base, qu'une réponse au côté fermé de QT dans KDE)
KDE avait choisis QT car c'était techniquement la meilleur solution, ce qui a été démontré par la suite ainsi que le fait qu'une boite pouvait, sous l'impulsion de projets open sources, libérer leur code et le releaser en GPL.

Franchement, si tu attends vraiment une réponse y'a peut-être moyen de poser la question autrement...

d'ailleurs, concernant l'installation, c'est plutôt ubuntu qui est encore en retard...
L'installeur graphique d'ubuntu est sorti avec les version 6.06
J'ai le souvenir d'installations graphiques avec une mandriva 7.2 ou 8.0, soit en ... fin 2000 début 2001. Et surtout, un outil de partitionnement particulièrement puissant et bien fait (qui est toujours au dessus du lot pour ce point précis)

Ce qu'ubuntu apporte (en tout cas c'est ce qui je pense fait que cette distrib plait) c'est qu'elle laisse initialement peu de choix et que ces choix sont relativement bien pensés et permettent d'avoir directement un bureau assez sympa.
D'un autre côté, certaines distributions proposent presque trop de choix, trop fouilli.

Mais au niveau facilité, faut arrêter. Depuis quand Ubuntu a un outil pour gérer les écrans ?
Depuis quand est NetworkManager ?
etc

Pourquoi est-ce que Mandriva n'arrive toujours pas à sortir la tête de l'eau ?

Ptetre parce que certaines distrib n'ont justement pas à ce poser cette question (pour combien de temps encore...) et bénéficie d'un gentil donateur ce qui leur permet même de balancer des cds gratos...

oui mais non

Bochs est un émulateur x86 et non une solution de virtualisation
Qemu l'est également mais peut être agrémenté d'un noyau jouant le rôle d'accélérateur (il ne fait "que" balancer les instructions qu'il peut au proc sans passer par l'émulation, me souvient plus exactement du nom
Kernel-based_Virtual_Machine lui fait vraiment de la virtualisation mais se base sur une version modifiée de QEmu

Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données,
Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...

Moi ce que je me demande, c'est surtout s'il n'aurait pas été bénéfique, surtout en terme de temps, de passer sur un mode de développement ouvert tout de suite (y compris avec une roadmap stricte, c'est pas le problème) pour bénéficier justement de la "force de frappe" du libre : le nombre de développeurs.

Si ce projet est si intéressant, alors il n'aurait pas eu de mal à trouver des développeurs pour s'y mettre et donc gagner du temps.

Parce que tout ça, moi je le vois surtout comme une volontée de contrôle bien plus important que dans les autres distribs.
Si je ne me trompe pas, la majorité des développements de red hat sont en open source, tous les dev de mandriva sont en gpl (pour novel, suse, je me prononcerai pas je ne sais pas)

M'enfin tout ça pour dire que je suis content que launchpad se libère enfin mais je trouve très domage cette volonté constante d'emprisoner les utilisateurs / développeurs chez ubuntu, ce qui est à mon avis contraire aux intérêts et aux buts du Libre.

c'est surtout que
attaque (attaquant => robert, attaqué => martin)
et
robert.attaque(martin)

ne sont pas du tout la même chose
dans le premier cas, on a un 'attaque' qui est "global" alors que dans le deuxième attaque s'applique à 'robert'

Cet exemple montre justement que le premier est plus verveux et pourtant pas plus clair...

En ce sens, les nomages à la objective C me semblent intéressant. On aurait écrit (en gros) :
[robert attaque:martin]

D'ailleurs, il suffit de rajouter un paramètre pour le voir un peu mieux :
attaque(attaquant => robert, attaqué => martin, arme => machette)
robert.attaque(martin, machette)
[robert attaque:martin avec_arme:machette]

D'ailleurs, on retrouve parfois ce genre de construction en ruby (en jouant sur les hash) :
robert.attaque margin, arme => machette

Tout ça pour dire que je trouve vraiment que les langages concis et bien foutu permettent d'avoir des codes bien plus lisibles, plus compréhensible. Il est d'ailleurs au pire toujours possible de faire du verbeux, du lourd avec un langage concis, mais malheureusement pas le contraire (et les langages trop verbeux ... beurk)
En fait, ce qu'il faut à mon avis ces des langages expressif, et je trouve que ruby en est justement un pas trop mauvais exemple. Il est concis, lisible et suffisament expressif pour avoir des codes lisibles et propres

évidemment, mais je parlais là des 12Go de différence ... ce qui est pas mal je trouve (à moins que ce soit surtout des options de compil, debug, ...)

d'un autre côté, si tu ne veux (que) les RPMS et non l'arbre entier, pour une 2008.1 ça reviens à 28Go pour la branche i586

Donc encore plus dans ce cas, c'est gérable (à condition d'avoir une connexion suffisante pour aller récupérer les 28Go...)

(maintenant, la différence entre 2008.1/i586 et ta cooker/i586 ... je sais pas trop d'où ça vient, c'est un peu zarb quand même...)

Ce bouquin est vraiment pas mal (il est écrit en partie par les auteurs de rails si je ne me trompe pas)
La seule chose, comme mentionné ailleurs dans ce journal, est qu'il se base sur les version 1.1 et 1.2 et non la 2 (mais si je ne me trompe, c'est en cours)

Donc le mieux avec ce bouquin est d'utiliser un rails 1.2, de lire le bouquin, suivre le tuto, etc
Et ensuite s'essayer à modifier, recréer des applis et à ce moment passer en rails 2 et voir la doc pour les différences

Mais c'est à mon avis un très bon bouquin pour commencer

oups, oui, merci pour la correction

Je me disais bien que c'était pas possible que j'y arrive du premier coup (même si le résultat est le même) ;-)

question bête, mais le fichier n'était pas déjà pré rempli avec la bonne structure ?
Ce que je veux dire par là c'est que je trouve que c'est un peu un faux problème, tu rentres une mauvaise config, il t'insulte qu'il ne comprend pas, ben c'est un peu normal, non ?

Bon c'est sur que l'un des problèmes vient du fait d'avoir changer certaines choses en passant à rails 2 et donc il faut arriver à trouver de l'aide sur cette version.

Maintenant, vouloir faire du rails sans base de donnée est par exemple un peu idiot car rails est vraiment fait pour ça (les modèles du mvc sont liés avec une base, donc sans base je vois pas trop comment tu veux faire...)

Je pense que le plus simple pour toi serait de suivre un tuto quelconque "bêtement" pour commencer, pour dégrossir justement ce genre de problèmes et ce qui te permeterait de voir justement le modèle mvc. Ensuite, libre à toi de la modifier ou même de repartir depuis 0, mais surtout je pense pas qu'on puisse se jeter dans rails comme ça sans doc (au début)

0, non ?

(si mes souvenirs sont bon, d(sin(x))/dx = cos(x)
4*cos(7*x - pi/2) avec x = 0 -> cos(-pi/2) = 0)

merde, je dois pas être humain... ;-)
(par contre, un ordi doit bien pouvoir le faire aussi, non ?)

en même temps (sans vouloir minimiser l'impact ou la captivité que peu vouloir Apple), on ne peut pas non plus demander à Tristant Nitot d'être totalement impartial..
Non que je pense qu'il ne le soit pas, mais c'est ce qu'on dirait si une même déclaration venait d'un dirigeant ou employé d'Apple...

Et même si le libre n'est pas "courant" chez Apple, est-ce réellement une raison de ne pas utiliser leurs développement qui eux le seraient ?

Maintenant, je ne vais pas pour ma part courir derrière les projets webkit mais j'espère que ça fera un peu bouger les choses du côté de mozilla pour qu'ils se décident enfin à mettre un peu plus en avant (que ce soit par la com ou les développement) les autres techno mozilla, présentées comme super prométeuses (xul...) mais dont on ne voit pas grand chose venir malgré le temps et la prédominance de firefox...

> Gecko est un... Kit. La communicatio nest faite autour du kit, pas de Firefox

Sérieux ? t'as vu de la communication sur autre chose que firefox de la part de mozilla ces dernières années ???


> Si Thunderbird utilise Gecko et xul, c'est simplement un sabotage de la volonté de Mozilla.

Heu... en même temps, montrer que des développeur de mozilla utilisent des produits de mozilla ... ben encore heureux ! mais je crois qu'il parlait plutôt des projets non mozilla (tu sais, epiphany par exemple, parce que bon, sortir galeon...)

oula, faut pas se méprendre du tout, je ne disais absolument pas que le wiki de suse (ou autre) est mieux.

Mais j'en ai juste un peu ras le cul de voir arriver partout des "sous bountou say mieux" alors que c'est juste ... comme les autres ...

Et bon, la simplicité d'ubuntu, une fois passée l'installe il n'a plus grand chose de différent et le wiki sert surtout pour faire du copier coller en général...

> Le pire dans leur article c'est qu'ils donnent une ligne de commande imbitable pour installer je ne sais plus quel package sous OpenSuse.
> Pourquoi ne pas avoir utilisé Ubuntu qui aurait rendu ça plus simple?

C'est vrai que le wiki d'ubuntu n'est pas du tout rempli d'une quantité de lignes de commandes qui sont copiées collées sans même comprendre, de quantité de sudo vim ceci, sudo apt-get cela, ...


(pfiou, heureusement qu'on est quand même vendredi...)

il faut aussi générer les fichiers de langue (update_mo.sh et update_po.sh) qui créent les fichiers dans pub/local (de tête)

(oui, moi aussi testé et adopté, merci beaucoup !)

j'ai lu vite fait et je suis resté sur :
> Pour la gestion des packages, les meta packages sont peu évident à trouver. Il faut sélectionner le type meta-package pour pouvoir les parcourir

Je trouve au contraire cela très bien et trouve justement que ça donne beaucoup plus de visibiilité qu'auparavant.
En outre, une fois le type choisi, on retrouve les meta packages classés par catégories et il est alors assez simple de les sélectionner.

En fait, j'ai pas très bien compris le manque de visibilité ou la solution à utiliser à la place.

oui, le noir et le blanc ne sont pas des couleurs
le noir est justement l'absence de couleur et le blanc l'opposé

(pour plus de détails : Noir_et_blanc )

oui et non...

rpm intègre déjà les requires. Les suggest ne sont que des dépendances optionnelles et sont justement au même niveau.
Franchement je ne vois pas pourquoi il y aurait une différence entre les 2.

Maintenant, oui, tout comme ce sont les front-end qui gèrent l'installation des dépendances, ces front-end peuvent traiter (ou non) les suggests à leurs niveaux.

Mais là ou ce serait vraiment intéressant c'est qu'il y aurait une (et une seule) façon d'indiquer les suggest pour tous les paquets rpms.
Le suggest fait partie du paquet et non de l'outil de gestion du paquet ou d'installation.