Obsidian a écrit 5291 commentaires

« Kikoo ! All your skyblogs are belong to us LoL ! »

Perso, pas de problème. Je veux bien leur laisser ...

C'est surtout que l'on risque rien tant que les brevets logiciels n'ont aucune valeur chez nous. Après ...

Pour les cas présents, il est très facile de démontrer l'antériorité de l'affaire. Pour le reste, on risque d'entrer dans des batailles juridiques sans fin avant d'arriver à prouver sa bonne foi, mais ça tout le monde le sait déjà. Sauf que nous ne sommes pas (encore) des américains, dont toute la société est basée sur le dollar. Ce n'est pas un jugement de valeur, c'est juste que le modèle serait encore plus nocif s'il était transposé chez nous qu'il ne l'est déjà outre-atlantique.


Le point le plus sensible des brevets qui a quand même une légitimité dans des cas de figure hors-logiciel est qu'il doit impérativement correspondre à une invention "non-triviale même pour les gens du métier". Et c'est sur que lorsque l'on en est à breveter la scrollbar, aller prouver à chaque fois que n'importe quel codeur en a eu l'idée dans son garage, c'est plus difficile.

" Face " à Microsoft, rien du tout. Je pense que le système va continuer à se développer exactement de la manière dont il le fait, asymptotiquement. Avec le temps, de plus en plus de gens en entendent parler, ce qui légitimise le système et augmente le nombre d'adeptes. Cela permet aux gens sérieux de travailler.

Les consommateurs eux-mêmes commencent à brandir l'argument Linux lorsqu'ils estiment qu'il y a du laxisme chez Redmond, surtout dans l'espoir que celui-ci réagisse avant d'être réellement contraints d'avoir à franchir le pas. C'est très bien comme ça. Un gros marché de masse qui tire le prix des machines vers le bas et un "contre-pouvoir". Linux permet même à Microsoft d'éviter les lois anti-trust dans une certaine mesure et il me semble bien que c'est ce à quoi le juge Jackson avait conclu.


Par contre, on risque vraiment très gros face aux lois stupides. Tout le monde sait désormais que la LCEN et la loi sur les DADVSI n'ont pas été promulguées pour le bien de nos concitoyens mais bien pour poser le premier maillon de la chaîne TCPA.

Il est déjà illégal de visionner un DVD acquis légalement sous Linux, même sur un lecteur officiellement estampillé " DVD " parce que les textes ne condamnent même plus l'effraction mais le fait en soi de casser une serrure (ce qui, transposé dans le monde réel, enverrait tous les serruriers en prison).

D'ici à ce qu'un texte impose à toute l'activité informatique l'usage d'une puce Fritz pour éviter les virus et combattre la guerre de l'information, et on ne pourra même plus acheter de microcontrôleur en France ...

En même temps, on peut généralement très bien faire les deux. Etre dyslexique, c'est une chose, la tragédie des Skyblogs en témoigne d'une autre.

Déclarer que " l'orthographe est la science du pauvre ", c'est se dédouaner un peu vite, je trouve.

Moi j'aimerais bien qu'on fasse aussi les « perles des enseignants ».

Y en a :

http://www.priceminister.com/offer/buy/1245319/Duhamel-Jerom(...)

Il y a problablement un timeout au niveau du kernel. Ca arrive par exemple avec le NFS ... il faut identifier où, mais par forum interposé c'est très difficile.

Est-ce qu'il y a de l'activité disque pendant ces moments d'attente ?

Des services devenus lents au démarrage, ça peut être le signe d'un timeout, mais dans ton cas de figure, on dirait que quelque chose part dans une boucle infinie.

En général, un processus fou consomme 100% du CPU, mais ne ralentit pas le reste car il se fait préempter facilement. Si tout le reste est lent, il y a probablement quelque chose qui travaille sur le disque.

Essaie de faire un top dans une console pour voir ce qui pourrait bien être aussi gourmand ...

Un bon coup de plussoir pour ce commentaire !

Pas tout-à-fait au point, mais presque, sous vi :

:%s/[^\\]*\(\\line\|\\par\)\?\|.*/\1/g

Oui, si tu considères que "à la fin on désalloue" signifie que cela se fera en dehors de ta fonction bien sûr !

void f2()
{
Objet obj (); /* <- NE PAS METTRE DE PARENTHESES ! */
obj.print();
}

En tout cas, pas par défaut. De la même façon que tu vas faire un int x, tu va faire un Object obj;. Type et nom de variable.

Le fait que tu puisse mettre des parenthèses te permet de choisir le constructeur qui doit être appelé, quand il y en a plusieurs.


Quand tu crées une variable en C, il reserve de la place dans la pile, en plus de ce qu'il y met déjà (sauvegarde des registres, adresse de retour et paramètres de la fonction). Eventuellement, il peut affecter une valeur par défaut à la place réservée.C'est d'ailleurs pour cette raison que C t'impose de déclarer toutes tes variables en début de bloc : spécialement parce que ce n'est PAS dynamique, mais déterminé au moment de la compilation (ce qui, en soi, est génial).

