Psychofox a écrit 9997 commentaires

ahahaha

ouais très stable. La dernière fois que j'ai voulu en installer une, le kernel paniquait à dès le démarrage du dvd d'install. Les autres distrib testées dessus (OpenSuse, Ubuntu, Slackware) bootaient correctement...

c'est une mode qui a été poussée par les casinos en lignes. La mode a un peu contaminé tous les pays, donc Patrick Bruel n'y est pour rien (il surfe juste sur la vague)...

En tout cas je trouve drôle toutes ces personnes qui s'y mettent maintenant, victimes aussi facilement d'un grand coup de marketing mondial. ça fait beaucoup de moutons dans la bergerie...

il n'y a jamais eu à payer pour utiliser OpenBSD. L'achat de cd ou de t-shirts est facultatif, c'est au choix du merchandising ou un don.

c'est oublié.

Cela dit sur un de tes points, j'avoue que je n'ai jamais possédé de voitures avec abs. Donc j'ai toujours su freiner sans et j'ai à plusieurs reprises du faire des freinages d'urgence avec manoeuvre d'évitement sans encombre. Mais bon je suis un peu spécial, je suis une des seules personnes à sortir la voiture pour le plaisir quand la route est enneigée alors que je prends habituellement les transports en commun (je dois avoir des gênes scandinaves)...aaaah les appels contre appels. ^_ ^

Combien de personne "conduisant une monoplace" sait faire correctement un freinage d'urgence sans faire patiner les roues, sans abs ?

J'espère que toute personne "conduisant une monoplace" sait le faire !

On apprend bien à l'autoécole à faire des freinages d'urgence (mon moniteur m'avait même fait faire des freinages d'urgences sur sol gras et sur gravillons).

Et niveau spectateur vs sécu, je choisis la sécu, bizarrement.

ce n'est pas parce qu'une voiture glisse plus facilement que c'est plus dangereux. Plus tu perds du grip rapidement, plus cette perte de grip est contrôlable contrairement à un décrochage violent sur une voiture à fort appui aéro.

50L aux 100 ça me parait léger pour une F1. Une AC Cobra préparée course consomme déja 1L au km. Une F1, même plus moderne avec son aéro d'armoire normande et le double de puissance doit consommer bien plus.

les bio carburants ne sont pas écologiques...

1. ils polluent comme (parfois plus) le carburant traditionnel
2. pour en avoir beaucoup, il faut convertir beaucoup de cultures alimentaires ou abattre des forêts, et utiliser des engrais.

sauf que la FIA se débrouille pour étouffer toute initiative qui jette un peu d'ombre à la F1 (un peu à la manière MS).

C'est comme ça que le DTM s'était cassé la gueule au milieu des années 90, que le magnifique championnat BPR s'était éteint dans la soporiphique FIA GT, que les sports prototypes ont périclités (y'a plein d'autres exemples).

Je n'ai pas dit que c'est simple, mais ce n'est pas plus difficile que de conduire une monoplace certe moins puissantes mais avec moins d'aides électronique. Hors c'est une abérration si on part du principe que le championnat pilotes est mis autant en avant.

Il n'y a que le physique qui est plus sollicité.

Et puis du point de vue des spectateurs, des voitures qui adhèrent moins serait un plus, il suffit de voir la différence entre une course soporiphique sur le sec et une course sur le mouillé.

s'ils avaient vraiment compris quelque chose, le règlement imposerait aux F1 de n'embarquer que le carburant nécessaire pour faire la course avec une conso moyenne de 10L aux 100 (voir moins), sans remplissage supplémentaire à l'arrêt au stands.

La on verrait un peu les ingénieurs se tirer les trous de nez pour faire une voiture rapide et peu consommatrice. Et ça ajouterait du spectacle puisque pour gagner en consommation, on ne pourrait plus jouer la carte de l'appui aéro maximum (les F1 sont de vrais aérofreins aérodynamiquement) et on devrait diminuer probablement la largeur des roues. La au moins les pilotes auraient besoin d'un peu d'adresse pour prendre les courbes avec leurs roues de vélos et un appui réduit.

