Obsidian a écrit 5299 commentaires

Surtout si derrière tu fait linux-friser ton site, le compteur de vite risque d'être très vite très musclé ! :-)

Ah ? Ce serait interressant de faire un reportage sur l'unique 1% des utilisateurs qui achètent leurs logiciels ! :-)

Possible, mais j'attends de voir d'abord.

C'était « Crazy George ». Je me souviens d'ailleurs d'une scène des Guignols de l'Info mémorable à ce sujet.

Le concept n'était pas nouveau, cela s'appelle le leasing. Cela a déclenché les passions de bon nombre de gens, mais personne n'a remis en cause le principe de la location. Si mon bailleur avait fait de même pour la maison familliale, nous serions propriétaires aujourd'hui ...

Balmer et consors n'ont rien à voir avec cela. Pour eux, il s'agit de maintenir le monopole, et surtout de bien faire en sorte que les gens ne connaissent QUE CA, et ils multiplient les coups bas comme les réductions de 90% sur les licences - avec une provision d'argent dédiée à cela - lorsque cela les arrange, alors qu'on nous bourre le mou d'autre part pour nous dire que Pirater, C'est Mal ™, que le logiciel est un produit de luxe et que les compagnies n'auront bientôt plus rien à manger si cela continue. Tout cela sachant qu'ils ont plus à gagner à se battre avec la justice qu'avec leurs concurrents.

C'est la pire forme de concurrence déloyale qui puisse exister. A vrai dire, c'est même presque un cas d'école.

parce que les hommes ont la capacité de se mouvoir,
parce que nous adorons voir ce que les utilisateurs font avec de nouveaux produits ...

Si ça se trouve, c'est peut-être juste des T-shirt ou des casquettes « Mandrake ». C'est les copines-de-geek qui vont être contentes ! :-)

PS: J'utilise Mandrake, donc je ne critique pas.

Et à tous hasard, jette aussi un oeil dans /lost+found
Avec une Mandrake 9.1 et un filesystem ext2 des familles, lors d'un reboot un peu trop violent, les fichiers que je perds sont pratiquement toujours ceux qui sont ouverts au moment du crash.

En général, tu les retrouves dans ce répertoire (et s'il n'existe pas, je ne saurais trop te recommender de le créer). Il aura probablement perdu son nom, mais ses major/minor dans le cas d'un device ou son contenu dans le cas d'un fichie régulier, eux, seront toujours là ....

Non, non. Trollons, trollons ... :-)

En gros, le standard USB a eu la bonne idée d'inclure la définition générique des systèmes de stockage. Tant et si bien qu'un périphérique de stockage qui se branche sur l'USB n'a pas besoin de pilote, puisque le layer USB fait tout le travail. C'est ce qui permet aux clés USB de fonctionner partout sans se faire suer et qui participe à leur succès.

Sauf qu'effectivement Win98 gère cela très mal, et cela oblige les fabricants de clés USB à fournir une disquette de pilote dans la boite de chacune de ces clés pour palier à ce problème.

Monopole, quand tu nous tiens (dans tous les sens du terme) ...

Tout d'abord, bravo et merci pour vos efforts.

Ensuite, il y a une chose qu'il faut garder à l'esprit, c'est que la loi française autorise le reverse-enginering lorsque c'est pour un usage légitime du produit dont tu as la licence d'exploitation et lorsque que l'auteur ou le détenteur des droits ne met pas ces infos à disposition:

Art. L. 122-6-1. I. Les actes prévus aux 1° et 2° de l'article L. 122-6 ne sont pas soumis à l'autorisation de l'auteur lorsqu'ils sont nécessaires pour permettre l'utilisation du logiciel [1], conformément à sa destination, par la personne ayant le droit de l'utiliser, y compris pour corriger des erreurs. [...]

Il faut ensuite interpréter les conditions:

[...] 1° Ces actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin ;
2° Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au 1° ci-dessus ;
3° Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité.
Les informations ainsi obtenues ne peuvent être :
1° Ni utilisées à des fins autres que la réalisation de l'interopérabilité du logiciel créé de façon indépendante ;
2° Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante;
3° Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.
V. Le présent article ne saurait être interprété comme permettant de porter atteinte à l'exploitation normale du logiciel ou de causer un préjudice injustifié aux intérêts légitimes de l'auteur.
Toute stipulation contraire aux dispositions prévues aux II, III et IV du présent article est nulle et non avenue.

Donc, en gros:

- Effectivement, adieu la GPL, mais rien ne t'empêche de diffuser un pilote binaire libre. Tu peux également transmettre les informations à des tiers si ceux-ci participent au développement du projet et s'engagent à ne pas diffuser ces informations (autrement dit, tu mets ton propre NDA sur ton fork).
- Cela prend fin le jour où le fabricant décide de diffuser - ou de commercialiser - ses propres pilotes.