D'ailleurs, message perso aux afficionados de la qualité du code : il y a certains chefs de projets qui mettent un point d'honneur à vérifier que toutes les boucles et opérations conditionnelles (if while etc ...) soit bien encadrées dans des accolades. On leur répondra que 1) Si le langage permet certaines facilités, c'est pour des raisons précises 2) les accolades en C sont pratiquement toujours synonymes d'ouverture d'un nouveau cadre de pile et que la plupart des gens ne le savent plus 3) laissez les coders faire leur boulot :-)

La réservation de cette place ce fait d'ailleurs simplement en décalant le pointeur de pile de n octets. En C++, il faudra peut-être appeler une fonction plus sophistiquée pour mettre ton objet au propre : le constructeur. Celui-ci est donc appelé automatiquement en lui passant l'adresse de la mémoire fraîchement allouée.

Lorsque ta fonction se termine, en C, pour libérer la mémoire dans la pile, il suffit de faire remonter le pointeur de pile et de laisser tout le reste en l'état. En C++, il y a aura peut-être des ressources internes à libérer, donc les destructeurs seront appelés automatiquement aussi, mais fondamentalement, la mémoire allouée est la même qu'en C.


new et delete maintenant, c'est exactement la même chose que malloc et free en C. Ca sert à faire une allocation explicite d'un objet, et ne le libérer que lorsque le programmeur le décide explicitement. Et la, ça fonctionne aussi comme en C : une zone mémoire réservée, distincte de la pile, avec un tas, une table d'allocation, et une fragmentation mémoire.