je dirai surtout que le moins compatible, c'est Mac OS X puisqu'il est incapable de tourner sur tous les pc que j'ai eu ;-)

Non puisqu'il existe des drivers nvidia pour Solaris Express. Freebsd étant aussi à exclure avec ses pilotes nvidia, il te reste plan9, netbsd, openbsd, haiku, hurd, syllable et quelques autres...

Enfin bon, tout ça pour relever ce que je trouve être une faille de sécurité qd même, alors qu'on dit MacOSX assez sécurisé.

qui le dit ? j'ai toujours entendu le contraire.

Il a aussi produit et distribué le dernier album de Saul Williams via le net (gratuit en qualité correct je crois et payant pour les flac)

Payant, mais précisons le, vraiment pas cher puisqu'il ne fallait débourser que 5€ pour avoir l'album entier en flac.

systemrescuecd est grand public, puisque librement téléchargeable, utilisable et documenté.

Par contre si tu veux quelque chose d'utilisable par n'importe qui, sans connaissance préalable, c'est idiot. A partir du moment ou tu as je cite de gros problèmes et que tu dois effectuer une restauration, c'est que tu veux faire des choses d'assez bas niveau. Donc y aller les yeux bandés, sans connaissances, c'est idiot, quelque soit la facilité d'utilisation du produit.

Pour les gens qui n'y connaissent rien. Une simple réinstallation de l'OS assortie de l'outil de backup qu'ils préfèrent suffit.

Quand a demander aux gens de fermer et reouvrir la session, si c'etait si simple... Faut penser aux cas ou plusieurs personnes sont loguees sur une machine: plusieurs explorer qui tournent, etc...

Mais la problématique est la même si tu dois rebooter. De toute façon lorsqu'on est admin sur un terminal server, on ne balance pas une mise à jour IE quand les gens travaillent (enfin j'espère) donc le cas des multisession est un cas à part.

Enfin je ne sais pas, mais en tout cas, MS se donne une mauvaise image avec les reboots à répétition à la moindre install/maj de logiciel alors que ça pourrait être évité...

Explorer(le shell) charge certaines librairies d'IE pour afficher des trucs genre l'aide, etc...

Resultat, tu ne peux pas updater ces librairies sans stopper le shell, mais ces elements n'ont absolument rien d'essentiel dans l'OS.

IE en tant que browser web n'a rien de plus critique que la KPart dans KDE qui fait l'affichage HTML.

Dans ce cas la, question bête, pourquoi le système ne restart pas le shell lors de l'install IE. A la limite, si on a peur de fermer des applis ouverte par l'utilisateur, on peut juste lui demander de fermer et réouvrir sa session. Enfin bref, sans avoir à rebooter complètement.