Toutes les infos ici:
http://www.celog.fr/cpi/index.htm(...)

Oui, cela me parait très bien. En fait, je pense que c'est exactement les actions qu'il faut mener, et dans cet ordre.

J'ajoute qu'en ce qui concerne hoaxbuster, ils peuvent très bien diffuser l'information en la qualifiant de "vraie" (le feu vert). Mais pour ce faire, il faudrait d'abord que l'info circule d'elle-même, de mail en mail. Or, amorcer ce phénomène correspond à du spam, et faire relayer de la sorte des infos n'est de toute façon jamais sans risque. En plus, on risquerait de dénaturer le problème dans l'esprit des lecteurs: « LG fabrique des lecteurs défectueux -> C'est arrivé à l'installation d'une Mandrake 9.2 -> J'm'en fous moi j'utilise Windows -> Windows c'est secure, Linux c'est dangereux. ».

Pour le reste, que du tout bon.

Tiens, puis pendant qu'on y est, autant prendre les bonnes habitudes de suite:
bouge donc le param[1]=argv[i] au dessus du fork(). Comme ca, ca évite la modification de variables dans le processus fils et donc la duplication des pages de RAM (surtout si elles sont destinées à être écrasées par le execve() ).

Merci.. J'avais en effet une grave erreur de compréhension de ma part.

Et ce ne sera pas la dernière, loin de là ! Mais c'est comme ça que l'on finit par devenir guru ! :-)

Si tu fais un argv+(i+1), tu ne transmets pas un argument à la fois mais la fin du tableau, avec chaque fois un élément en moins. Essaie plutôt:


/* Programme qui lance plein d'applications */

#include <unistd.h>
#include <stdio.h>
#include <errno.h>

int main (int argc,char **argv)
{
if (argc>1)
{
int i;
int r;
char * param [3];

param [0] = argv[0];
param [2] = NULL;

for (i=1;i<argc;i++)
{
r=fork();

if (!r)
{
param [1] = argv [i];
if (execve("./programme",param,environ)<0) perror ("Erreur sur execve");
}
else if (r<0) perror ("erreur sur fork()");
}
}
else fprintf (stderr,"Merci de spécifier des arguments");

return 0;
}

Cela vient probablement du argv+1 qui doit être transmis tel quel au nouveau programme. le "+1" ici permet de shifter tous les arguments vers la gauche et d'éjecter le nom du fichier originel.

Essaie d'utiliser juste "argv" ou alors de lancer le programme tel quel mais en passant un argument dans ta ligne de commande (qui correspondrait par exemple au nom que tu voudrais donner à l'autre programme :-) ).

"Bad adress" = EFAULT = Une segfault à l'appel de ta fonction = un pointeur fou.

Lis la man page de execve, il parle de l'argument "fichier", mais à mon avis c'est le pointeur env qui est initialisé à zéro qui ne lui plaît pas. Suis mon exemple ci-dessous ou celui de Christophe GRAND, et dis-nous si ça marche.

Je crois qu'il y a belle lurette que les occupants de ce canal ont cessé d'essayer d'avoir l'air malin.

char **env = 0;
int result = execve("monpremier programme", argv + 1, env);


#include <unistd.h>
int result = execve("monpremier programme", argv + 1, environ);

Comme ça, tu transmets les variables d'environnement.
(void man environ).

export PATH=$PATH:.

peut-être ?

Mais le plus propre serait d'ajouter "./" au début du nom de ton fichier.

Sale affaire, d'autant plus grave que Mandrake n'y est pour rien !

Mais l'éducation des gens en informatique et l'état des monopoles actuels font que c'est Mandrake - qui a connu des jours meilleurs - qui doit faire les frais d'une erreur de conception sur une seule marque de lecteur.

Si l'erreur se produisait à l'installation de la nouvelle mouture de Windows, Microsoft corrigerait probablement ses masters aussi, mais je ne pense pas qu'il y aurait rappel. Et dans tout les cas (puisque ce serait largement relayé dans la presse spécialisée), l'organisme mis en cause serait clairement LG, et personne d'autre.

Probablement mais, tu dois le savoir très bien d'ailleurs, David N. Cutler, en charge du projet VMS chez Digital, a été débauché par Microsoft pour développer WNT, et la rumeur est née de là. D'ailleurs l'une des principales couches de ce dernier système est HAL (Hardware Abstraction Layer) qui isole le système des spécificités techniques de chaque machine ...

C'est sûr qu'avec de tels exemples, ils ne pouvaient pas produire un OS fiable ... :-)

