riri le breton a écrit 84 commentaires

runit ne gère pas les dépendances, dinit oui. J'avais choisi runit au début pour sa simplicité, mais le manque de gestion de dépendance n'était pas top. dinit n'est pas parfait non plus. Par exemple par défaut si un service dont on dépend s'arrête, par exemple le réseau, celui qui en dépend, par exemple ntp, ne s'arrête pas. On peut toutefois le forcer.

openrc a les mêmes concepts que dinit, mais est selon moi plus lourd. Par comparaison, un même système lancé via openrc mettra plus de temps à avoir un environnement prêt, et consommera plus.

Ce sont des tests empiriques qui m'ont guidés, via mes machines virtuelles, mais c'était flagrant. De plus j'aime le côté vraiment KISS de dinit.

Le seul défaut que je lui trouve pour l'instant, est qu'on ne peut pas désactiver un service pour le prochain démarrage sans l'arrêter, et vice versa; les deux sont liés.

Merci d'avoir travaillé sur ça ! C'est le genre de dépendance qui me fait sortir les yeux des orbites.

Je n'ai pas testé les nouveautés, mais lors de la précédente dépèche j'avais essayé le jeu et j'avais bien aimé, même si j'ai juste essayé vite fait.

C'est en effet un excellent moyen de comprendre comment tout ça fonctionne, comment ça s'imbrique, pourquoi telles dépendances sont nécessaires, etc..

LFS existera je pense tant que des personnes voudront avoir ces connaissances, il évolue bien, en restant dans son cadre (et permettant d'aller plus loin avec BLFS)

Lorsque je participais au projet de distribution Nasgaïa, j'étais monsieur "système" et je m'étais fortement inspiré de LFS pour concevoir notre "créateur de distribution semi-automatisé".

D'ailleurs à l'époque l'utilisation du cross-compiling était une version à part, et je m'étais adapté non sans mal pour que la toolchain soit aussi indépendante du système hôte que possible. Tout cela est bien loin maintenant, et je regarde les informations concernant ce projet avec un petit sourire nostalgique :)

Oui concernant la limitation au texte pour les Server Sent Events, c'est relativement secondaire. Je suis loin d'être un spécialiste (et j'avoue ne pas être allé vérifier plus en avant), mais ce qui passe dans les événements, c'est fonctionnel entre le serveur et l'application, pas protocolaire.

Dire "tiens l'URL d'une nouvelle image à charger" ou "il faut aller récupérer cette mise à jour de document" a beaucoup de sens et n'est pas vraiment coûteux. Encore moins avec HTTP/2, mais même… et je dirais même que c'est plus souple. Plutôt que de transiter de facto des données binaires (la plupart du temps plus volumineuses) on a cette restriction de ne pouvoir que donner l'information "ça c'est dispo".

Je connaissais les Websockets, pour les avoir utilisé. Je ne connaissais pas les Server Sent Events, et j'aime beaucoup.

Patrick_g: Firefox a bien évolué je trouve (Servo, Quantum, Rust, etc). Il a presque rattrapé son retard technique sur Chrome (qui est plus récent) et le dépasse même sur certains points. Pour les utilisateurs de Chrome je pense que ça vaut vraiment le coup de refaire un essai.

Le texte simple et concis qui me fera réessayer.

Je suis sous Chromium depuis quelques années, et j'avais entendu parler des évolutions récentes de Firefox (grâce à LinuxFR), sans toutefois prendre le temps de refaire un yaourt -S firefox-fr.

Je confirme, utiliser le démon permet un net gain en mémoire (pour la rapidité de lancement, je ne sais pas). Le seul désavantage, c'est si une des fenêtres plante, c'est l'ensemble des instances qui plantent… mais urxvt ne plante jamais chez moi (ça fait 10 ans que je l'utilise tous les jours et ça a du arriver une ou deux fois).

A noter un petit utilitaire pratique (à mettre dans /usr/local/bin par exemple) pour automatiser le lancement du démon s'il n'est pas déjà présent:

#!/bin/sh
{ ps -U $USER | grep urxvtd; } || /usr/bin/urxvtd -q -o -f
exec urxvtc "$@"

En tout cas, cette dernière phrase moi m'a éclairé. Elle aurait mérité d'être dans l'article, en résumé de la section parlant des concepts.

Petite précision concernant Manjaro. Elle utilise ses propres dépôts, mais qui suit le rythme de mise à jour d'ArchLinux, avec un léger retard. Cette duplication sert entre autres à valider les mises à jour avant diffusion sur les dépôts de Manjaro, comme expliqué ici.

J'ai installé cette distribution pour le laptop de ma femme. Je reste pour ma part un fidèle à un ArchLinux pur.

export VIMDIR="$XDG_CONFIG_DIR/vim"
export VIMINIT="source '$XDG_CONFIG_DIR/vim/vimrc'"


Ça me fait penser à ArchBang, qui est ni plus ni moins une ArchLinux avec un jeu de paquets pré-installés.

C'est bien que l'on retrouve ce genre d'initiative en tant que dérivées de distributions majeures, car le upstream est respecté et on y trouve quand même une valeur ajoutée.

source "on le trouve très souvent dans l'embarqué, même dans Android…"

---->[]

