/* Topic des codeurs [6] */

Pylades · Le 15/01/2012, à 22:09

Ah, OK. C’est un peu une interface SSH à travers des menus, donc ?
J’espère que tu sais que tu peux perdre la connexion sans raison apparente, en SSH ; donc que ça peut se fermer sans que tu ne cliques sur le bouton de verrouillage…

tshirtman · Le 16/01/2012, à 16:46

http://kivy.org/#contest

il reste une quinzaine de jours, et seulement quelques participants pour l'instant… (moi je peux pas…)

http://kivy.org/docs/tutorials/pong.html
(un tuto pong honteux, la balle est même pas carrée, tout se perds…)

Dernière modification par tshirtman (Le 16/01/2012, à 17:57)

Elzen · Le 16/01/2012, à 21:37

Πυλάδης a écrit :

Ah, OK. C’est un peu une interface SSH à travers des menus, donc ?

Bah pas forcément SSH, mais yep. Le cas ne se rencontre pas forcément souvent sur une machine perso, mais sur une machine partagée, ça peut être sympa de pouvoir ouvrir des trucs en tant qu'un autre utilisateur local.
Du genre, si chaque utilisateur de la machine a son compte mail avec son client mail perso configuré sur son compte à lui, tu peux te servir d'un truc dans ce genre-là pour aller consulter tes mails sans avoir à te reloguer.

En fait, ça peut même servir aussi à communiquer avec un logiciel arbitraire plutôt que de faire exécuter les commandes par le shell système normal. C'est ça qui est cool : t'as juste à indiquer la commande de « déverrouillage » que tu veux, et le truc tente de se débrouiller avec.

Πυλάδης a écrit :

J’espère que tu sais que tu peux perdre la connexion sans raison apparente, en SSH ; donc que ça peut se fermer sans que tu ne cliques sur le bouton de verrouillage…

Une connexion qui se paume toute seule ?
Jamais vu. Quand j'ai des soucis de réseau, en général, c'est plutôt l'inverse (le truc qui reste ouvert, mais bloqué, genre j'suis obligé de le killer pour réussir à le fermer).

Ceci dit, c'est pris en compte : le menu se referme automatiquement si le shell distant se ferme. D'ailleurs, si jamais t'as l'idée saugrenue d'utiliser deux menus différents qui pointent vers la même commande, déverrouiller l'un déverrouille l'autre aussi.

tshirtman a écrit :

paramiko sera peut être utile…

J'ai jeté un coup d'œil (très) rapide, mais ça a l'air spécifique à SSH. Comme je l'ai dit, j'ai voulu faire un truc relativement générique, qui soit capable de lancer d'autres trucs aussi.

D'ailleurs, en fait, j'me demande si verrouiller le terminal est vraiment utile. Ça pourrait avoir un semblant d'intérêt pour des raisons de sécurité si c'était l'utilisateur cible qui fournissait le fichier de config du menu (donc si le truc était bien fait, propre et tout, avec une vraie connexion inter-comptes), mais comme là, c'est l'utilisateur qui lance le truc qui choisit les commandes qu'il veut et que de toute façon, s'il peut ouvrir le menu, il peut ouvrir un shell pour taper ce qu'il veut, autant que je lui laisse la possibilité de taper directement…

Et puis il faut que je bosse un peu plus sérieusement un découpeur d'arguments shells, aussi, pour le moment j'ai juste un truc qui split sur les espaces, ça n'sert pas à grand chose. Il faudrait un truc qui interprète les guillemets, les $variables, les $(commandes) et les $((expressions de calcul))…

tshirtman a écrit :

http://kivy.org/#contest

Çquoi exactement ?

J'n'ai pas du tout le temps dans l'immédiat (début de phase de codage du projet annuel, il reste plein de docs à rédiger et j'm'occupe aussi de la partie admin serveurs), mais peut-être quand on sera un peu mieux lancés…

tshirtman · Le 17/01/2012, à 00:12

C'est un framework multiplateform (windows/mac/linux/android/iOS) en python permettant de faire des applies de toutes sortes, mais surtout orienté multitouch, le tout utilisant openGL pour un affichage efficace partout, sans embéter avec la complexité d'icelui… ça définit aussi un langage de templates pour les UI qui permet de prototyper et définir rapidement le look-n'-feel de son applie.

et puis c'est beau, et c'est en LGPL…

la le concours c'est pour faire des jeux libres avec ça

Elzen · Le 18/01/2012, à 21:29

J'y jetterai un œil un de ces jours si j'ai le temps ^^

Sinon, j'ai pensé à un concept fun : une clef USB.

