Colin Leroy a écrit 1205 commentaires

Je trouve que tout ça ne ressemble vraiment à rien.
D'un côté on a Gnome qui veut tout réécrire progressivement, juste parce que c'est plus groovy - voir http://ometer.com/desktop-language.html(...) :
" In the Linux desktop world, there's widespread sentiment that high-level language technologies such as garbage collection, sandboxed code, and so forth would be valuable to have and represent an improvement over C/C++"
Perso j'ai pas ce sentiment. J'ai surtout le sentiment qu'une telle solution boufferait deux fois plus de ressources, fonctionnerait plus lentement, et surtout, nous ferait utiliser des trucs à la philosophie plutôt éloignée du libre. Enfin bon.

De l'autre côté, on a les rêves de grandeurs de certains, où Gecko devient presque le noyau du système...

1. Construire des applications multi-plateformes entièrement nouvelles, utilisant Gecko, le rendu natif par les thèmes et une bonne intégration bureau/OS.

ça c'est une super idée ! on n'a qu'à refaire plein de trucs qui existent déjà juste avec un autre toolkit ! (et une bonne intégration bureau/OS, yeah, qu'à Gecko à voir là dedans?)

4. Parallèlement, dès maintenant et en collaboration étroite avec d'autres hackers de l'open source, construire une nouvelle plateforme applicative unifiée bureau/web à partir de morceaux du code de Mozilla et de GNOME. Partager le code et les efforts, éviter les grandes réécritures.

ça c'est sûr qu'en mettant mozilla et gnome dans une "nouvelle plateforme applicative", on évite les grandes réécritures ...

C'est quoi, le but ultime? Mettre une page web en fond d'écran ?
World domination ?

Je ne vois vraiment pas en quoi l'arrivée de XAML demande de réécrire un gestionnaire de bureau à partir d'un navigateur. Je suis peut-être obtus, mais perso je m'en fous d'XAML.

Traduction automatique... ("- connaissance importante du réseautage" est pas mal aussi ;-))

Mais, où trouves-tu des offres aussi intéressantes?

inutile de repondre que c'est stupide, allez plutot argumenter avec les developpeurs nvidia :)

s/développeurs/décideurs ;-)

D'après ce que je lis ils ont enlevé le pire, la responsabilité du filtrage aux FAI...
Je ne vois pas mention non plus de taxe sur l'upload. Faudrait lire le tout, histoire de voir ce qui reste...

comme une action qui gêne seulement le fonctionnement des labos (et plus particulièrement les relations labos/gouvernement) ?

Je ne vois pas en quoi ça a gêné des millions de personnes. Peux-tu nous éclairer ?

Quand est-ce que les informaticiens vont comprendre que tous les choix ne sont pas seulement techniques ?

Justement, je parle de question "politiques" qui amènent à des choix techniques *et les modifient* ; dans le cadre du logiciel libre, ça peut nuire gravement à un projet - cf http://www.linux-france.org/article/these/conseil-municipal/bazaar_(...) .

Pour en revenir à nos moutons, il y a des gens à qui la politique d'XFree ne plait pas ; parmis eux, il y en a qui sont prêts à donner du temps pour donner à tous une alternative. De quoi peut-on se plaindre (indépendemment de tout avis sur la question du choix politique) ?
Du fait que parmi eux, d'autres avant bossaient sur XFree86. ça ralentit le développement. Je sais que je n'ai pas le droit de me plaindre, ce n'est pas ce que je fais, je constate. Et je trouve ça dommage.

Au passage, petite question un peu provoc' : si le logiciel libre n'est pas ta principale motivation, pourquoi tu utilises GNU/Linux ?

C'est ma principale motivation. Il y a une chose qui n'était pas claire dans mon précédent message, j'ai utilisé l'expression "ça pue c'est pas libre" en référence aux hurlements qu'on trouve souvent sur linuxfr.
Ce que j'ai voulu dire c'est que le changement de licence d'XFree n'en fait pas un logiciel non-libre. La GPL n'est pas tout...

Plus généralement, bien que je sois un fervent utilisateur (et développeur) de logiciel libre, je n'en garde pas moins la tête froide, et lorsque que le choix de l'utilisation d'un logiciel propriétaire ou d'un libre aux capacités largement inférieures (voire pas d'équivalent) se présente, je pèse le pour et le contre et il m'arrive d'installer du proprio - drivers nVidia sur le PC de ma copine, bitkeeper.

On "moinsse" les commentaires non constructifs (voire gratuitement destructifs), pas ceux avec lesquels on n'est pas d'accord.
Si tout le monde pouvait réfléchir comme toi...

Bientôt en France, des lois aussi connes que certaines aux Etats-unis!
Pour eux ça fait déjà trois ans...
http://marc.theaimsgroup.com/?l=linux-kernel&m=100374730418148&(...)

- les listes

Tant qu'il y aura des programmes en java, y'aura une VM pour Linux, même si elle est pas libre, et les gens qui en auront besoin l'utiliseront.
Pas besoin de s'inventer des problèmes

Au passage, les dévs de Gnome en ce moment ont l'air de les chercher, les problèmes, à se demander s'ils vont utiliser Java ou Mono... Mais *pourquoi* changer, déjà? ça marche pas ce qui existe?

Encore des raisons "politiques"[*] qui font perdre une énergie incroyable à bon nombre de gens...
de XFree on passe à XFree, Y, Xorg et fd.o. Comme tu le dis les drivers fermés amènent plus de problèmes encore.
ATI et nVidia vont certainement pas, avant longtemps[**] du moins, signer des NDAs avec les développeurs de ces quatre groupes et sortir des drivers propriétaires pour chacun. Si les différents projets perdent la compatibilité binaire de leurs drivers, les utilisateurs des forks vont se retrouver dans une position emmerdante...

"J'ai remplacé mon XFree86 parce que ça pue c'est pas libre! Bon ok maintenant je joue à tuxracer à 12 fps, mais au moins Saint Richard est fier de moi."

Ben non merci - perso j'ai installé XFree86 4.4 le jour de sa sortie, parce que c'est cette version qui fait mieux marcher ma radeon que le 4.3 ou les forks.

[*]rien que pour ce mot je sens que je peux dire "adieu XPs". tant pis.
[**] échelle de temps du monde informatique

"quand j'estime que cela est nécessaire" et "mon code est suffisamment explicite de lui même" sont un peu redondantes...
Perso j'estime un commentaire nécessaire quand le code auquel il s'applique n'est pas assez explicite : pas de commentaire sur un get_date(), par contre sur un do_stuff(lots, of, params) un petit commentaire doxygenable/javadocisable est toujours le bienvenu...

Pour les deux, en anglais - une habitude prise dans mon premier boulot (où des anglais et espagnols lisaient notre code) d'une part, et parce que sur les projets open-source c'est la norme quand on contribue ;-) (et aussi, la norme si vous voulez que des gens envoient des patches à votre projet).
ça tombe bien, c'est plus concis, donc ça fait du code plus clair - à mes yeux.

