patrick_g a écrit 6387 commentaires

J'espère qu'il a modifié les options du BIOS pour toujours démarrer sur le disque dur et qu'il a ensuite verrouillé le BIOS avec un mot de passe. C'est le minimum dans ce cas.
Bon il suffit que le gamin s'achète un disque dur à lui et qu'il fasse l'échange chaque fois qu'il veut utiliser l'ordi…mais c'est déjà plus chaud.

En ce qui concerne les cgroups, remplace Linux par google.

Google utilise intensivement les cgroups mais ce ne sont pas les devs payés par Googe qui pilotent le développement. Le fichier MAINTAINERS liste Tejun Heo (qui bosse pour Novell) et Li Zefan (qui bosse pour Huawei) comme mainteneurs officiels.

En attendant qu'elle le soit, j'ai mieux à faire de mon temps que de coder une interface vouée à être fortement remaniée.

Soit. C'est une réponse parfaitement sensée…mais cela signifie également que tu ne peux pas intervenir lors de la phase de construction pour orienter le développement. C'est un choix.

À quand une spécification définitive des cgroups ?

Salut Miod.
AMHA si tu explores de nouvelles possibilités et que tu tentes d'aller au delà de POSIX, alors une certaine période d'expérimentation est inévitable avant que les choses ne se stabilisent. C'est ce que font les devs Linux.

Je trouve ce paragraphe de Jon Corbet (issu de cet article) particulièrement intéressant :

In the early years of Linux, most of the ABIs implemented by the kernel were specified by groups like POSIX or by prior implementation in other kernels. That made the ABI design problem mostly go away; it was just a matter of doing what had already been done before. For current problems, though, there are rather fewer places to look for guidance, so we are having to figure out the best designs as we go. Mistakes are certain to happen in such a setting. So we are going to have to get better at learning from those mistakes, coming up with better designs, and moving to them without causing misery for our users. The control group transition is likely to set a lot of precedents regarding how these changes should (or should not) be handled in the future.

Donc ta question est pertinente. Les cgroups ne sont pas encore spécifiés avec la perfection formelle d'une norme. Mais ta question reflète aussi le fait que Linux est le pionnier et que les BSDs sont, au moins sur ce sujet, les suiveurs. Pourquoi attendre que le travail soit terminé côté Linux pour ensuite décider d'adopter, ou pas, cette nouvelle techno ? Je trouve assez paradoxal de reprocher aux cgroups de ne pas avoir de specs définitives pour l'instant et en même temps de ne pas chercher à aller au delà de POSIX. Si tout le monde participe, discute, expérimente et implémente on arrivera à un truc stable bien plus rapidement.

Le jour ou tu craques et que tu sautes le pas, met la facture sur le nom de tes parents, ça t'évitera d'avoir à payer la redevance.

C'est avec ce genre de raisonnement anti-social que la Grèce s'est effondrée. Fraude généralisée, tout les citoyens optant pour le choix de faire défection (au sens de la théorie des jeux) et en sortie la catastrophe. Si tu ne veux pas payer de redevance alors tu n’achètes pas de télévision, c'est tout.

Il faut voter pour cette entrée dans le suivi => https://linuxfr.org/suivi/resultat-de-recherche-incomplet

Apple contribue à LLVM alors que rien ne l'y oblige dans la licence

Apple fait ça parce que LLVM n'est pas son coeur de métier. En revanche pour tout ce qui touche à l'interface graphique c'est complètement fermé et propriétaire.
Et c'est pareil pour les autres entreprises en général: il peut éventuellement y avoir des contributions sous BSD quand le logiciel n'est pas stratégique, mais pour tout ce qui concerne le business on reste en code fermé.
C'est là que l'avantage de la GPL apparaît clairement (même si ce n'est pas la panacée). Les firmes comme Samsung ou Broadcom ou Texas Instruments voudraient bien tout garder pour elles…mais en fait elles doivent contribuer leur code parce que le noyau est sous GPL. Et c'est comme ça qu'on se retrouve, pour le futur noyau 3.11, avec 485 patchs de Samsung, 319 patchs de Texas Instruments et 122 patchs de Broadcom.
Merci la GPL !

Mais prendre pour exemple un OS qui a plus de 10 ans d'âge, je trouve cela assez déplacé…

Faut pas exagérer ! Bcrypt est sorti en 1999 (bien avant Win XP donc). Si Microsoft avait utilisé ça ils n'auraient pas eu le moindre problème. Mais non il a fallu qu'ils inventent un schéma pourri bien à eux.

N’empêche ça me fait bien marrer, j’utilise les nightly de CyanogenMod depuis presque un an et j’ai jamais eu ce genre de bugs.

D'après les infos glanées à droite et à gauche sur le net, le bug viendrait en partie d'un problème matériel sur le Nexus 4 donc ce ne serait pas vraiment la faute d'Android. D'ailleurs je ne sais pas comment cela a été corrigé dans la 4.3. Je constate juste que je n'ai plus le problème.
Et pour le reste ce Nexus est un vrai bonheur à utiliser.

10 numéros en comptant le zéro, une touche d'appel et une touche de clôture

Et tu retiens tous les numéros de tes correspondants juste avec ta mémoire organique ? Moi je préfère avoir un auxiliaire en silicium qui s'occupe de ça…

J'ai un Nexus 4 et j'ai eu le bug de l'extinction intempestive. C'était vraiment chiant de découvrir en fin de journée que son téléphone s'était éteint tout seul et qu'on avait peut-être loupé des appels.
Depuis le passage en version 4.3 plus aucun souci.

Ah, c'est sûr que le troll à l'arrache, ça reste le meilleur moyen de faire venir du monde sur un blog

Et encore tu n'as pas lu le sommet trolissime qu'est son article sur Torvalds. Là on est dans le troll vraiment bien gras et poilu ;-)

