Mildred a écrit 2249 commentaires

Scott James Remnant (l'auteur de upstart et fervent défenseur de Xsplash¹) explique son choix par trois raisons:

- Xsplash est aussi compatible avec du matériel/drivers qui ne supporte pas KMS
- XSplash fournit un serveur X complet et permet donc rapidement la mise en place d'une interface graphique pour intéragit avec l'utilisateur. Il imagine entrer le mot de passe d'une partition chiffrée, mais on peux aussi imaginer un fsck intéractif.
- Si on peux démarrer plymouth, c'est qu'on peut démarrer Xorg, autant démarrer directement Xorg.

Il ne fait pas oublier que cela s'inscrit dans le projet d'Ubuntu qui veux un démarrage en moins de 10s. Dans ce contexte, démarrer plymouth pour le remplacer par Xorg très rapidement peux sembler une charge supplémentaire et inutile.

Ceci dit, je n'ai pas les conaissances techniques pour juger par moi même, et j'aime bien plymouth qui vient avec Fedora 12ß qui me permet d'avoir un boot graphique avec EFI et KMS (MacBook).


¹ http://www.netsplit.com/2009/09/02/making-a-splash/

Par exemple pour avoir un bureau qui s'étend sur deux écrans. Avoir plus de place quoi.

Pour moi, gitk et git gui (ou git citool) me suffisent comme interface graphique.

Certaines opérations sont plus faciles avec une interface graphique (voir l'historique, choisir exactement les lignes qu'on veut commiter (git add -i), ...) mais d'autres sont bien plus faciles en ligne de commande.

Mercurial et git sont très proches. J'utilisais Mercurial avant de passer à git, et finalement je préfère git :/

Pour moi, les différences que je vois sont:
- Dans git, tu peux perdre des commits facilement (par exemple en faisant un rebase, tu as des commits équivalents, mais pas exactement les même). Mercurial est beaucoup plus prudent je crois
- Avec git, lorsque tu clone un repository (pour travailler dessus en local par exemple) tu ne copies en fait que la branche master (en général). Ce qui fait que si tu partages à ton tour ton repository, tu ne partages que la branche master et pas les autres. J'ai trouvé ça inconfortable pour faire des échanges de commits entre un portable et une station via un repository sur clef usb.
- Dans Mercurial, chaque commit est associé à une branche. Ce qui fait qu'il est possible pour une branche d'avoir plusieurs têtes (heads). Avec git, seules les têtes peuvent être associées à une branche, et une branche ne peux avoir qu'une seule tête. Avec Mercurial, les merges se font entre plusieurs têtes de la même branche en général alors qu'avec git, c'est entre deux branches, la branche origin/branchname et branchname.
- git est populaire et avance très vite.
- git peux être difficile à prendre en main au départ
- le livre Mercurial est très bien fait
- git te laisse accéder à ses couches bas-niveau facilement

Les netbooks, oui, mais pas la formule actuelle

Pour ma part, je me suis procuré un OLPC XO-1 et je l'utilise majoritairement pour lire (mode e-book). Dans ces circonstances, l'autonomie est formidable (il se met en veille automatiquement, sauf l'écran, après une minute d'inactivité). Et le mode de lecture en plein soleil aussi.

Et en plus, il y a une fedora, je peux me connecter en VNC à une autre station (pour lire encore) et si j'ai besoin d'aller sur Internet, je peux toujours. J'ai un client SSH, un client VPN ... bien mieux qu'un simple e-book en fait.

En mode prise de note (couplé avec le logiciel Zim) il a quand même moins d'autonomie. Mais dans un emploi du temps peu chargé sur une journée, je n'ai pas eu de problèmes.

Bon, bien sûr, pour avoir la meilleure autonomie, il ne faut pas activer le wifi (en tout cas, pas dans un endroit où on ne peux pas se connecter à un réseau).

Sauf avec les distrib qui mettent / et /home sur la même partition :/

Les ACL sous Linux, c'est pas du POSIX ?
Parce qu'a ce moment là, les BSD devraient aussi pouvoir l'implémenter, non?

J'ai dernièrement fait un rm -rf * dans mon homedir ... je pensait être dans un sous dossier.

Finalement, je n'ai pas perdu grand chose. Principalement le dossier Desktop (qui me sert de poubelle en quelque sorte) mais j'ai eu peur sur le moment.

Vive btrfs

Je suppose parce que dans les en-tête Qt, il doit y avoir des macros:

#define slots /*nothing*/
#define signals /*nothing*/

Ce sont juste des mots-clefs supprimés par le préprocesseur C++ qui sont là pour que le compilateur moc comprenne où sont les signaux et les slots.

En gros, si la nested function est executé en dehors de la fonction qui la créer la pile d'appel n'a plus aucun sens. Une vrai closure doit gérer ce cas-là (Lisaac le fait pour les types blocs).


Tu veux me dire que comme vala, les block Lisaac peuvent accéder à des variables définies en dehors du block (upvalue), même si ces variables ne sont plus dans la pile au moment où le block est appelé ?
Je ne pense pas que ce soit le cas ...
Cela voudrait dire une allocation dans le tas.

Vala n'est pas un générateur de code, c'est bien un compilateur. C'est juste qu'il utilise du C comme code intermédiaire, c'est tout. Le C est suffisamment proche de la machine pour que ca ne pose pas de problèmes de performances. En fait, je pense que c'est même plus rapide que de générer du code machine ... gcc a plein d'optimisations qui sont mises a profit dans Vala.

Même gcc utilise du code intermédiaire, il n'est ni écrit, ni spécifié, mais c'est du code intermédiaire.

C'est déjà le cas avec GIMP 2.6
J'adore vraiment le mode multi-fenêtres et je n'aimerais pas avoir un mode fenêtre unique d'imposé :/

Le point principal, c'est que les toolbox ne sont pas vies commes des fenêtres principales. Lorsque l'application est en arrière plan, elles sont cachées, et bien sûr, on ne les comptabilise pas dans le alt-tab.

Enfin c'est presque déjà le cas avec le gimp 2.6 sous GNOME. Alt-tab n'affiche pas la toolbox. Si je met en avant une fenêtre contenant une image, la toolbox apparaît aussi. Je n'ai aucun reproche a la manière dont GIMP fonctionne avec plusieurs fenêtres (même si pour moi, j'ai tout docké dans la toolbox, je n'ai plus assez de place pour l'image sinon).