ld-linux.-so.2 est hard-codé selon une configuration du compilateur (gcc) lors de son bootstrap (compilation de gcc pour avoir un autre gcc). Il est donc tout à fait possible de modifier /lib/ld-linux.so.2 pour le faire passer sous /usr/lib (le même type de problème s'était posé pour les différentiations entre /lib, /lib32 et /lib64).

Il a l'air fichtrement intéressant le GLMF ce mois-ci en ce qui me concerne.

D'ailleurs, c'est moi ou la passion pour l'électronique du rédac-chef se fait de plus en plus sentir ? (pour mon plus grand plaisir)

Je préfère xoria256 qui a des couleurs assez prononcées pour la syntaxe mais en restant doux. Voici la partie graphique de mon vimrc

if &t_Co > 2 || has('gui_running')
	syntax on
	set hls
	set bg=dark
	if &t_Co > 8 || has('gui_running')
		set cul
		colo xoria256
		hi CursorLine cterm=none
	el
		" < 256 colors
		colo desert
	en
	if has('gui_running')
		set co=87
		set lines=30
		set go-=T go-=t stal=2
		set gfn=Monospace\ 8
	en
en

Mais il faudra beaucoup plus de temps pour atteindre Linux 95 :)

Moi ce que je vois, outre la qualité maintenant devenu classique des dépêches sur le noyau, qu'il se passe de plus en plus de choses intéressantes : début de refonte, fin de refonte (BKL par exemple), plus de projets à fort impact.

Ça montre que les développeurs du noyau sont vraiment très au fait des besoins réels (stabilité/performances/etc..) des utilisateurs. On le sait tous, mais en avoir la preuve de temps en temps ne fait pas de mal.

Mes 2cts

Bravo à toi, tu es le premier a avoir fait un commentaire parlant du soft lui-même :)

Oh, pinaise !

Personnellement, je préfère éviter eclipse à cause de sa lourdeur, mais ce qui m'attire le plus chez lui, c'est la puissance de la colorisation syntaxique et du complètement, qui sont partiellement sémantique,(basés il me semble sur l'utilisation de gcc) donnant ainsi un bien meilleur retour au développeur.

J'ai l'impression que les développeurs de KDevelop ne sont pas allé aussi loin, et c'est dommage pour une version majeure.

Non je confirme, c'est une méthode très pratique que j'utilise de temps à autres.

Par exemple, je fais un peu de dev cross-platform, où la plateforme de base est Windows, mais on doit livrer les versions finales sur différents Unix et dérivés (dont GNU/Linux). Comme je n'ai pas de machine RedHat ou SuSE (les seuls supportés pour nos diffusions) facilement, je teste d'abord sous Cygwin pour éviter d'avoir à transférer l'arbre des sources. J'enlève le plus gros.

Après effectivement, il faut tester sur plateforme réelle, mais Cygwin permet de gagner un peu de temps.

La killer feature que j'attendais de manière officielle était le support des cartes AMD sur chipset R6xx en ce qui concerne KMS. J'ai testé rapidement sur une Fedora 12 qui a backporté l'implémentation sur un 2.6.31, et je dois dire que c'est un régal (si on a les bons mesa et xorg qui vont bien).

Voilà, juste pour dire que j'étais content, comme sûrement beaucoup de possesseurs de cartes graphiques AMD relativement récentes :-)

Je ne sais pas pourquoi cette réponse a été moissée (je n'ai pas trop suivi le fil :-) ), en tout cas, pour moi ce commentaire était pertinent car il m'a appris que dans le prochain Firefox (si on considère que la 3.6 est sortie), les plugins s'exécuteront dans des processus séparés - j'espère que cela isolera assez le navigateur de ses plugins, et empêchera sont plantage lorsque les plugins foirent (genre le flash).

Non tu peux vraiment me dire quel est l'appel système fork() sur Windows, ou même une pile POSIX, parce que moi je ne vois pas... mais attends :

Non il n'est pas aussi rapide que sous linux car il appel derrière des appels systemes Win32

Ha donc ce n'est pas natif, c'est émulé. Il ne faut pas confondre, car cela n'a rien a voir.

Quant à fork(), je dois dire qu'ayant commencé la programmation avec l'API Win32, et étant passé sur une vraie API (POSIX), j'ai su m'y faire, et je trouve aujourd'hui que fork() est plus élégant, associé à la panoplie des signaux POSIX bien-sûr :-)

Les threads (et donc QThread ou autre) sont également intéressants, mais AMHA pas à mettre partout ; un mix des deux peut s'avérer être la meilleure solution, quand fork() est réellement disponible, en natif, bien-sûr :-p

ArchLinux pur c'est pareil, ça ne passe pas sous VBox. J'ai également essayé avec qemu, mais pas mieux. Il y a un truc dans le noyau compilé sur le livecd qui ne plaît pas aux machines virtuelles, mais je ne sais pas quoi.

Tu es resté bloqué à MS Windows Me. Les MS Windows de la branche NT sont compatibles POSIX. Donc il y a bien fork.

Tu me diras où tu as vu que l'API (j'ai ajouté API car tu l'avais omis) Windows était compatible POSIX ... Si tu veux du POSIX, il faut au minimum ajouter la couche Unix Services for Windows, ou le nom qu'ils donnent aujourd'hui, et il faut bien-sûr compiler le programme pour l'utiliser (jamais testé, donc je ne connais pas les spécificités).

Dans tous les cas, le fork n'existe pas, il est au mieux simulé par la couche sus-mentionnée.