> Cependant, si le home est crypté (je compte le faire d'ici peu), le garder dans un autre endroit que l'eee devient inutile. Le voleur ne pourra pas lire son contenu.

complètement faux.

Hackers read encrypted hard drives
Written by W. Curtis Preston (http://www.backupcentral.com)
Sunday, 24 February 2008

If you're encrypting the data on your hard drive using OS-level software encryption (e.g. Windows EFS, Vista BitBlocker, MacOS FileVault, Linux DM-Crypt, or TrueCrypt ), then a research study at Princeton University, partially funded by the Department of Homeland Security, has figured out how to read that data without your password. Well, that's just great.

Let me see if I can summarize the essential elements of the story:

* In order for OS-level encryption to work, the unencrypted keys must be held in RAM
* This includes when your system is powered on after a suspend or hibernation sequence. As soon as you see the Windows/Mac/Linux login prompt, the unencrypted key is now in RAM.
* Data stays in RAM after it's powered off, from seconds to minutes
* Here's the exploit:
1. Black hat steals laptop & powers it on
2. Laptop comes up to login prompt
3. Black hat plugs in USB device with special hack/boot software
4. Optionally the black hat sprays an upside-down can of compressed air on your RAM chip to freeze it. This causes the RAM chip's residual image to last much longer after power off, as in 10 minutes or longer.
5. Black hat unplugs system (with battery out), then immediately plugs it back in
6. This time the special boot/hack software copies the residual image in RAM to a file on the USB stick/drive
7. Now they've got all day to scour the RAM image to find the unencrypted key. Of course they don't need that long.
8. Once the find the key, they can use it to access all the encrypted data on the drive -- even without your password

And there you have it. With a little bit of know-how (which they don't divulge any more than I have), and a can of compressed air if you want to take your time (good thing those are hard to find), you can render OS-level encryption completely worthless. They've demonstrated the exploit against Windows EFS, Vista BitBlocker, MacOS FileVault, Linux DM-Crypt, and TrueCrypt -- and they broke every one of them. They believe that pretty much all versions of OS-level encryption will be vulnerable to this attack.

What are you to do? It sucks that you have to do this, but the answer is simple. If you are using OS-level encryption, the following two steps would work.

* Don't suspend, hibernate, or leave your system powered on when you leave it
* When you do power it off, wait a few minutes for the residual image in RAM to fade before you leave it unattended

They did mention in the report that some systems require you to enter a hard-drive level password before it will read the OS image and wake up from being suspend, and that systems so configured were also not vulnerable to this attack. But if when your system wakes up from hibernation/suspension, it comes right to a Windows/MacOS/Linux login screen, you are SOL.

Read the whole study here. Watch their YouTube video of a sample attack here. There's something about watching how easily they do it that's just downright eerie. If you're curious what a frozen RAM chip looks like, here you go.

le lien vers l'étude en question :
http://citp.princeton.edu/memory/

Moi je préfererais surtout voir le log de progression. Savoir exactement ou j'en suis et pas qu'on use d'un artifice pour me faire patienter et me faire croire que ça avance vite.

Les propositions de Chris Harrison ne visent qu'à tromper l'utilisateur pour lui faire croire que ce qui est long est plus court qu'il n'y parait. J'appelle ça faire l'autruche. Dans ce cas la pendant qu'on y est, pourquoi pas envoyer des popups pour nous dire que tout va bien on est en sécurité quand une faille non patchée est découverte. C'est vrai quoi faudrait surtout pas stresser l'utilisateur avec la peur d'être hacké.

Bref ---> /dev/null

(les progress bar, ça sert à rien en plus)

non.

Ubuntu utilise/gère ses propres dépôts et pas ceux de Debian. Mint dépend directement de ubuntu, pour les mises à jours de sécu par exemple.

la mint est une ubuntu (avec quelques outils en plus et une config de base différente) qui utilise les dépôts ubuntu.

Par exemple là je tente l'installation de latex ..... c'est pas gagné. Le script d'install de texlive me rend la main sans rien me dire :(

Je serai tenté de dire que le problème ne vient pas d'aix, mais de texlive dont les scripts ne sont pas testés ou ne comportent pas les vérifications nécessaires (shell, path, version des applis utilisés, etc...).

Pour ça y'a plein de projets libres qui ne sont testés que sous linux et qui sont des plaies à installer sur d'autres environnements comme (open)solaris par exemple. Tout ça parce que les devs font des scripts d'install qui utilisent des options n'existant que dans les versions gnu de certains outils.

d'une manière ou d'une autre tu as copié l'iso sur la machine AIX, donc de la même manières tu aurais pu copier son contenu. Après le nfs n'était qu'un exemple. Tu peux faire du tar/detar over ssh ou autre si ça te chantes :)

...enfin le montage d'un fichier .iso, c'est pas non plus le truc que tu fais tous les jours hein :)

T'aurais très bien pu copier le contenu de ta station au serveur, faire un montage nfs sur ta machine ou autre...

Franchement c'est mega low priority comme fonctionnalité.

ouais enfin on peut connaitre D&D comme moi et ne pas avoir retenu le nom de son auteur. Faudrait pas non plus tomber dans l'adulation quasi religieuse. D&D n'est qu'un jeu.