Posté par 007 .
En réponse au journal Sun dépassé?.
Évalué à 3.
Pour l'anectode mais c'est significatif.
Avant Red Hat tournait et supportait sparc et alpha.
sparc et alpha ne sont plus supportés.
IA64 a été introduit.
Puis AMD64.
Il reste x86/IA64/AMD64 et :
- ppc (pas mac mais IBM eServer pSeries)
- s390 (IBM)
Pas de sparc ni alpha alors que Red Hat a toujours été souple pour Rawhide.
C-à-d que Sparc et Alpha n'est même plus intéressant (et vraiment pas manifestement) pour une distributeur qui cible les stations de travail et serveurs.
Posté par 007 .
En réponse au journal Sun dépassé?.
Évalué à 7.
Franchement, le hard des Unix commerciaux (Sun, HP, IBM, Alpha) sont en train de se casser la gueule pour les micro et mini.
Leurs jours (mois) sont comptés et ils (Sun, etc) le savent.
C'est très bien d'afficher une super fiabilité pour le matos bas de gamme. Mais au prix d'un sparc bas de gamme, j'achetes 3 PC bas de gammes qui sont plus performants avec plus de mémoire, plus de disque, qui ont plus de programmes/OS, etc...
C'est jouée d'avance.
Pour l'OS, Unix va aussi se casser la gueule et vite (toujours pour les micro et mini).
On parle de Windows vs Linux, mais en premier et de façon sûre (pour moi), Linux va bouffer Unix et vite fait.
Ça impose de passer devant les tribunaux.
En attendant, le brevet est valide.
Que le brevet soit intelligent ou non, qu'il soit une copie de ce qui existait déjà depuis 200 ans, etc ne change rien à ça (malheureusement).
Tu parles d'un serveur. Or normalement un serveur n'est pas lancé par un utilisateur mais à l'init du système.
Et même dans ce cas...
Tu peux lancer plusieurs mysqld et depuis les comptes utilisateurs (faut faire attention aux ports).
btw, il ne faut pas mélanger les comptes de l'OS et les comptes de mysql par exemple.
Donc tu peux très bien avoir une machine avec plusieurs mysqld/postgresql/apache/bind/etc (tous différents si tu veux (mélanger mysql v3 et v4)) qui tournent en même temps.
Pour ton info, la majorité des services sous Unix tourne sur des comptes dédiés.
Il y a quelque cas où il faut développer en fesant attention à l'aspect multi-utilisateur de l'OS (atd, crond, etc). Mais c'est très très limité par rapport à l'ensemble des applis Unix/Linux.
> Tu m'expliqueras la difference fondamentale, entre prendre le controle des operations, et prendre le controle du pc, sachant qu'un pc fait des operations.
Me suis mal exprimé.
Lorsque l'édutiant fait une manip, si tu veux reprendre le "contrôle des opérations", tu ne prends pas le contrôle sur le PC mais sur la manip en cours. Je parlais de prendre le contrôle des opérations de la manip (qui peut passer par avoir l'exclusivité du PC. Mais c'est une autre histoire).
> que tu fais correspondre avec "avoir un acces root".
Imaginons deux postes de commande d'une barrière, distants de 200 mètres. Le poste A (pour le patron) et le poste B. Il n'y en a qu'un qui peut être actif à la fois. Pour passer d'un poste à l'autre, il y a un interrupteur (coupure du courant d'un poste et arrivé du courant pour l'autre) sur le poste A (poste uniquement accessible au patron). Cet interrupteur permet de décider quel poste commande la barrière (poste A ou B).
Question :
Un interrupteur est-il un moyen de "prise de contrôle à distance" ?
Voilà le problème. On mélange l'usage fait d'un objet et l'objet lui-même.
Un interrupteur reste un interrupteur même dans un contexte où il est utilisé pour faire de la "prise de contrôle à distance".
Soit on parle de l'interrupteur (intensité maxi, etc), soit au parle du dispositif de "prise de contrôle à distance" (un interrupteur, mis dans une pièce uniquement accessible au patron, des fils qui relient le poste A et B, etc).
Maintenant remplace "interrupteur" par VNC/PCpartout/etc, les postes de commandes par des PC (ça tombe bien (PC)), la pièces uniquement accessible par le patron par un mot de passe uniquement connu du patron pour le poste A, etc...
On a remplacé notre interrupteur par un système de transport d'affichage et un gestionnaire de session etc... mais pas par un système de "prise de contrôle à distance".
Pour utilisateur final, VNC lui permet d'obtenir le contrôle à distance de la barrière comme avec l'interrupteur.
Comme avec l'interrupteur, VNC n'a aucune information sur le fait qu'il permet "la prise de contrôle à distance" de la commande d'une barrière. Il ne fait que changer le lieu de l'affichage, le terminal. VNC est là pour ça et le fait bien.
btw, il y a plein de cas où VNC n'est pas utilisé pour faire de la "prise de contrôle à distance" (inhiber une session sur un poste et utiliser la session sur un autre poste). D'ailleur, je ne serais vraiment pas, mais vraiment pas étonné, que ça ne soit qu'un usage mineur.
Quand je dit que les brevets Rational (maintenant IBM) sont valables, je dis valable pour une agence de brevet, la justice.
Pour moi un brevet n'est pas valable.
> Mieux vaut qu'il prenne le contrôle de la _session_
Ce qui est toujours ridicule.
Prend le controle d'un train lancé à pleine vitesse, prend le contrôle d'un outil de production pour augmenter la production, etc.
Prendre le contrôle d'une session n'a aucun sens.
Que _fait_ un train : il avance
Que _fait_ un outil de production : il controle/participe à la production
Que _fait_ une session d'un utilisateur : rien.
> Pratiquement et d'un point de vue pragmatique, si.
Un couteau permet de tuer ou de bouffer du jambon mais outil "pour tuer" ou "bouffer du jambon" n'est pas sa définition.
D'un point vue "pragmatique", une voiture permet d'aller en vacance.
Mais la voiture reste un moyen de déplacement et pas un moyen pour aller en vacance. Un moteur, qu'on trouve dans une voiture n'est pas :
- Le truc qui fait accélérer la machine pour aller en vacance.
Pourtant des gens qui vont en vacance en voiture, il y en a beaucoup plus que d'utilisateurs de PCanywhere.
> Ce dont il parle, c'est pas de la prise de contrôle, c'est de la "persistance de session".
Je m'en doutais un peu.
Je me rappèle de les annonces (depuis 2.2 ?) avait platform et desktop.
Par contre, c'est la premier foi que je vois ça pour le site ftp (un répertoire pour desktop, un autre pour platform, etc...).
NB : j'y vais très très très rarement sur le site ftp :-)
- "Les micro-processeurs Intel Pentium accélèrent Internet"
C'est du français aussi.
J'espère que tu vois ce qu'il y a de marketeu dedans.
> "faire à la place de l'utilisateur" d'ou le "prise de controle" => prendre, enlever à l'utilisateur le controle de la machine.
Qu'on dise ça dans le cadre d'un formation par exemple où le prof veut montrer à l'élève ce qu'il faut faire ou pour décoincer d'élève qui a fait une connerie, je comprend parfaitement.
Dans ce cas, on prend le contrôle "des opérations" (et pas du pc).
Mais VNC n'est pas nécessaire pour faire cette reprise de contrôle. Le prof peux aussi te déplacer et faire le boulot sur le poste directement.
Idem, je peux te donner mon cooki linuxfr (ou un admin peut le faire) et tu peux reprendre temporairement le contrôle "sur linuxfr" le temps de faire des modifications de préférence de mon profile que je n'arrive pas à faire (c'est un exemple farfelu, je sais).
Techniquement et d'un point de vu informatique (au moins pour vnc) ce n'est pas une "prise de contrôle".
Ben il ne l'appèle comme ça. Ça permet de reprendre un session existante.
Que ça te permette de reprendre le contrôle sur les conneries d'un étudiant est une autre histoire.
ssh et rsh ne font pas shell !
Les shells ne s'occupent pas de marcher à distance ou non. Les shell tournent sur un terminal ou un pseudo terminal. Pour un shell, un terminal distant, ça n'existe pas.
> il s'agit bêtement d'un outil de prise de controle à distance.
Comme un clavier ou un terminal sur RS232 ?
Il règne une confusion dans votre "cerveau".
> est un moyen simple/efficace de controler tout le bureau et l'interface graphique.
Comme X11.
Donc X11 est un moyen pour prendre le contrôle.
Changement de vocabulaire !
"je me loggue" est remplacé par "je prends le contrôle"
Et si c'est un système multi-utilisateur.
Ben on est plusieurs à avoir le contrôle en même temps. Bonjours le bordel.
Je me connecte à linuxfr, je peux récupérer ma session sur une autre navigateur , qui peut aussi être sur un autre post, suffit de copier le cookie.
Questions :
- Es-ce que je prend le contrôle de Linuxfr ?
- Les cookies/navigateurs sont-ils un moyen de prise de contrôle ?
Coup de gueule :
Pour faire "in" on utilise des expression du monde marketing ("prise de contrôle à distance") et on finit par être complètement polué et à penser de travers.
> il se peut que les brevets ne valent pas un clou.
Si, ils sont tout à fait valables.
Valables selon Red Hat et c'est pour celà que Valgrind n'était pas diffusé par Red Hat/Fedora.
Ben Valgrind a fait son apparation il y a quelques semaines dans Fedora Core.
> ca voulait dire quoi pour toi alors "prise de controle" ?
Rien ou presque dans un contexte informatique "classique".
"Prise de contrôle" me fait penser a quelqu'un qui prend le contrôle de mon PC à "l'insu de mon plein grès". Bref, un virus ou l'exploitation d'un trou de sécurité.
> J'aurais plutot parlé de ssh, rlogin ou autre ... que de screen, mais bon ...
ssh ou rlogin tu ne peut pas continuer ailleur une session.
avec screen, tu peux.
btw, screen n'est pas équivalent à ssh et screen n'a rien pour contrôler le PC. Tu as accès aux commandes du PC avec tes privilèges (si tu as un shell, ce qu'il ne préoccupe en rien screen (ni vnc d'ailleur)). Screen ne te donne pas plus de contrôle que ce que veut bien t'accorder le système.
Question :
ssh est-il un moyen de connection à distance ou un système de prise de contrôle à distance ?
Je commence à comprendre.
Lorsque les gens parlent de "prise de contrôle", il parle de continuer une session ailleur.
Mouaifff.
Dans ce cas, screen fait aussi de la "prise de contrôle" (à distance ou pas) de machine.
> Lorsque le serveur VNC est installlé sous Windows, on peut dire qu'il y a prise de contrôle à distance de la bécane.
C'est lié à une limitation de Windows. Et ce n'est vraiment pas une "feature".
D'ailleur, je ne sais pas si cette limitation existe toujours...
Si pour avoir le label "prise de contrôle à distance" un programme dépend d'une limitation/bug, c'est bien la preuve que le programme ne fournit pas les fonctionnalités pour faire de la "prise de contrôle à distance". S'il n'a pas de telles fonctionnalités ...
ils ont écrit un client-serveur permettant la prise de contrôle à distance (comme VNC)
Je ne sais pas pour vous, mais quand j'utilise VNC ou X11, j'ai pas l'impression de prendre le contrôle à distance d'une bécane... surtout si je ne suis pas sous le compte root.
Le serveur est sur la bécane "locale" et les clients sont des programmes (pas une machine) qui sont clients de capacités graphiques et non de "prise de contrôle".
"prise de contrôle à distance" ne veut rien dire ici.
IBM a acheter Rational qui possédait des brevets utilisés par Valgrind. Or il y a quelques semaines IBM a annoncé autoriser l'utilisation de ses brevets par le LL.
Donc Valgrind est maintenant un "vrai" logiciel libre.
Je ne connais pas kile ni rien de l'histoire. Souvent ce type de bug (spécifique à une distribution) n'est pas lié à une modification du paquet (ici kile) mais à l'environnement de la distribution.
Par exemple, Red Hat est en utf-8, ils ont exec-shield, depuis peu l'adressage mémoire du noyau est différent. Souvent Red Hat à la dernière version de la lib C. Maintenant il y a SeLinux. Etc...
Ce type de problème, n'implique pas que RedHat fait de mauvais paquets KDE. Et en générale ce type de problème se retrouve dans plusieurs programmes (KDE/GNOME/etc) et aussi dans la version upstream.
Pour fixer ce problème :
- Red Hat corrige son problème si c'est une erreur de leur côté.
- La modification de Red Hat est juste mais incompatible avec d'autres programmes. Typiquement utf8, exec-shield, selinux, etc. Soit Red Hat estime le paquet important ou le problème grave et il corrige eux même le problème, soit le problème est considéré comme mineur par Red Hat (à tord ou à raison, c'est une autre histoire) et dans ce cas il faut attendre le fixe en upstream qui finira par arriver dans Red Hat (ça peut être long).
Il faut garder en tête que chaques distributeurs à des compétences propres et ses "chouchous".
Si tu veux un bon support (au sens large) pour KDE, il faut regarder du côté de SuSE.
Ça ne veut pas dire que Red Hat fait du mauvais boulot mais simplement que SuSE est meilleur pour KDE comme Red Hat est meilleur que SuSE pour Gnome.
S'il y a un petit problème avec KDE, Suse a les compétences pour corriger ce petit problème.
Si SuSE engage une modification du noyau qui impact les programmes, SuSE peu savoir par avance que tel out tel programme de KDE doit être mise à jour et contacter le mainteneur du paquet (qui peut aussi être employé SuSE).
Ceci a été discuté pour reiserfs sur la mailing devel de Fedora. Et Red Hat a reconnu que Fedora sera moins bon que SuSE pour reiserfs simplement car SuSE a les compétence en reiserfs.
C'est la vie.
Mais les idées de complots/sabotages, de patchs à chier, etc
=> poubelle.
> n'empeche qu'il reste encore des bugs "KDE-redhat only"
> Peut-être qu'ils ne massacrent plus KDE
C'est faux. Ça relève du troll et c'est tout. Si tu as réellement un problème de ce type, vas sur : http://bugzilla.redhat.com/(...)
btw, cherches dans la base bugzilla pour trouver des problèmes spécifiques aux petits patchs RedHat (même pour des vieilles versions de Red Hat). Je ne parle pas de problèmes de paquetage ou que l'on trouve aussi en upstream.
A ma connaissance, pour lire la mailing devel depuis longtemps, c'est très rare.
> je l'attendais celle la! KDE n'est PAS lourd
Je parlais de l'interface graphique (fonctionnalité/configuration). Pas en temps de chargement/place mémoire/charge cpu, etc.
Sachant que tu dis qu'ils enlevent des "fonctionnalités et cie", ça m'a fait "bizarre".
[^] # Re: Re:
Posté par 007 . En réponse au journal Sun dépassé?. Évalué à 3.
Avant Red Hat tournait et supportait sparc et alpha.
sparc et alpha ne sont plus supportés.
IA64 a été introduit.
Puis AMD64.
Il reste x86/IA64/AMD64 et :
- ppc (pas mac mais IBM eServer pSeries)
- s390 (IBM)
Que voit-on dans la branche rawhide de Fedora :
http://fr2.rpmfind.net/linux/fedora/core/development/(...)
Pas de sparc ni alpha alors que Red Hat a toujours été souple pour Rawhide.
C-à-d que Sparc et Alpha n'est même plus intéressant (et vraiment pas manifestement) pour une distributeur qui cible les stations de travail et serveurs.
# Re:
Posté par 007 . En réponse au journal Sun dépassé?. Évalué à 7.
Leurs jours (mois) sont comptés et ils (Sun, etc) le savent.
C'est très bien d'afficher une super fiabilité pour le matos bas de gamme. Mais au prix d'un sparc bas de gamme, j'achetes 3 PC bas de gammes qui sont plus performants avec plus de mémoire, plus de disque, qui ont plus de programmes/OS, etc...
C'est jouée d'avance.
Pour l'OS, Unix va aussi se casser la gueule et vite (toujours pour les micro et mini).
On parle de Windows vs Linux, mais en premier et de façon sûre (pour moi), Linux va bouffer Unix et vite fait.
Pour Windows ou Mac, ce n'est pas gagné.
[^] # Re: Valgrind libre
Posté par 007 . En réponse à la dépêche Valgrind 2.2.0. Évalué à 1.
En attendant, le brevet est valide.
Que le brevet soit intelligent ou non, qu'il soit une copie de ce qui existait déjà depuis 200 ans, etc ne change rien à ça (malheureusement).
[^] # Re: Si j'ai bien tout compris...
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à 4.
Tu parles d'un serveur. Or normalement un serveur n'est pas lancé par un utilisateur mais à l'init du système.
Et même dans ce cas...
Tu peux lancer plusieurs mysqld et depuis les comptes utilisateurs (faut faire attention aux ports).
btw, il ne faut pas mélanger les comptes de l'OS et les comptes de mysql par exemple.
Donc tu peux très bien avoir une machine avec plusieurs mysqld/postgresql/apache/bind/etc (tous différents si tu veux (mélanger mysql v3 et v4)) qui tournent en même temps.
Pour ton info, la majorité des services sous Unix tourne sur des comptes dédiés.
Il y a quelque cas où il faut développer en fesant attention à l'aspect multi-utilisateur de l'OS (atd, crond, etc). Mais c'est très très limité par rapport à l'ensemble des applis Unix/Linux.
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à 0.
Me suis mal exprimé.
Lorsque l'édutiant fait une manip, si tu veux reprendre le "contrôle des opérations", tu ne prends pas le contrôle sur le PC mais sur la manip en cours. Je parlais de prendre le contrôle des opérations de la manip (qui peut passer par avoir l'exclusivité du PC. Mais c'est une autre histoire).
> que tu fais correspondre avec "avoir un acces root".
Imaginons deux postes de commande d'une barrière, distants de 200 mètres. Le poste A (pour le patron) et le poste B. Il n'y en a qu'un qui peut être actif à la fois. Pour passer d'un poste à l'autre, il y a un interrupteur (coupure du courant d'un poste et arrivé du courant pour l'autre) sur le poste A (poste uniquement accessible au patron). Cet interrupteur permet de décider quel poste commande la barrière (poste A ou B).
Question :
Un interrupteur est-il un moyen de "prise de contrôle à distance" ?
Voilà le problème. On mélange l'usage fait d'un objet et l'objet lui-même.
Un interrupteur reste un interrupteur même dans un contexte où il est utilisé pour faire de la "prise de contrôle à distance".
Soit on parle de l'interrupteur (intensité maxi, etc), soit au parle du dispositif de "prise de contrôle à distance" (un interrupteur, mis dans une pièce uniquement accessible au patron, des fils qui relient le poste A et B, etc).
Maintenant remplace "interrupteur" par VNC/PCpartout/etc, les postes de commandes par des PC (ça tombe bien (PC)), la pièces uniquement accessible par le patron par un mot de passe uniquement connu du patron pour le poste A, etc...
On a remplacé notre interrupteur par un système de transport d'affichage et un gestionnaire de session etc... mais pas par un système de "prise de contrôle à distance".
Pour utilisateur final, VNC lui permet d'obtenir le contrôle à distance de la barrière comme avec l'interrupteur.
Comme avec l'interrupteur, VNC n'a aucune information sur le fait qu'il permet "la prise de contrôle à distance" de la commande d'une barrière. Il ne fait que changer le lieu de l'affichage, le terminal. VNC est là pour ça et le fait bien.
btw, il y a plein de cas où VNC n'est pas utilisé pour faire de la "prise de contrôle à distance" (inhiber une session sur un poste et utiliser la session sur un autre poste). D'ailleur, je ne serais vraiment pas, mais vraiment pas étonné, que ça ne soit qu'un usage mineur.
[^] # Re: Si j'ai bien tout compris...
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à 0.
L'un ne va pas sans l'autre.
Sous Unix tu n'as pas besoin de le faire exprès pour qu'un soft soit multi-utilisateur.
[^] # Re: Valgrind libre
Posté par 007 . En réponse à la dépêche Valgrind 2.2.0. Évalué à 0.
Quand je dit que les brevets Rational (maintenant IBM) sont valables, je dis valable pour une agence de brevet, la justice.
Pour moi un brevet n'est pas valable.
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -2.
Ce qui est toujours ridicule.
Prend le controle d'un train lancé à pleine vitesse, prend le contrôle d'un outil de production pour augmenter la production, etc.
Prendre le contrôle d'une session n'a aucun sens.
Que _fait_ un train : il avance
Que _fait_ un outil de production : il controle/participe à la production
Que _fait_ une session d'un utilisateur : rien.
> Pratiquement et d'un point de vue pragmatique, si.
Un couteau permet de tuer ou de bouffer du jambon mais outil "pour tuer" ou "bouffer du jambon" n'est pas sa définition.
D'un point vue "pragmatique", une voiture permet d'aller en vacance.
Mais la voiture reste un moyen de déplacement et pas un moyen pour aller en vacance. Un moteur, qu'on trouve dans une voiture n'est pas :
- Le truc qui fait accélérer la machine pour aller en vacance.
Pourtant des gens qui vont en vacance en voiture, il y en a beaucoup plus que d'utilisateurs de PCanywhere.
> Ce dont il parle, c'est pas de la prise de contrôle, c'est de la "persistance de session".
Parfaitement.
[^] # Re: oulà non
Posté par 007 . En réponse au journal Gnome 2.8 rc1 (2.7.92) is dehors. Évalué à 1.
Je me rappèle de les annonces (depuis 2.2 ?) avait platform et desktop.
Par contre, c'est la premier foi que je vois ça pour le site ftp (un répertoire pour desktop, un autre pour platform, etc...).
NB : j'y vais très très très rarement sur le site ftp :-)
Récent ou pas, c'est très bien.
[^] # Re: TSE et CITRIX
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -1.
Je comprends...
http://linuxfr.org/comments/466009.html#466009(...)
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à 0.
- "Les micro-processeurs Intel Pentium accélèrent Internet"
C'est du français aussi.
J'espère que tu vois ce qu'il y a de marketeu dedans.
> "faire à la place de l'utilisateur" d'ou le "prise de controle" => prendre, enlever à l'utilisateur le controle de la machine.
Qu'on dise ça dans le cadre d'un formation par exemple où le prof veut montrer à l'élève ce qu'il faut faire ou pour décoincer d'élève qui a fait une connerie, je comprend parfaitement.
Dans ce cas, on prend le contrôle "des opérations" (et pas du pc).
Mais VNC n'est pas nécessaire pour faire cette reprise de contrôle. Le prof peux aussi te déplacer et faire le boulot sur le poste directement.
Idem, je peux te donner mon cooki linuxfr (ou un admin peut le faire) et tu peux reprendre temporairement le contrôle "sur linuxfr" le temps de faire des modifications de préférence de mon profile que je n'arrive pas à faire (c'est un exemple farfelu, je sais).
Techniquement et d'un point de vu informatique (au moins pour vnc) ce n'est pas une "prise de contrôle".
Un employé de Red Hat bosse sur ce que tu pourrais (du moins il me semble) appeler un système de "prise de contrôle" :
http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg000(...)
Ben il ne l'appèle comme ça. Ça permet de reprendre un session existante.
Que ça te permette de reprendre le contrôle sur les conneries d'un étudiant est une autre histoire.
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à 3.
ssh et rsh ne font pas shell !
Les shells ne s'occupent pas de marcher à distance ou non. Les shell tournent sur un terminal ou un pseudo terminal. Pour un shell, un terminal distant, ça n'existe pas.
> il s'agit bêtement d'un outil de prise de controle à distance.
Comme un clavier ou un terminal sur RS232 ?
Il règne une confusion dans votre "cerveau".
> est un moyen simple/efficace de controler tout le bureau et l'interface graphique.
Comme X11.
Donc X11 est un moyen pour prendre le contrôle.
Changement de vocabulaire !
"je me loggue" est remplacé par "je prends le contrôle"
Et si c'est un système multi-utilisateur.
Ben on est plusieurs à avoir le contrôle en même temps. Bonjours le bordel.
Je me connecte à linuxfr, je peux récupérer ma session sur une autre navigateur , qui peut aussi être sur un autre post, suffit de copier le cookie.
Questions :
- Es-ce que je prend le contrôle de Linuxfr ?
- Les cookies/navigateurs sont-ils un moyen de prise de contrôle ?
Coup de gueule :
Pour faire "in" on utilise des expression du monde marketing ("prise de contrôle à distance") et on finit par être complètement polué et à penser de travers.
[^] # Re: Valgrind libre
Posté par 007 . En réponse à la dépêche Valgrind 2.2.0. Évalué à 2.
[^] # Re: Valgrind libre
Posté par 007 . En réponse à la dépêche Valgrind 2.2.0. Évalué à 5.
Si, ils sont tout à fait valables.
Valables selon Red Hat et c'est pour celà que Valgrind n'était pas diffusé par Red Hat/Fedora.
Ben Valgrind a fait son apparation il y a quelques semaines dans Fedora Core.
Ce problème était dans bugzilla de Red Hat :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78403(...)
Le bug est maintenant fermé.
> Et il y avait eu des menaces du cote de valgrind ?
Mauvais cette façon d'aborder les brevets/copyright/etc.
SCO n'est pas prévenu avant de faire chier. Heureusement pour nous, ça ne marche pas.
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -1.
Rien ou presque dans un contexte informatique "classique".
"Prise de contrôle" me fait penser a quelqu'un qui prend le contrôle de mon PC à "l'insu de mon plein grès". Bref, un virus ou l'exploitation d'un trou de sécurité.
> J'aurais plutot parlé de ssh, rlogin ou autre ... que de screen, mais bon ...
ssh ou rlogin tu ne peut pas continuer ailleur une session.
avec screen, tu peux.
btw, screen n'est pas équivalent à ssh et screen n'a rien pour contrôler le PC. Tu as accès aux commandes du PC avec tes privilèges (si tu as un shell, ce qu'il ne préoccupe en rien screen (ni vnc d'ailleur)). Screen ne te donne pas plus de contrôle que ce que veut bien t'accorder le système.
Question :
ssh est-il un moyen de connection à distance ou un système de prise de contrôle à distance ?
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -1.
Autre exemple :
MS-DOS a de supers features temps-réel.
Ou (et c'est plus juste) MS-DOS n'est pas multi-tâche, n'a pas de mode kernel/user, etc.
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -1.
Lorsque les gens parlent de "prise de contrôle", il parle de continuer une session ailleur.
Mouaifff.
Dans ce cas, screen fait aussi de la "prise de contrôle" (à distance ou pas) de machine.
Je me casse, je ne cause pas le marketeux.
[^] # Re: Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -2.
C'est lié à une limitation de Windows. Et ce n'est vraiment pas une "feature".
D'ailleur, je ne sais pas si cette limitation existe toujours...
Si pour avoir le label "prise de contrôle à distance" un programme dépend d'une limitation/bug, c'est bien la preuve que le programme ne fournit pas les fonctionnalités pour faire de la "prise de contrôle à distance". S'il n'a pas de telles fonctionnalités ...
> mais " d'ouverture de session "
Toujours pas...
C'est [xkg]dm qui fait ça.
# Marketing
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -2.
ils ont écrit un client-serveur permettant la prise de contrôle à distance (comme VNC)
Je ne sais pas pour vous, mais quand j'utilise VNC ou X11, j'ai pas l'impression de prendre le contrôle à distance d'une bécane... surtout si je ne suis pas sous le compte root.
Le serveur est sur la bécane "locale" et les clients sont des programmes (pas une machine) qui sont clients de capacités graphiques et non de "prise de contrôle".
"prise de contrôle à distance" ne veut rien dire ici.
# Valgrind libre
Posté par 007 . En réponse à la dépêche Valgrind 2.2.0. Évalué à 4.
Donc Valgrind est maintenant un "vrai" logiciel libre.
# DÉJÀ !
Posté par 007 . En réponse au journal Yuummm ! On va se régaler !. Évalué à 1.
http://fr2.rpmfind.net/linux/fedora/core/development/SRPMS/yum-2.1.(...)
http://fr2.rpmfind.net/linux/fedora/core/development/i386/Fedora/RP(...)
Et la branche de développement (rawhide) utilise déjà le nouveau format de donnée :
http://fr2.rpmfind.net/linux/fedora/core/development/i386/repodata/(...)
[^] # Re: oh, un troll!
Posté par 007 . En réponse au journal Yuummm ! On va se régaler !. Évalué à 2.
Je ne connais pas kile ni rien de l'histoire. Souvent ce type de bug (spécifique à une distribution) n'est pas lié à une modification du paquet (ici kile) mais à l'environnement de la distribution.
Par exemple, Red Hat est en utf-8, ils ont exec-shield, depuis peu l'adressage mémoire du noyau est différent. Souvent Red Hat à la dernière version de la lib C. Maintenant il y a SeLinux. Etc...
Ce type de problème, n'implique pas que RedHat fait de mauvais paquets KDE. Et en générale ce type de problème se retrouve dans plusieurs programmes (KDE/GNOME/etc) et aussi dans la version upstream.
Pour fixer ce problème :
- Red Hat corrige son problème si c'est une erreur de leur côté.
- La modification de Red Hat est juste mais incompatible avec d'autres programmes. Typiquement utf8, exec-shield, selinux, etc. Soit Red Hat estime le paquet important ou le problème grave et il corrige eux même le problème, soit le problème est considéré comme mineur par Red Hat (à tord ou à raison, c'est une autre histoire) et dans ce cas il faut attendre le fixe en upstream qui finira par arriver dans Red Hat (ça peut être long).
Il faut garder en tête que chaques distributeurs à des compétences propres et ses "chouchous".
Si tu veux un bon support (au sens large) pour KDE, il faut regarder du côté de SuSE.
Ça ne veut pas dire que Red Hat fait du mauvais boulot mais simplement que SuSE est meilleur pour KDE comme Red Hat est meilleur que SuSE pour Gnome.
S'il y a un petit problème avec KDE, Suse a les compétences pour corriger ce petit problème.
Si SuSE engage une modification du noyau qui impact les programmes, SuSE peu savoir par avance que tel out tel programme de KDE doit être mise à jour et contacter le mainteneur du paquet (qui peut aussi être employé SuSE).
Ceci a été discuté pour reiserfs sur la mailing devel de Fedora. Et Red Hat a reconnu que Fedora sera moins bon que SuSE pour reiserfs simplement car SuSE a les compétence en reiserfs.
C'est la vie.
Mais les idées de complots/sabotages, de patchs à chier, etc
=> poubelle.
[^] # Re: oh, un troll!
Posté par 007 . En réponse au journal Yuummm ! On va se régaler !. Évalué à 1.
> Peut-être qu'ils ne massacrent plus KDE
C'est faux. Ça relève du troll et c'est tout. Si tu as réellement un problème de ce type, vas sur :
http://bugzilla.redhat.com/(...)
btw, cherches dans la base bugzilla pour trouver des problèmes spécifiques aux petits patchs RedHat (même pour des vieilles versions de Red Hat). Je ne parle pas de problèmes de paquetage ou que l'on trouve aussi en upstream.
A ma connaissance, pour lire la mailing devel depuis longtemps, c'est très rare.
> je l'attendais celle la! KDE n'est PAS lourd
Je parlais de l'interface graphique (fonctionnalité/configuration). Pas en temps de chargement/place mémoire/charge cpu, etc.
Sachant que tu dis qu'ils enlevent des "fonctionnalités et cie", ça m'a fait "bizarre".
[^] # Re: oh, un troll!
Posté par 007 . En réponse au journal Yuummm ! On va se régaler !. Évalué à 1.
Très peu de fonctionnalités sont retirées (d'ailleur je trouve KDE toujours aussi "lourd" :-)). Regardes les src.rpm de Fedora pour t'en convaincre.
Le principale avantage de kde-redhat maintenant, est d'avoir la dernière version de KDE.
[^] # Re: Mur
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
> Unix, même époque que le language C. C-à-d fin 60 début 70.
Début développement. Premières versions vraiment exploitables en 73-75.