La vache, un PS qui freeze ta session ? C'est violent ...
Tes process sont en state "D", je suppose ? Il n'y a pas beaucoup de doc la-dessus, mais cela m'est déjà arrivé avec des noyaux 2.2.x et 2.4.x . Spécialement avec Netscape.

Un admin m'a dit un jour que cela arrivait souvent sur les accès aux fichiers, et qu'il fallait attendre que le kernel finisse ce qu'il doit faire, donc, je suppose que cela arrive lorsque le kernel fait une opération « atomique » sur ton processus mais qu'il attend quand même quelque chose de l'extérieur. Cela arrive typiquement avec les I/O. Tu dois pouvoir prendre un "D" lorsque tu tues un processus qui avait ouvert des fichiers au travers d'un NFS, par exemple, et que celui-ci n'est plus accessible. Le kernel va essayer de nettoyer tout ce qui a été laissé en plan par le processus, notament fermer les fichiers, mais cette opération est l'initiative du noyau, et pas celle du processus, censé être mort, et qui ne peut donc plus recevoir aucun code de retour. Si le NFS est down, le VFS va attendre ad vitam aeternam la réponse des couches de plus bas niveau (en tout cas, jusqu'à un timeout du VFS), ce qui veut dire que c'est le kernel lui-même qui ne rend plus la main. Cela doit aussi arriver sur des périphériques lents alors qu'ils ne sont pas censés l'être (lecture sur un CD rayé, par exemple). Je suppose qu'il doit également y avoir moyen de provoquer des deadlocks entre des tubes ou des sockets.

Bon tout cela est très hypothétique. C'est peu documenté car cela ne devrait pas arriver. Je m'en vais potasser les sources du noyau pour voir si je trouve plus d'infos.

En tout cas, la moralité de l'histoire est que lorsque cela arrive, la première chose à faire est d'essayer de trouver ce qui bloque ton processus, et le premier endroit où regarder est /proc/fd, qui contient les descripteurs de tous les fichiers ouverts par le processus.

Bon courage.

Hmm, j'ai pas vu le film mais vu les restrictions gouvernementales actuelles concernant la durée du chômage, mais également les aides en tous genres accordées notament aux personnes en stage, je ne pense pas que ce soit encore d'actualité, malheureusement.

En dehors de çà, j'ai toujours adhéré à l'idée de ne pas perdre sa vie à la gagner, d'autant que bien souvent, le premier job que l'on récupère après une carrière honorable fait perdre ses droits au chômage et rapporte moins que les allocations perçues avant, mais malgré cela, je ne pense pas qu'inciter les gens à ne pas travailler soit une bonne idée.

Si justement on peut se permettre un temps mort entre deux emplois pour se retrouver un peu, c'est parce que l'on a un système qui permet de le faire et que beaucoup de gens nous envient. En abuser reviendrait à le saborder, et là, c'est tout le monde à la rue.

At this point, please do not install Mandrake Linux 9.2 on any computer containing a LG-based CD-ROM drive or it will damage your CD-ROM drive.

Ce n'est pas les CD-ROM d'installation que Mandrake/Linux va tuer, c'est le lecteur lui-même ! Pourtant je ne leur jette pas la pierre (d'ailleurs j'utilise moi-même Mandrake 9.1).

a) Comment se fait-il qu'en 2003, on trouve encore du matériel que l'on puisse griller logiciellement ?
b) Comment se fait-il qu'en 2003, on trouve encore des fabricants qui ne sachent pas ce qu'est Linux ?

Pour a), imaginez un peu que quelqu'un répande un virus Windows qui exploite cette faiblesse. La publicité que cela engendrerait pousserait probablement le fabricant à améliorer ses produits.

Pour b), c'est déjà limite acceptable pour un éditeur de logiciel, qui s'appuie sur le système d'exploitation. Cela ne l'est pas du tout de la part d'un fabricant de pièces détachées comme un lecteur de CD qui devrait tout au plus se baser sur le standard ATA pour les lecteurs IDE.

Sans réponse valable à ces deux questions, je considère que ce fabricant est à exterminer de la même façon que les trolls régulièrement tapis dans les coulisses de DLFP.

ASM roulaize !

Rien de tel que de découvrir comment fonctionne réellement sa bécane.
Sinon vient le C, puis le Bash, puis le C++ et enfin un peu de Basic 512 :-)

Voila pour mes préférences.

Et moi aussi !
Rien que pour cela, ça mérite un [+] :-)

Bon, tout cela est bien beau, mais pourquoi n'installes-tu pas un bootloader, comme tout le monde ?

Un bon petit LILO ou GRUB des familles, un menu de démarrage, une temporisation d'environ 10 secondes, et tu ne t'emmerde plus à faire mumuse avec fdisk ou que sais-je ...