Anonyme a écrit 62265 commentaires

(il y a une appli pour ça)

Les smartphones font de moins en moins de chose et il faut même une application pour afficher l'horloge, c'est dingue pour des trucs avec 16Gio de RAM et 4 cœurs CPU.

c'est ce que je dis plus haut …

l'utilisation possible nécessiterait une première installation avec les google apps pour récupérer les identifiants, puis une réinstallation de cynaogenmod (ou tout autre système de base de votre choix) sans les google apps et utilisation de ce soft pour installer des applications.

Meme si google peut toujours savoir ce que tu utilises comme applications, on améliore la situation initiale en empêchant la modification du système par les google apps.

Ca me semble une évolution positive sur laquelle pourraient se greffer d'autres améliorations.

en cherchant un petit peu, il semble que ce soit fait exprès: le compte semble avoir été créé pour l'occasion

http://tuxicoman.jesuislibre.net/2013/07/real-apk-leecher-telecharger-les-apk-du-google-play.html

peut être parce que c'est un 0.1 et qu'il attend d'avoir des retours pour aller plus loin

il faut lire les petites lignes:

modifier les identifiants Google actuellement hardcodés

sur ton blog tu réponds à ma question 1: il faut les identifiants générés lors de l'installation des google apps !
du coup, à moins d'avoir loupé un truc, ça semble perdre un peu de son intérêt…

1/ A quoi correspondent les identifiants utilisés ? ce sont les mêmes que ceux utilisés par le système de google ?
si c'est le cas en quoi cela empêche google de savoir ce que tu utilises comme outils (sauf à tout faire un miroir local et choisir ensuite)

2/ y a t il une possibilité d'installer et d'utiliser cela sur l'appareil android directement ?

Je n'utilise pas d'appareil android, mais ca va me motiver pour installer cyanogenmod sur ceux de mes proches: jusque là, j'étais freiné par l'installation obligatoire des google apps pour avoir acces au magasin de google

Intel HD3000, tout type de vidéo. Et downgrader ne servirait à rien, j'ai bien précisé qu'il y a un an j'avais le même problème avec Arch… donc je remonte trois ans en arrière ?

Je n'ai pas dû me faire comprendre : le problème est de réutiliser un volume chiffré existant et dont je veux conserver les données présentes. D'où mon intro, sur le partitionnement du disque :)

Un cas particulier ? C'est quand même pas si particulier que ça, c'est soit pas de chiffrement, soit LUKS/LVM ou LVM/LUKS.

Et de toute façon ça n'aurait pas changé grand chose, il aurait fallu savoir comment configurer crypttab, et là comme ça, sans savoir que Debian nomme le volume luks « cryptroot » par défaut, le problème est le même.

Ca serait bien d'arreter de parler de "pro-Lennart" pour les gens qui defendent systemd. On peut parler de "pro-systemd" eventuellement, mais je ne vois pas ce que Lennart vient faire dans cette discussion.

Mais personellement je n'aime pas la magie noire, j'aime savoir ce que fait le système.

Aucune magie noire dans systemd, tout est parfaitement documenté. Bien plus en tout cas que l'init classique et beaucoup d'autres projets.

Ça n'a rien donné.

Ni moi ni mon collègue n'avons trouvé. Si j'avais pu le faire, ce journal n'aurait pas existé.

Après avoir man crypttab on se rend compte qu'il faut utiliser en target (le premier champ du fichier) le nom sous lequel est ouvert notre volume LUKS dans /dev/mapper/

Le message donne ce nom s'il ne le trouve pas dans la liste :

cryptsetup: WARNING: invalid line in /etc/crypttab for cryptroot -

cryptroot est ici notre cible. Donc on oublie le fichier moisi dans /etc/initramfs-tools et on utilise crypttab :

crypttab /dev/sda3 none luks

Par ailleurs, n'est-il pas possible de passer en paramètre au démarrage les disques à ouvrir et la racine lvm ?

Et c'est quoi la procédure pour ouvrir de façon non manuelle son disque chiffré sans devoir le formater ?

Ça serait assez extraordinaire que le matériel plante avec une Arch et pas une Fedora ou une Debian. Mais je vais le faire quand même… on sait jamais.

Bon ben même avec le noyau « minimal » et cette conf, ça vient de planter.

C'est super il ne s'est rien passé de la journée et là paf… -_-

Ça c'est en retirant le code Java, ils ont omis toutes les briques de protection contre les failles 0day et du coup le firewall, c'est évident…

Il se trouve que j'ai étudié l'appel-système jail_set(2) de FreeBSD. En ce qui me concerne, j'ai renoncé à l'implémenter ou à m'en inspirer, pour diverses raisons, mais j'ai bien dû reconnaître qu'il était supérieur au chroot(2) de Linux.

chroot n'a rien de specifique a Linux, on le trouve aussi sur la plupars des Unix, dont FreeBSD.

Si on veut comparer les jails de FreeBSD a quelquechose sur Linux, ca serait plutot aux Containers qu'il faudrait comparer.

Boh, c'était surtout histoire de la ramener sur un journal où… ben ya pas grand chose à dire :)

« FreeBSD » n'est pas responsable des ports dans le sens où si il y a un problème de sécurité dans les ports, c'est ton problème si tu ne mets pas à jour.

Les paquets pkgng de PC-BSD sont à jour, j'ai même eu une installation fonctionnelle du système entier + zfs + kde4 en moins de 20 minutes.

Donc tu la boucle et tu retourne tranquillement mouler sur Ubuntu.

Ouais t'as raison. On balance tout.

Tiens je n'avais pas remarqué ça. Je viens de build un noyau minimal et ça fait bien une heure qu'il tourne sans problème. Et c'est un kernel préemptif « classique ».

J'ai bien envie de modifier la conf du noyau d'Arch et recompiler mais ça va encore prendre une plombe et faire bouillir les océans donc… un peu plus tard.

Bon en attendant jvais voir quel type de noyau utilise Fedora.

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 ;-)

Excellent ! En particulier le paragraphe "Linus Benedict Torvalds un fardeau pour GNU" qui est un veritable chef d'oeuvre !