Une appli référence dans sa config un ou plusieurs UUID de partition de clef USB. Ensuite, quand on lui demande, l'appli verrouille complètement la session et surveille les branchements de périphériques, et si on branche une clef dont l'UUID a été référencée, ça déverrouille automatiquement.

Z'en dites quoi ? ^^

Pylades · Le 18/01/2012, à 21:32

Que je veux bien l’adresse de ton fournisseur.

kamui57 · Le 18/01/2012, à 22:14

ArkSeth: http://doc.ubuntu-fr.org/tutoriel/pam-usb ?
http://geekfault.org/2009/05/19/authent … e-cle-usb/
(pas testés)

Dernière modification par kamui57 (Le 18/01/2012, à 22:15)

Dr Le Rouge · Le 18/01/2012, à 22:27

ArkSeth a écrit :

J'y jetterai un œil un de ces jours si j'ai le temps ^^

Sinon, j'ai pensé à un concept fun : une clef USB.
Une appli référence dans sa config un ou plusieurs UUID de partition de clef USB. Ensuite, quand on lui demande, l'appli verrouille complètement la session et surveille les branchements de périphériques, et si on branche une clef dont l'UUID a été référencée, ça déverrouille automatiquement.
Z'en dites quoi ? ^^

Plutôt que de jouer sur l'UUID, tu pourrais mettre une clef de chiffrement qui déverrouille une partition (genre avec cryptsetup). Enfin je dis ça, j'en sais un peu rien en fait ^^

Pylades · Le 19/01/2012, à 21:51

Putain, mais c’est quoi cette mise à jour de pacman avec ces clefs GnuPG qui foutent un bordel monstre ?

Nan mais si celui qui a fait ça voulait ces cochonneries, il pouvait installer une Debian, hein, pas la peine de pourrir Arch !

(Je sais que c’est sensé être plus secure, mais le gain est plus qu’hypothétique…)

Sinon, est-ce que l’un de vous a testé systemd ? C’est vraiment bien ? Est-ce que le boot est vraiment incroyablement rapide ?

The Uploader · Le 19/01/2012, à 21:55

Sur un SSD, j'ai pas tenté. Le gain doit être imperceptible. En plus, tous les daemons ne sont pas compatibles... C'est un gros bordel (enfin, on dirait).
Et sur mon ancien 5400 RPM, ben c'est tellement lent de toute façon que j'ai pas essayé non plus. ^^

Sinon, j'ai presque fini mes partiels ! \o/
(demain : IA, Agilité, Compilation / Théorie des langages, 3D)

Dernière modification par The Uploader (Le 19/01/2012, à 22:03)

Rolinh · Le 19/01/2012, à 22:42

@Pylade: je ne vois pas en quoi c'est le bordel. Il suffit de merger le rc.conf avec le pacnew et de générer la clé... Et je trouve l'évolution positive. S'il n'y a pas de "version" d'archlinux, il faut par conséquent mettre un petit peu la main à la pâte lors de certaines mises-à-jour et c'est tout à fait normal.

Pour systemd, je n'ai pas essayé et je ne compte pas le faire (je déteste la façon dont a été développé systemd). Et de toute façon, si c'est pour gagner une poignée de secondes... Sans SSD, mon OS démarre en 17 secondes (je vous dirais ce que cela donnera quand j'aurais installé mon SSD en mSATA que je vais cherché demain) donc bon... Et puis quand je n'ai pas besoin de redémarrer, j'utilise la mise-en-veille: on n'a pas plus rapide (2 secondes pour sortir de la mise-en-veille).

EDIT: à propos des pacnew, j'utilise ça (bon c'est améliorable):

# review and delete pacnew files
pacnew () {
    for n in /etc/**/*.pacnew; do
        if [[ -r ${n%.*} ]]; then
            sudo vimdiff $n ${n%.*} &&
            echo -n "delete $n ?(y/n) ";
            read -q && sudo rm $n
        fi
    done
}

Dernière modification par Rolinh (Le 19/01/2012, à 22:44)

The Uploader · Le 19/01/2012, à 22:47

Rolinh a écrit :