Vite tout le monde, remettez vite vos chapeaux d'aluminium...

Vos réactions sont effarantes - quand bien même les conditions ne vous plaisent pas, qui vous force à vous inscrire ? à mon avis l'affichage de pubs à côté des emails fonctionnera comme pour les pages web, pas besoin de stocker votre vie entière dans un cookie pour ça.

D'autre part je préfère de beaucoup que Google fasse sa thune (tip of the day: leur ferme de serveurs, bien que tournant sous OS libre, n'est pas gratuite; ni leurs salariés) avec des pubs au format texte plutôt qu'en faisant payer les inscriptions au moteur.

ça sert à rien tout ça, honnêtement, vous voyez le bureau combien de temps après l'ouverture de votre session? moi pas plus de cinq minutes... (et tout minimiser, c'est plus pénible que taper tail /var/log/...).

Oui, c'est ce que font la plupart des admins de vrais réseaux :)

table arp statique :)
Il faudrait que l'attaquant prenne une IP whitelistée (d'une station); soit ça ne marchera pas car la station sera allumée; soit la station sera éteinte et l'attaquant devra en deviner l'adresse ARP aussi.

oui, en effet, j'ai laissé le clavier :)
J'attends impatiemment un adapteur bluetooth/ondes-alpha-du-cerveau, mais ça a pas l'air d'être pour demain ;)

PS: ssh, ça se troue, donc j'en mets pas sur mon firewall. Je pense qu'il faut forcément faire des compromis pour avoir plus de sécurité, et ce genre de compromis est acceptable: j'aurais ssh sur mon firewall, j'aurais dû upgrader ssh aussi souvent que j'ai branché l'écran.

juste l'écran. A chaque fois, pour moi, ça se traduit par "tous les six mois" pour ajouter une IP autorisée à sortir. C'est pas si chiant que ça :)

non pas les logs, mais plutôt la defaultroute (`route -n`). Ceci dit l'adresse n'est pas une information secrète, on s'en fout puisqu'il n'y a rien à y voir (comme dit Quzqo, le relais ne se fait pas au niveau TCP (ni UDP, d'ailleurs ;-)) mais IP).

Quand on sépare le firewall, il est imprenable (sauf faille TCP/IP, comme je le dis dans un autre message).

Ton premier avantage se transforme en
+ si ton serveur est compromis, le reste des machines ne l'est pas nécessairement

Séparer le firewall et le(s) serveur(s) est beaucoup plus sécurisant car te faire pirater le serveur ne permettra pas pour autant au pirate d'utiliser ton serveur comme relais vers l'extérieur.
Le firewall est normalement imprenable, sauf en cas de faille dans la pile TCP/IP dans le noyau: chez moi, il a l'air "mort". Il n'écoute sur rien, ni tcp, ni udp, ni icmp. (Forcément pour le configurer, faut brancher l'écran, mais le jeu en vaut la chandelle à mon avis).

Le serveur Web accepte les connexions en ssh (de partout), en http (de partout). Il ne peut initier aucune connexion, ni vers le LAN (grâce à un firewall local), ni vers internet (firewall local + le firewall dédié, le "mort"). Si le firewall local devient inutile (exploit root et pas seulement user), le serveur web pourra servir de relais pour attaquer les ordis présents sur le LAN (qui n'écoutent que sur ssh). L'attaquant ne pourra pas ressortir vers internet, car le firewall dédié l'en empêchera.

Mixer firewall et serveurs te prive principalement de ce niveau de sécurité.

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.(...)
http://members.optusnet.com.au/ckolivas/kernel/(...)
par exemple

PS: tu peux aussi regarder du côté de ifplugd, qui est censé t'aider à automatiser le branchement/débranchement du câble:
http://www.stud.uni-hamburg.de/users/lennart/projects/ifplugd/(...)

Tu peux ajouter à la fin de ton script d'init.d qui gère eth0, un appel à mii-tool (http://linux-ip.net/html/tools-mii-tool.html(...)), et si ça te dit que le câble n'est pas là:

/sbin/route del default gw
/sbin/ifconfig eth0 down

et ça devrait suffire pour que tous les services réseau chopent un "no route to host" immédiat au lieu d'un timeout "connection failed"..