- Pas de majuscule à String (ce n'est pas du Java).
- Pas de ".h" au bout des noms des fichiers d'entêtes dans le code en C++ (même si la recommandation précise que ça doit marche quand même) ...

Surtout qu'ici, "string.h", c'est toujours le fichier de déclaration des fonctions C.

Ensuite, le namespace que va bien, effectivement ...

A quand l'émulateur ?

En fait, les émulateurs Thomson existent depuis belle lurette :

http://membres.lycos.fr/jth/emuto8.html

Blue War doit même être disponible, tiens ...

J'ai essayé :-)

En réalité ce n'était pas vraiment un bug. En fait, le bâtiment ne tombait en panne systématiquement, mais facilement au deuxième ou troisième tir. C'était surtout une erreur de dosage ...

En réalité, je ne crois pas avoir un jour fini une campagne de Blue War. Trop long. Le temps passait plus lentement à cette époque.

Moi aussi, sur MO6 à l'époque !

Avec le sous-marin qui affichait une avarie chaque fois que l'on tirait une torpille ! :-)

Du coup, je ne sais pas si j'ai pu finir une mission, mais je me suis quand même bien amusé à explorer les sources, le jeu étant écrit en basic sur Thomson, à l'époque ...

Sondage : qui a joué à Blue War ou Silent Service dans les années 80 ?

Pas besoin. Il suffit qu'il vire ses crochets et ses quotes pour que tout rentre dans l'ordre, à première vue.

avec juste un mot de pass commun

99 fois sur cent, mot de passe commun est exactement synonyme d'erreur de conception. Un mot de passe est propre à un compte.

Si tu as l'intention de distribuer ton mot de passe à une liste de personnes de confiance, c'est à toi d'intégrer la liste des comptes desdites personnes dans ta configuration. Dès lors, le fait d'être identifié leur suffira à accéder à ton partage.

Ou encore :

- Créer une disquette de démarrage
- S'en servir pour lancer un CD.

Franchement, c'est quand même beaucoup plus confortable.

su, ça veut dire substitute user. C'est fait pour changer d'identité. On s'en sert pour lancer un programme (par défaut, un shell) sous une identité donnée (par défaut, root). L'option -c permet d'exécuter une commande spécifiée plutôt que le shell. Autant que je sache, su ne fait même pas partie du standard Unix de l'Open Group, mais il est conçu comme il faut, et extrêmement pratique.

sudo, c'est un bricolage qui étend ce principe. Il pallie certains manques et est de fait très utilisé. Mais comme il est en général très mal configuré, il est généralement très facile à contourner. En gros, tout le monde s'en sert pour redéfinir le rôle "administrateur" des utilisateurs Windows. Au feu.

Le principal intérêt est de te faire utiliser ton propre mot de passe, voire même un mot de passe dédié, pour te faire accéder à des commandes bien définies sous une identité bien définie elle-aussi, et de garder une trace des commandes effectuées. Ca sert aussi à respecter le principe de confidentialité des mots de passe (à considérer comme des codes de carte bleue)/

C'est bien là tout le problème, d'ailleurs : ouvrir une session de cinq minutes où l'on peut saisir des commandes sans mot de passe et depuis son propre compte, c'est déjà dégueu, mais c'est toujours mieux que de laisser une console root ouverte sans délai d'expiration ni trace des opérations effectuées.

La meilleure chose, donc, consiste encore à ne pas avoir à utiliser root à tout bout de champ, donc à configurer son système proprement une fois pour toute. Et, là encore, il ne s'agit pas de le faire en supprimant les barrières ! Il faut s'arranger pour repérer toutes les opérations réversibles, et les rendre leur exécution possibles aux utilisateurs ordinaires membres des groupes idoines.

Surtout, si ce n'est pas clair, dis-le tout de suite.

S'il faut développer un peu plus, je veux bien le faire ici, car cela servira à tout le monde, et formera une trace écrite, qui plus est référencée par Google :-)

En fait c'est la fleme de taper mon passe a chaque fois que je veux utiliser synaptec pour installer un ptit logiciel ou ouvrir mon serveur gproftpd alors que je suis le seul utilisateur de mon PC.

Les meilleurs pratiques consistent à identifier le problème avant d'essayer de trouver une solution pour le contourner. Les garde-fous ne sont pas là pour embêter l'utilisateur exprès.

Pour synaptic, tu ne devrais pas avoir à l'employer à tour de bras systématiquement. Si toutefois c'est le cas, utilise plutôt sudo apt-get install pour récupérer un truc identifié et ponctuel. Au moins, si tu rappelle la commande par accident, ou si un utilisateur le fait quand tu as le dos tourné, tu ne risqueras pas d'installer quelque chose d'imprévu.

Pour proFTPd, on peut lire sur Wikipédia :

Ses supporters disent que ProFTPd est bien documenté et que la pluspart des configurations seront proches de celles des exemples fournis avec le logiciel. Son unique fichier de configuration, proftpd.conf, utilise une syntaxe similaire à celle d'Apache permettant ainsi d'homogénéiser les fichiers de configuration.

Ce qui signifie que :
- Tu aurais largement plus vite fait d'éditer directement le fichier de conf plutôt que de passer par l'interface graphique à chaque fois.
- Cette interface (gproftpd) se contente, en coulisses, d'éditer ce fichier et éventuellement d'envoyer un signal à proftpd pour lui demander de le relire.

Donc, si tu fais ls -l /etc/proftp.conf tu verras que le fichier appartient, comme tous les autres, à un groupe. Il te suffit de te placer dans ce groupe pour que tu puisses, toi et personne d'autre à priori, éditer ce fichier directement sans jamais avoir à changer d'identité !

Mieux que ça, comme tu peux naturellement éditer le fichier, gproftpd le pourra aussi et il n'a donc plus besoin non plus d'être lancé par le super-utilisateur. Au lieu de ça, on parlait de lancer automatiquement, en root et sans mot de passe une application s'appuyant sur une infrastructure GNOME et ouvrant une connexion vers X-Window. Il suffit que n'importe quelle autre appli ouvre une connexion vers le serveur pour pouvoir taper "à ta place".

En poussant le raisonnement au maximum, même proftpd n'a pas besoin d'être root. Il peut fonctionner sous sa propre identité dans un environnement chrooté. Comme çà, même en cas de faille de sécurité, un utilisateur extérieur ne pourra jamais aller plus loin que ce que le système permet. La seule raison de démarrer le daemon FTP en root est pour lui permettre de réclamer le port 21 et çà, il suffit de demander à xinetd de le faire pour lui.

Bref, dans un serveur UNIX proprement administré, au bout d'un moment, on ne devrait plus avoir à passer root plus d'une fois par mois. Alors en arriver à vouloir virer le mot de passe ...

Enfin - et le ne le fais pas non plus si ce n'est pas nécessaire -, si tu a vraiment besoin de lancer fréquement des commandes en root, tu peux en préciser la liste dans /etc/sudoers et affecter NOPASSWD uniquement sur celles-ci.

C'est vraiment dommage parce qu'il suffit de savoir mettre des droits sur un fichier pour commencer à gérer la sécurité efficacement sous UNIX, c'est presque trivial. Evidemment, sous Windows, ce n'est même pas la peine d'y penser, et tous les utilisateurs exportent - bien plus que des mauvaises habitudes - des schémas de pensée entiers et calamiteux.

Ne fais pas çà. C'est suicidaire si tu es relié directement à Internet, et ce n'est de toute façon pas une habitude à prendre.

Si tu as besoin d'effectuer des commandes super-utilisateur à l'occassion, utilise sudo, c'est à çà que ça sert. Cette commande t'ouvre une session qui expire après cinq minutes d'inactivité. Donc, tu tapes ton propre mot de passe (et pas celui du superchef) une seule fois, et tu fais tout ton boulot sans être emmerdé.

Si vraiment c'est trop compliqué, tu peux ajouter la directive NOPASSWD dans /etc/sudoers pour que les irresponsables utilisateurs de confiance puissent directement lancer leurs commandes. La sécurité reste proche de zéro, mais au moins on limite les probabilités d'exécution de commandes en root par accident.

Pour le reste, voir ici :

http://linuxfr.org/comments/801182.html#801182

Félicitations : Tu viens d'inventer le rootkit corse ! :-)

Spindizzy ?

Déconseillé aux étudiants et aux salariés en entreprise ...