galactikboulay a écrit 620 commentaires

  • [^] # Re: A Free ?

    Posté par  . En réponse au journal Une histoire d'Orange et de cerveau. Évalué à 8.

    Le principe de box ?
  • [^] # Re: Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 1.

    Ah parce qu'on a plus besoin du tout d'entreprises qui font du soft ? Première nouvelle.

    Tu as pensé à avoir une vision moins étriquée du monde, ou tu vas encore nous sortir le nom d'un nazi quelconque pour "étayer" ton propos ?
  • [^] # Re: Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 2.

    Ah parce que bien sûr, avec la GPL (ou même la BSD), tu es entièrement libre de faire ce que tu veux ? On peut très bien objecter d'être privé du droit de changer la licence par exemple.
  • [^] # Re: Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 3.

    cette phrase ne veut strictement rien dire. on dirait le gerbis abominable que sortent Pascal Nègre et autres cuistres "les artistes ont bien le droit de vivre de leur passion" "les maisons de films/diffuseurs ont bien le droit de vivre de leur métier".


    On était en train de parler de *logiciels*, je ne vois pas ce que Pascal Nègre et les artistes viennent faire dans la discussion.


    c'est d'un nauséabond, c'est du Goebels.


    Tu te rends compte des inepties que tu écris ?
  • [^] # Re: Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 1.

    La question "éthique" telle que tu l'abordes est complètement hors de propos pour moi. Ce n'est pas parce que tu as les moyens de diffuser un logiciel à coût nul que ce logiciel a un coût de réalisation nul pour l'entreprise qui l'a conçu. Cette entreprise a le droit de payer ses salariés et d'amortir ses frais aussi.
  • [^] # Re: Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 3.

    Non. Un logiciel "propriétaire" ou "non-libre" ne te donne pas les libertés qu'un logiciel libre équivalent t'offre. Je considère que le terme "logiciel privateur" sous-entend un jugement négatif qui n'a pas lieu d'être.
  • [^] # Re: Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 5.

    Merci, je connais la définition de la FSF. Je ne vois toujours pas pourquoi on parle "de renoncer à ces libertés", vu qu'à la base, tu ne peux pas y prétendre en étant pas auteur du soft. Les logiciels libres te les donnent (et c'est très bien), ça ne veut pas dire que c'est un droit universel.
  • [^] # Re: Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 1.

    Sauf que ça ne marche pas dans ce sens là, non. Une licence libre te donne des libertés *supplémentaires*. Par défaut, tu n'aurais pas le droit de copier et distribuer le soft comme tu veux.

    Je préfère de loin le logiciel libre hein, mais il faut arrêter de considérer comme un droit naturel le fait d'avoir les sources ou de pouvoir distribuer à qui tu veux sans le consentement de l'auteur.
  • # Logiciels "privateurs"

    Posté par  . En réponse au journal RMS et le piège du Javascript. Évalué à 4.

    Ca commence à m'énerver ce concept intégriste de logiciel soit disant "privateur" en lieu et place de "propriétaire".

    Je ne vois pas en quoi ça "prive" l'utilisateur de quelquechose, l'auteur choisit la licence qu'il veut, c'est son droit le plus strict, point barre. La licence ne convient pas à l'utilisateur ? Il n'achète pas le produit et puis c'est tout.
  • # Pas grave

    Posté par  . En réponse au journal [HADOPI] "Est-il liberticide que de vouloir préserver le droit pour les auteurs de continuer à faire des films?". Évalué à 10.

    On trouve dans la liste Gérard Krawczyk (qui a commis entre autres Taxi 2 à 4) et Patrick Braoudé (qui a commis Iznogood), donc si effectivement ils pouvaient arrêter de faire des films ça serait pas une grande perte...
  • [^] # Re: Les brevets

    Posté par  . En réponse au journal MS attaque TomTom et Linux (putain de brevets). Évalué à 10.


    Faire chier ? Non, MS a cree FAT, pourquoi donc les gens pourraient le reutiliser gratuitement ? Ils ne sont pas foutus de creer un FS eux-meme ?


    Nan mais genre, qu'est-ce qu'il faut pas lire ... FAT est une grosse bouse immonde et n'importe quel étudiant en informatique concevrait quelque chose de mieux fichu que ça. Le pb est que Windows ne supporte, "bizarremment", qu'un nombre minimal de FS, et comme côté MS il ne faut pas être interopérable avec le reste ...

    Pourquoi MS n'a pas attaqué ceux qui ont fait des utilitaires de récupération de données, des défragmenteurs ou que sais-je encore ?

    J'espère que ta boite de nuisibles finira par couler un jour ou l'autre. Elle n'a jamais rien apporté à l'informatique et tu me fais bien rigoler quand tu parles de la communauté du libre qui copie avec OOo ou KDE, alors qu'au départ MS a bien pompé sur Apple et d'autres. MS, c'est le degré 0 de l'innovation.
  • [^] # Re: Les brevets

    Posté par  . En réponse au journal MS attaque TomTom et Linux (putain de brevets). Évalué à 6.

    Et sinon ça te pose aucun problème de conscience de bosser pour cette boite de connards ?
  • [^] # Re: produit fini ?

    Posté par  . En réponse à la dépêche Le projet Armadeus passe à la vitesse supérieure. Évalué à 1.

    Comment ça l'ISE n'est plus gratuit ? Apparemment c'est toujours le cas:

    http://www.xilinx.com/ise/logic_design_prod/webpack.htm

    Par contre il ne gère pas les plus gros modèles de chaque famille si je me rappelle bien.
  • [^] # Re: Explications?

    Posté par  . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.


    Le seul avantage est effectivement de pouvoir migrer une machine virtuelle d'un hardware physique à un autre. Mais bon la même chose peut toujours se faire au niveau applicatif (tar/untar d'une machine à une autre et zou).


    Comme s'il suffisait de faire un tar/untar pour toutes les applis... O_o
    Déjà sur de l'Unix c'est pas forcément toujours évident à réaliser, mais il y a d'autres systèmes (au hasard Windows) où ça devient vite non trivial (transférer les clés de registre ou autres joyeusetés).
    On pourrait aussi parler de la config réseau, si ton appli est interrogée sur une certaine adresse IP ou un certain nom cela oblige à des reconfigurations.

    Franchement, comparer des migrations à chaud de VM avec du tar/untar, faut oser.
  • [^] # Re: Explications?

    Posté par  . En réponse au journal SPICE libéré ! (bientôt). Évalué à 1.


    En général tu prévoies de la redondance (ben oui en cas de panne) et tu dois pouvoir être capable d'arrêter une machine sans que ça se voit. Si ce n'est pas le cas, ce n'est pas normal, c'est tout ^_^


    Ca c'est bien sympathique comme remarque, mais il existe des gens qui conçoivent des applis non redondantes... Autant sur certains services c'est facile (genre du Web/DNS/DHCP/Radius/... par exemple), autant pour d'autres choses ça l'est beaucoup moins.
    Quoiqu'il en soit, je préfère migrer des VMs de manière transparente en cas de maintenance planifiée sur un hyperviseur plutôt que de compter sur le fait que la redondance applicative marche à tous les coups (parce qu'on peut avoir des surprises assez sympa à ce niveau là).


    tu peux faire tourner plusieurs applis sur 1 seul serveur et tu n'es pas obligé d'acheter que des bêtes de courses.


    Sauf qu'à l'heure actuelle, même si tu prends pas le haut de gamme, tu as quand même des machines très puissantes de base, donc qui consomment (et il y a toujours la question de la place).
    Après, c'est sûr que tu peux faire tourner plusieurs applications sur le même serveur, c'est juste moins top en terme de sécurité ou même d'isolation (conso CPU, mémoire,... qui part en vrille pour une appli et qui perturbe les autres)


    peut souvent se faire en général aussi au niveau applicatif.


    Oui, *en général*. Ce n'est pas vrai tout le temps.


    La virtualisation n'a rien à voir la dedans, les serveurs ont tous une console d'administration à distance.


    J'ai dit que l'administration était facilitée, pas que c'était impossible avec des serveurs physiques.
    Je préfère largement utiliser un VI client que d'avoir à me coltiner les différents systèmes de gestion à distance des constructeurs (genre iLO, DRAC et cie).
    En plus, je peux facilement donner des droits assez fins à tel ou tel utilisateur sur la VM.
  • [^] # Re: Explications?

    Posté par  . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.

    Aucun intérêt ? on voit bien que tu n'as jamais vraiment utilisé...

    Le fait est que concrètement ça permet:

    - d'effectuer des maintenances matérielles (ajout de RAM, CPU, ...) ou logicielles (upgrade) sur les serveurs de virtualisation de manière transparente: tu évacues les VMs sur les serveurs qui restent pendant que tu effectues la manip sur le serveur physique.

    - de migrer de manière transparente tes machines d'un datacenter à l'autre si pour une raison X ou Y tu as un problème sur ton site principal

    - d'avoir une consommation électrique réduite, au lieu d'avoir 42000 serveurs qui ne font quasi rien, tu en achètes quelques gros. Cela économise aussi de la place, du câblage, ...

    - de load-balancer tes VMs sur les différents serveurs.

    - de déployer extrêmement rapidement un nouveau serveur (surtout quand tu as la possibilité de cloner des VMs ou de faire des templates). L'accès à distance est également facilité: tu as tes media d'install sur une baie de disques, que tu montes virtuellement. Tu as accès à la console à distance, pas besoin d'aller en salle serveurs (pratique quand tu merdes et que la dite salle serveurs est à des km).
  • [^] # Re: Le multicoeur va vraiment devenir problématique

    Posté par  . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 6.

    L'architecture x86 a évolué par ajout de couches successives pour aboutir à qqch d'immonde (ISA au départ 16 bits, ensuite étendu à 32, et encore à 64).
    Le nombre de registres disponibles (8 en 16/32, et encore avec 6 concrètement utilisables) est à mourrir de rire. C'est à peine mieux en x86_64, puisque pour utiliser les 8 registres supplémentaires (total de 16 donc), il faut utiliser un préfixe...

    Alors c'est sûr, ce n'est pas spécifique au SMP, ça prouve que c'est juste une architecture de merde.

    Ensuite pour ton information, l'APIC ça ne "gère" pas le SMP dans l'ensemble, ça permet l'aiguillage des interruptions vers les différents CPU dans un système SMP.
  • [^] # Re: Le multicoeur va vraiment devenir problématique

    Posté par  . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 5.

    T'as déjà regardé le jeu d'instructions du x86 avant de dire ça ? Voire programmé avec ?
  • [^] # Re: Tuer le spam à la racine!

    Posté par  . En réponse à la dépêche Reprise de Dspam par la communauté. Évalué à 3.

    Le problème est que les mails envoyés à abuse@... sont souvent redirigés vers /dev/null et donc ça ne sert pas à grand chose.
  • # Oui il est 64-bits

    Posté par  . En réponse au message Intel Xeon X3220 32 ou 64 bit ?. Évalué à 2.

    Le Xeon 3220 gère effectivement EM64T, donc tu peux installer un noyau 64-bits dessus. Il supporte également la virtualisation, ce qui a un intérêt certain pour Xen.
  • [^] # Re: Free

    Posté par  . En réponse au journal Mobilix. Évalué à 10.

    bon ça suffixe
  • [^] # Re: Oh

    Posté par  . En réponse au journal Rions jaune avec voyages-sncf.com. Évalué à 10.

    à ce niveau là, c'est plus une pelle, c'est carrément une des foreuses qu'a servi à creuser le tunnel sous la manche
  • [^] # Re: autoflagelation

    Posté par  . En réponse au message VLAN et tunnel IPSEC. Évalué à 2.

    Il faut voir si cette implémentation en particulier (linux) le supporte, j'aurais tendance à dire non en voyant le message. Je jeterai un coup d'oeil dans le code de brctl ça peut être intéressant.

    Tu as essayé avec une interface GRE ? J'ai vu qu'il y a eu des patches (pour du noyau 2.6) pour supporter ce genre de bridging, tu auras peut-être plus de succès.
  • [^] # Re: autoflagelation

    Posté par  . En réponse au message VLAN et tunnel IPSEC. Évalué à 2.

    On peut tout à fait bridger entre une interface Ethernet et un tunnel GRE. Le tagging 802.1Q est juste une entête de 32-bits qui vient s'intercaler (ethertype 0x8100 + n° du VLAN + champ CoS).

    Pour au-dessus, par rapport à PPTP: PPTP s'appuie sur PPP, on peut aussi bridger sur PPP.
  • # Ce qui est bien ...

    Posté par  . En réponse au journal EyeOS 1.7.0. Évalué à 10.

    ... avec ce genre d'usine à gaz, c'est que bientôt il faudra un quadricore pour lancer un outil de calendrier tout bête ou un éditeur à la notepad.

    En déplaçant une fenêtre (par la barre de titre) rapidement, on voit que ça rame, et ça arrive à utiliser 100% d'un core sur ma machine pour ça.

    Je vois vraiment pas l'intérêt de ce genre de trucs (je dis pas que c'est facile à faire, c'est certainement un boulot de fou). Mais déjà appeler ça un OS, ça me fait doucement sourire. Pour moi, c'est une GUI rien de plus. Mais j'imagine qu'appeler ça OS ça fait plus "hype".

    Si j'ai besoin d'accéder à mes données à distance, j'utilise ssh (éventuellement avec le tunneling X11 pour lancer des applis graphiques). Si c'est sur une machine sans serveur X, VNC marche très bien.

    Enfin, à part des petites applis très ponctuelles, je pense pas que le concept soit généralisable (applis à porter et tout).