si vous l'aimez, prenez-le, si vous ne l'aimez pas, laissez-le, et puis voilà tout…

Cela n'a rien à voir avec l'utilisation ou pas de ton logiciel. C'est le fait que tu as posté un journal sur LinuxFR pour présenter ton travail. Il est normal (c'est le principe même des journaux) que nous fassions des commentaires sur Manux, que ce soit le côté technique ou bien le juridique.
Tu t'attendais à quoi ? Les lecteurs ont un esprit critique et ils l'exercent, c'est sain non ?

D'ailleurs, un exploit noyau aussi, ça suffirait à passer. Mais elle sera renforcée, et très significativement; et pour la plupart des applications, elle sera complète hors bogue noyau.

Comme pour une distro Linux classique qui utilise SELinux (ou Apparmor) et Seccomp mode 2. Donc quel avantage significatif apporte ton OS sur le plan de la sécurité par rapport à ça ?

Et puis il y a aussi le fait que chroot n'est pas fait pour la sécurité. Cela a été dit et répété des centaines de fois.
Citation d'Alan Cox : chroot is not and never has been a security tool.
On trouve pleins d'articles sur le net pour mettre en garde les gens (un exemple au hasard).

La solution pour sécuriser les applications c'est un module MAC (SELinux ou Apparmor ou autres).

seul mon format de paquetage comporte les fonctionnalités requises pour faire usage des protections contre les exploits jour zéro

Tu peux détailler s'il te plaît ? Parce que même en lisant ta documentation je n'ai pas compris en quoi ton projet permet de se protéger contre les exploits. C'est le fait de tout mettre dans des chroots ?

des recherches en cours pour travailler sur des données chiffrées (recherche de texte etc) sans avoir besoin de déchiffrer tout le flux auparavant.

C'est la notion de chiffrement homomorphique je crois.
Cela semble encore assez loin d'une utilisation pratique.

Je l'avais même écrit noir sur blanc dans mon post : "sera en lecture libre demain matin"

Allez, un lien souscripteur spécial => http://lwn.net/SubscriberLink/562314/b4a561c9f91bac12/

Mais je ne peux que t'inviter à t'abonner à LWN à la première occasion ! 3.50 $ par mois pour le niveau "starving hacker" c'est rien du tout et cela permet de soutenir une publication sur le libre de grande qualité. N'oublions pas que h-open en anglais vient de mourir…

La vulnérabilité en question a été patchée dans Firefox ESR 17.0.7.
Et de toute façon l'exploitation via javascript qui a été observée était conçue pour infecter les systèmes Windows.
Plus de détails sur cet article LWN (qui sera en lecture libre demain matin) => https://lwn.net/Articles/562314/

Je sais je suis chiant

Non tu as raison…mais le principe même du camouflage Windows XP implique de réutiliser cette image. Chacun fait ses choix.
Après au plan philosophique on peut discuter la valeur d'un copyright accordé sur une photo de nature sans acte créatif particulier. Mais bon c'est un autre débat.

Quelques alternatives sont évoquées ici : https://tails.boum.org/blueprint/replace_truecrypt/

Dans le changelog de cette version 0.20 on trouve ceci :

Add a wrapper around TrueCrypt which displays a warning about it soon being deprecated in Tails.

Accomplir des missions en autonomie, c'est (pour l'Armée Française) intervenir "from scratch" pour établir un réseaux de communications pour les secours & les autorités, réparer les infrastructures vitales

Heu y'a pas que le génie dans l'armée hein ?
La mission de l'armée française cela peut être également de combattre !

C'est quoi que tu modifie ?

Quand on a un SSD c'est pas mal de mettre les options qui vont bien pour utiliser préférentiellement la RAM au lieu du disque.

Je ne suis pas inquiété, je n'ai rien chez les entreprises concernées

Et c'est la même chose pour l'ensemble de tes interlocuteurs ? Non ? Ah ben alors tu es dans le même bateau que tout le monde.