Sans SSD, mon OS démarre en 17 secondes (je vous dirais ce que cela donnera quand j'aurais installé mon SSD en mSATA que je vais cherché demain)

Combien de RPMs ?

Je suis passé de 5 minutes pleines (5400 RPM) à ~80 ou 50 secondes (et 40 ou 10 de ces secondes, c'est le POST du BIOS! .. ça dépend s'il démarre à froid ou non, on dirait..)

Dernière modification par The Uploader (Le 19/01/2012, à 22:48)

Pylades · Le 19/01/2012, à 23:08

Rolinh a écrit :

@Pylade: je ne vois pas en quoi c'est le bordel. Il suffit de merger le rc.conf avec le pacnew et de générer la clé... Et je trouve l'évolution positive. S'il n'y a pas de "version" d'archlinux, il faut par conséquent mettre un petit peu la main à la pâte lors de certaines mises-à-jour et c'est tout à fait normal.

Ce qui m’énerve, ce qu’on se retrouve à devoir gérer plein de clefs dans tous les sens, qu’on ne sait pas vraiment comment ça fonctionne, que ça alourdie le bousin, et que si l’on ne passe pas à ce système, ça bloque les mises à jours. Tout ça pour signer des paquets qui de toutes façons sont servis par des serveurs normalement relativement fiables, alors que l’on n’a aucune idée de la fiabilité de la clef et que l’on ne va pas s’emmerder à savoir si elle est fiable. En gros, ça fout un beau bordel pour un gain quasi nul.
Ça me fait penser à l’approche Debian… Arch c’est tout le contraire, normalement, non ?

(Et même, à y réfléchir, je préfère le système de Debian, où l’on signe par dépôt et où c’est quand même nettement plus clair et organisé.)

Rolinh a écrit :

(je déteste la façon dont a été développé systemd)

T’as des griefs en particulier ?

Dernière modification par Πυλάδης (Le 19/01/2012, à 23:11)

Rolinh · Le 20/01/2012, à 08:14

The Uploader a écrit :

Combien de RPMs ?

Un petit retour d'hdparm sera même mieux (c'est un Seagate de 500Gb @ 7200rpm):

/dev/sda:
 Timing buffered disk reads: 298 MB in  3.01 seconds =  99.06 MB/sec

@Pylade: tiens, un article qui explique assez bien comment est géré le système de clés avec pacman 4. Si tu ne veux pas t'encombrer avec la signature des paquets, il te suffit de laisser le SigLevel en Never. Si tu as eu des soucis, c'est probablement que tu n'avais pas mergé le pacman.conf.pacnew Moi je trouve ça bien, donc je l'active pour les dépôts pour lesquels c'est déjà bien en place et je n'ai pas à m'en plaindre.

Pour revenir à systemd, oui, j'ai des griefs. Le plus important étant que systemd est Linux-only par essence. Par conséquent, cela ne sera pas sans poser problèmes à tous les systèmes BSD. C'est le genre de truc typique de Lennart Poettering: il pense à lui et se tape complètement du reste (tant pis pour la portabilité). C'est comme la décision unilatérale prise par Fedora, poussé par Lennart, de virer /sbin (j'en avais fait un article détaillé sur mon blog). En soi, ce n'est pas forcément une mauvaise chose mais plutôt que de faire les choses dans son coin, il faudrait chercher à faire évoluer les standards, histoire que tous le monde s'adapte. Bref, l'équipe de Debian est contre l'adoption de systemd et l'explique ici. Tout comme pour /sbin, on cherche à gagner en performances par le fait de ne plus respecter les standards POSIX (c'est d'ailleurs, selon Lennart, un argument en faveur!!). En dehors de ce point majeur, on peut aussi avancer le fait que systemd est "bloated" (ex: sytemd à nécessairement besoin de dbus... mais que faire de dbus sur un serveur??). Bref, tout ça sans compter que Lennart est tout sauf diplomate (il n'y a qu'à voir l'avis de tout ceux qui ont tenté de l'approcher pour parler de systemd...). Ça te suffit comme griefs? En tout cas, pour moi, c'est bien suffisant comme raisons pour ne pas l'utiliser! On ne s'occupe pas de PID 0 dans son coin sans même écouter l'avis des autres!

Rolinh · Le 20/01/2012, à 21:03

/dev/sdb:
 Timing cached reads:   14216 MB in  2.00 seconds = 7113.21 MB/sec
 Timing buffered disk reads: 774 MB in  3.01 seconds = 257.41 MB/sec

Tiens, ~ 2.5X plus rapide en théorie... Je pense que la différence va se faire sentir! Et dire que j'ignorais ce qu'était le mSATA et que j'avais la place pour ça dans mon portable...
Allez, plus qu'à me motiver à réinstaller archlinux... (après les exas...).

tshirtman · Le 20/01/2012, à 21:14

/dev/sda:
 Timing cached reads:   6358 MB in  2.00 seconds = 3180.02 MB/sec
 Timing buffered disk reads: 466 MB in  3.01 seconds = 154.93 MB/sec

tu laisses ma SSD sur place…

Rolinh · Le 20/01/2012, à 21:30