La seule chose qui me dérange un peu c'est la manière dont avec GIMP 2.6 une fenêtre complètement vide apparaît lorsqu'on a fermé la dernière image. Et le menu à disparu de la toolbox :(

A l'époque, ce n'était pas le cas.

Enfin, il faut dire qu'a l'époque, NM 0.7 n'existait pas encore, seulement pratiquement toutes les distributions l'utilisaient déjà.

Les paquets Arch sont super pratiques, ils sont faciles à faire, un peu rudimentaires certes.

Par contre du coté RPM, on a des signatures GPG, une distinction paquet source - plusieurs paquets binaires. la philosophie est clairement différente. Pacman ne pourrait pas convenir à une distribution comme Fedora, ce n'est pas assez sécurisé, et pas assez poussé sur certains points.

J'espère pouvoir dans le futur améliorer cet outil pour qu'on puisse faire de vrais paquets, avec toutes les métadonnées. Seulement avec une approche différente de rpmbuild. J'aimerais bien avoir ça pour toutes les distributions. Du coup, un programmeur pourrait facilement créer plein de paquets dans son Makefile.
Même si ce ne seront pas des paquets adaptés à la distribution, ce sera sûrement mieux que rien.

Avant, j'utilisais ArchLinux, et créer un paquet était simplissime. Il suffisait de créer un script shell PKGBUILD qui souvent est très court et de lancer makepkg ... et c'est bon.

Finalement, j'utilise Fedora, il y a d'autres aspects que j'apprécie (entre autre le fait qu'ils sont en avance sur certains projets, qu'on dispose de PackageKit, de NetworkManager 0.7 ...).

Pendant un temps, j'ai essayé de créer des paquets pour tous les programmes dont j'avais besoin et qui n'étaient pas packagés. Mais c'était long ... difficile. Donc j'ai abandonné, et je n'utilise plus vraiment d'applications non packagées.

Jusqu'à ce que je décide d'installer la dernière version de git.

J'espère que ça pourra être utile. Pour ma part, je pense que je ne vais pas me priver d'utiliser ce script.

Moi, re faisait un remplacement

' -> ' " ' " ' (sans les espaces)

ça donne:

abc"def'ghi -> 'abc"def'"'"'ghi'

mais ce que je voulais dire c'est que ce n'est pas comme on pourrait penser \'

Il faudrait que cette étape soit faite au niveau du make, et non pas au niveau du shell qui est invoqué par make. A ce point, c'est déjà trop tard.

J'ai entandu parler que les simples quotes ne pouvaient pas s'échapper. C'est d'ailleurs ainsi que certaines personnes ont pu prendre le contrôle de fonera:


As you can see, FON did take some precautions to prevent people injecting code: Parameters are enclosed in single quotes to avoid substitutions of any kind. The entering of strange characters is prohibited by the web interface, and even if you manage to get a single quote character into your ESSID, it will be "defused" by prepending a backslash to it.

[...]

But wait, is it? I was quite surprised when I consulted the bash manual page:

"Enclosing characters in single quotes preserves the literal value of each character within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash."


Pour traduire la page de manuel:

Chaque caractère dans des simples quotes préserve son sens. Une simple quote ne peux pas être présente au milieu d'une chaîne de caractères délimitée par de simples quotes, même si elle est précédée par un antislash.

http://stefans.datenbruch.de/lafonera/

Certes, c'est une possibilité, mais je préfère découper mes mots avant de les donner à exec, surtout qu'on est jamais vraiment sûr de ce que va être /bin/sh et comment il réagit vraiment.

Fedora me convient très bien

Sinon, j'aimerais revenir un peu sur les derniers commentaires. La solution de mettre des simple quotes autour des noms de fichiers serait une solution si les quotes n'étaient pas autorisées dans les noms de fichiers en eux même (au même titre que '/' ou que le caractère NULL). Mais je serais bien embêtée (par exemple pour écrire mon pseudo: Mildred Ki'Lya, même si on peut contourner avec un caractère unicode comme ’).

Ce que j'aime bien, c'est avoir un sysème robuste. Avoir un système qui peut avoir des comportements erratiques (une commande qui n'est pas exécutée comme prévu, ça peut parfois faire des gros dégats) ne me convient pas.

J'avais aussi dans l'idée que TBuild pouvait être sécurisé. je vois mal comment on peut sécuriser la chose si il suffit de mettre un nom de fichier «'; rm -rf /; echo '» pour finalement avoir une commande qui ressemble à:

gcc -o executable -c ''; rm -rf /; echo ''

Ça ne me paraît pas très sécurisé.


Dernière chose: je ne considère pas le shell inadapté, je l'utilise tous les jours. Je considère juste que du code shell généré pas forcément proprement n'est pas une bonne idée.

J'ai la prétention de vouloir faire des applications portables même sous Windows ou d'autres OS non unix, même si je ne les utilise pas.

J'ai eu la malchance de devoir développer sous Windows dernièrement (ça faisait des années que je n'avais pas touché à Windows) et je dois dire que même si mingw, msys, cygwin et coLinux ont bien été pratiques, je pense que j'aurais préféré avoir des applications natives.

Antre autre: git-svn n'arrêtait pas de planter, même avec coLinux.

Sans compter qu'il y a d'autres OS non unix libres dans la nature (par exemple IsaacOS, pour ceux qui suivent un peu de près le langage Lisaac dans lequel je me suis fortement investie).

ant, c'est une possibilité ...

seulement, je souhaitais le plus possible avoir une syntaxe pratique et facile, et pour moi, XML ne correspond pas vraiment.

Que scons gère les noms de fichiers particuliers, je n'en doute pas, par contre ça ne veux pas dire que les lignes de commande sont générées correctement. C'est la même chose avec Jam. Aucun problème avec Jam, mais lorsque les commandes sont générées, il peut y avoir des problèmes