Oui, mais à quoi bon le faire sur une plate-forme qui est pire que propriétaire ? La distinction propriétaire/libre a été faite à une époque où l'utilisateur avait le droit d'installer ce qu'il voulait, sur iOS ce n'est même pas le cas. Je préfère encore utiliser Windows même s'il a probablement moins de code libre derrière.
Chercher à créer des consommateurs captifs, qui auront le choix de devenir soumis et/ou fanboys, pour moi, c'est du long terme, ou au moins moyen terme ;-)
Si tu as des problèmes de mémoire libre, tu as essayé de compiler en -Os ?
À mon avis le gain de performance de mplayer est négligeable car ils font eux-mêmes des optimisations spécifiques bien plus importantes. Il faudrait comparer des programmes « pur C ». Sachant qu'en 64 bits c'est sûrement moins significatif car les distributions binaires sont sûres de pouvoir faire un certain nombre d'optimisations (i686, mmx, sse, etc.) contrairement au 32 bits.
Héhé, justement on peut le compiler sans HAL ! Ou encore avoir OpenOffice sans Java.
Comme on peut désactiver des fonctionnalités en dur, ça fait effectivement moins de failles à exploiter.
Je ne connais pas très bien les attaques type « buffer overflow », mais est-ce exploitable correctement si on ne connaît pas la structure du binaire distant ? Au vu de toutes les possibilités sous Gentoo (USE flags et options GCC) ça rendrait éventuellement la chose difficile.
De la même façon mes serveurs n'ont pas été touchés par un paquet de failles du noyau Linux parce que la fonctionnalité concernée n'était tout simplement pas compilée. Désactiver l'émulation 32 bits par exemple a été très payant.
De plus Gentoo est une des rares distributions à avoir une version « durcie (hardened) ». Concrètement, c'est des patchs sur GCC, un noyau différent par défaut, et quelques autres changements du système de base. Comme il n'y a pas de paquets supplémentaires à héberger, ça ne coûte pas grand-chose.
Gentoo *facilite* la tâche de maîtriser complètement son système − sinon c'est compiler chaque application sans système centralisé ce qui est là particulièrement emmerdant.
On peut même appliquer des patchs, comme par exemple le support des 256 couleurs dans urxvt, ou il y a quelques années aotuv pour le vorbis.
Ça me permet aussi d'éviter de me retrouver avec Java, Mono, etc.
Une fois qu'on a une configuration propre (et dans mon cas, partiellement partagée entre machines) ça ne demande plus beaucoup de maintenance.
Oula mais tu as juste rien compris, ça c'était pour répondre aux mecs qui disent que le NAT est plus sécurisé. Si tu veux avoir plusieurs ordis accessibles c'est justement possible quand tu n'as pas de NAT. La différence c'est que tu as le choix.
« blinder 10 avec des règles précises »
Non tu le fais une fois, au niveau de ta passerelle, elle route, mais ne fait pas de NAT.
« je branche une machine sur le réseau local, ça marche » là encore je suppose que tu pense à IPv4 et le DHCP qui lui est souvent associé ; c'est absolument pas lié au NAT.
IPv6 lui a un équivalent de DHCP qui nécessite encore moins de choses à gérer et qui est infiniment plus rapide.
nVidia ne fournit aucune doc au libre (à l'exception de forcedeth mais c'était après-coup).
Ils font des pilotes propriétaires de bonne facture pour le GPU, mais bon. Je ne sais pas ce qu'il en est du Tegra, je crois que c'est un peu la même chose (besoin de blobs binaires).
C'est gentil le sarcasme mais le NAT ça veut dire faire quelque chose de plus que ce qui est fait par défaut, donc par définition plus difficile à configurer.
Pour ces deux choses il y a des méthodes IPv6 beaucoup plus appropriées. Là encore, on a des réfractaires qui n'ont pas pris la peine de rafraîchir leur connaissances par rapport à IPv4.
Malheureusement c'est quelque chose que je lis souvent, y compris sur des sites où les participants sont sensés comprendre quelque chose aux réseaux.
Bref la réponse habituelle, c'est qu'il suffit d'une passerelle qui refuse tout ce qui entre par défaut et on a le même effet de bord que le NAT, les problèmes en moins.
[^] # Re: L'hypocrisie d'Apple
Posté par DLFP est mort . En réponse au journal [BreakingNews] VLC retiré de l'iOS AppStore !. Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: L'hypocrisie d'Apple
Posté par DLFP est mort . En réponse au journal [BreakingNews] VLC retiré de l'iOS AppStore !. Évalué à 8.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: L'hypocrisie d'Apple
Posté par DLFP est mort . En réponse au journal [BreakingNews] VLC retiré de l'iOS AppStore !. Évalué à 6.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: L'hypocrisie d'Apple
Posté par DLFP est mort . En réponse au journal [BreakingNews] VLC retiré de l'iOS AppStore !. Évalué à 8.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Mac App Store
Posté par DLFP est mort . En réponse au journal [BreakingNews] VLC retiré de l'iOS AppStore !. Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Gentoo
Posté par DLFP est mort . En réponse au journal Au revoir Ubuntu, bonjour Squeeze. Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Gentoo
Posté par DLFP est mort . En réponse au journal Au revoir Ubuntu, bonjour Squeeze. Évalué à 2.
À mon avis le gain de performance de mplayer est négligeable car ils font eux-mêmes des optimisations spécifiques bien plus importantes. Il faudrait comparer des programmes « pur C ». Sachant qu'en 64 bits c'est sûrement moins significatif car les distributions binaires sont sûres de pouvoir faire un certain nombre d'optimisations (i686, mmx, sse, etc.) contrairement au 32 bits.
Héhé, justement on peut le compiler sans HAL ! Ou encore avoir OpenOffice sans Java.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Gentoo
Posté par DLFP est mort . En réponse au journal Au revoir Ubuntu, bonjour Squeeze. Évalué à 3.
Je ne connais pas très bien les attaques type « buffer overflow », mais est-ce exploitable correctement si on ne connaît pas la structure du binaire distant ? Au vu de toutes les possibilités sous Gentoo (USE flags et options GCC) ça rendrait éventuellement la chose difficile.
De la même façon mes serveurs n'ont pas été touchés par un paquet de failles du noyau Linux parce que la fonctionnalité concernée n'était tout simplement pas compilée. Désactiver l'émulation 32 bits par exemple a été très payant.
De plus Gentoo est une des rares distributions à avoir une version « durcie (hardened) ». Concrètement, c'est des patchs sur GCC, un noyau différent par défaut, et quelques autres changements du système de base. Comme il n'y a pas de paquets supplémentaires à héberger, ça ne coûte pas grand-chose.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Gentoo
Posté par DLFP est mort . En réponse au journal Au revoir Ubuntu, bonjour Squeeze. Évalué à 3.
On peut même appliquer des patchs, comme par exemple le support des 256 couleurs dans urxvt, ou il y a quelques années aotuv pour le vorbis.
Ça me permet aussi d'éviter de me retrouver avec Java, Mono, etc.
Une fois qu'on a une configuration propre (et dans mon cas, partiellement partagée entre machines) ça ne demande plus beaucoup de maintenance.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 2.
C'est pas le web, c'est Internet.
et https://linuxfr.org/comments/1197697.html#1197697
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 3.
Non tu le fais une fois, au niveau de ta passerelle, elle route, mais ne fait pas de NAT.
« je branche une machine sur le réseau local, ça marche » là encore je suppose que tu pense à IPv4 et le DHCP qui lui est souvent associé ; c'est absolument pas lié au NAT.
IPv6 lui a un équivalent de DHCP qui nécessite encore moins de choses à gérer et qui est infiniment plus rapide.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Proc != GPU
Posté par DLFP est mort . En réponse au journal Projet Denver de Nvidia. Évalué à 1.
Ils font des pilotes propriétaires de bonne facture pour le GPU, mais bon. Je ne sais pas ce qu'il en est du Tegra, je crois que c'est un peu la même chose (besoin de blobs binaires).
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 2.
Un NAT est plus difficile à configurer que du routing IPv6 normal vu qu'il n'y a rien à configurer.
Pour le reste : il suffit de refuser les connexions entrantes par défaut.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 1.
Un peu de lecture : https://tools.ietf.org/rfc/rfc4864.txt
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Je m'en fous
Posté par DLFP est mort . En réponse au journal Dépouillement de Firefox. Évalué à 9.
Sinon, il n'y a pas d'extension pour avoir une interface à l'ancienne ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 4.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 3.
C'est quoi les avantages du NAT ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Reste à attendre…
Posté par DLFP est mort . En réponse au journal Projet Denver de Nvidia. Évalué à 8.
Je crois oui, il faudrait qu'ils consultent les commentateurs de DLFP pour améliorer ça car ils sont très doués en la matière.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Resteà attendre…
Posté par DLFP est mort . En réponse au journal Projet Denver de Nvidia. Évalué à 1.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pas forcément la fin du NAT
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 3.
Bref la réponse habituelle, c'est qu'il suffit d'une passerelle qui refuse tout ce qui entre par défaut et on a le même effet de bord que le NAT, les problèmes en moins.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: OVH
Posté par DLFP est mort . En réponse au journal IPcalypse : J - 42. Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org