C'est un OCZ Nocti que j'ai pris dans sa version 30Go (il n'en faut pas plus pour / et sinon ça devient vite hors de prix). Je verrais bien si cet investissement de 60€ en aura valu la peine mais j'ai plutôt un bon pressentiment.

The Uploader · Le 20/01/2012, à 21:56

/dev/sda:
 Timing cached reads:   1206 MB in  2.00 seconds = 602.73 MB/sec
 Timing buffered disk reads: 150 MB in  3.03 seconds =  49.58 MB/sec

C'est un "ata-SAMSUNG_SSD_830_Series_S0VXNYABB03759" sur du SATA II.

Rolinh · Le 20/01/2012, à 22:06

Pardon? C'est un SSD ça?

The Uploader · Le 20/01/2012, à 22:09

Bah c'est ce que me dis hdparm. Après, ça reste fulgurant comme un SSD. J'crois que c'est le SATA II qui gêne.

Dernière modification par The Uploader (Le 20/01/2012, à 22:12)

Rolinh · Le 20/01/2012, à 22:28

Ah non, là ça ne peut pas être le SATA II qui limite... La limite du SATA II se situe aux alentours des 300Mo/s. Le test doit être foireux.

The Uploader · Le 20/01/2012, à 22:33

Non, par contre le chipset qui le contrôle est foireux, j'pense. J'ai déjà vu plusieurs fois le PC se bloquer totalement (mais temporairement) lorsqu'il y avait une forte I/O sur le HDD (ça arrivait plus souvent avec le 5400 RPM). Et ça swapait même pas, donc le blocage n'était pas dû à un manque de mémoire de l'OS.

Il lui arrive aussi de se bloquer totalement quand il chauffe : la seule solution est le reboot. Je l'ai nettoyé il y a pas si longtemps, pourtant. Le pire est que je peux le faire chauffer pendant longteeeeeeemps sans plantage, le plus souvent, donc je suis pas sûr de la cause..

Dernière modification par The Uploader (Le 20/01/2012, à 22:38)

Rolinh · Le 20/01/2012, à 22:43

Bizarre. Alors il y a quelque chose de foireux parce qu'un SSD qui n'a que moitié moins de perf qu'un HDD @ 7200rpm bah... c'est pas normal.

The Uploader · Le 20/01/2012, à 22:48

Non, le moitié de moins de perfs j'pense que je le sentirai, la différence avec le 5400 RPM est bien trop énorme (énorme façon "distance de perfs égale à 3 galaxies"). ^^

tshirtman · Le 21/01/2012, à 01:37

ouais, mais apparement les perfs de ton ancien te mettaient au bords du suicide, alors c'était surement pas une référence…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2201 Le 15/01/2012, à 22:09

Re : /* Topic des codeurs [6] */

#2202 Le 16/01/2012, à 16:46

Re : /* Topic des codeurs [6] */

#2203 Le 16/01/2012, à 21:37

Re : /* Topic des codeurs [6] */

#2204 Le 17/01/2012, à 00:12

Re : /* Topic des codeurs [6] */

#2205 Le 18/01/2012, à 21:29

Re : /* Topic des codeurs [6] */

#2206 Le 18/01/2012, à 21:32

Re : /* Topic des codeurs [6] */

#2207 Le 18/01/2012, à 22:14

Re : /* Topic des codeurs [6] */

#2208 Le 18/01/2012, à 22:27

Re : /* Topic des codeurs [6] */

#2209 Le 19/01/2012, à 21:51

Re : /* Topic des codeurs [6] */

#2210 Le 19/01/2012, à 21:55

Re : /* Topic des codeurs [6] */

#2211 Le 19/01/2012, à 22:42

Re : /* Topic des codeurs [6] */

#2212 Le 19/01/2012, à 22:47

Re : /* Topic des codeurs [6] */

#2213 Le 19/01/2012, à 23:08

Re : /* Topic des codeurs [6] */

#2214 Le 20/01/2012, à 08:14

Re : /* Topic des codeurs [6] */

#2215 Le 20/01/2012, à 21:03

Re : /* Topic des codeurs [6] */

#2216 Le 20/01/2012, à 21:14

Re : /* Topic des codeurs [6] */

#2217 Le 20/01/2012, à 21:30

Re : /* Topic des codeurs [6] */

#2218 Le 20/01/2012, à 21:56

Re : /* Topic des codeurs [6] */

#2219 Le 20/01/2012, à 22:06

Re : /* Topic des codeurs [6] */

#2220 Le 20/01/2012, à 22:09

Re : /* Topic des codeurs [6] */

#2221 Le 20/01/2012, à 22:28

Re : /* Topic des codeurs [6] */

#2222 Le 20/01/2012, à 22:33

Re : /* Topic des codeurs [6] */

#2223 Le 20/01/2012, à 22:43

Re : /* Topic des codeurs [6] */

#2224 Le 20/01/2012, à 22:48

Re : /* Topic des codeurs [6] */

#2225 Le 21/01/2012, à 01:37

Re : /* Topic des codeurs [6] */

Pied de page des forums