Il ne s'agit pas de supprimer les pointeurs, mais de les rendre moins dangereux.
Les "smart pointers" sont des objets qui encapsulent un pointeur pour offrir certaines garanties, ils existent depuis longtemps par la bibliothèque boost, et maintenant directement dans le standard avec C++11.
Un unique_ptr représente la propriété exclusive d'un pointeur, quand l'objet unique_ptr est détruit, l'objet vers lequel il pointe l'est également. Il n'est pas possible de le copier, il faut explicitement le déplacer. Du coup un objet contenant un unique_ptr ne pourra par défaut pas être copié et on évite le problème spécifique de l'article.
Un shared_ptr représente la propriété partagée d'un pointeur, on peut en faire des copies et lorsque la dernière est détruite l'objet pointé est détruit.
En C++ le compilateur ne va jamais prouver que le code ne fait pas d'erreur, mais les outils permettent si ils sont utilisés correctement de lever des alertes ou erreurs de compilations en cas de mauvais usage.
Les kernels Android sont généralement issus de fork avec des modules ajoutés n'importe comment par les constructeurs. Rien n'est fait pour faire intégrer le support dans le kernel officiel, il n'y a donc aucun support sur le long terme (c'est à dire plus de 2 mois environ).
De plus ces kernels demande souvent une version précise du compilateur pour fonctionner, des paramètres très spécifiques du chargeur de démarrage et ne sont testés qu'avec une seule configuration.
On est donc dépendants du système d'exploitation fourni avec l'appareil et du bon vouloir du fabriquant.
Si demain Firefox OS décide qu'il faut utiliser une fonctionnalité du kernel 3.18 pour une raison quelconque, il sera impossible de faire la mise à jour sur un téléphone.
Pour ce qui est de la liberté des utilisateurs, voyons les réponses par rapport à la définition de la FSF:
0. la liberté d'exécuter le programme, pour tous les usages ;
Certaines APIs ne sont accessibles que par les programmes installés de base avec le système, et rien ne force un téléphone sous Firefox OS à permettre de flasher avec son propre OS
la liberté d'étudier le fonctionnement du programme et de l'adapter à ses besoins ;
Idem, la tivoization est possible
la liberté de redistribuer des copies du programme (ce qui implique la possibilité aussi bien de donner que de vendre des copies) ;
Ici ça a l'air bon
la liberté d'améliorer le programme et de distribuer ces améliorations au public, pour en faire profiter toute la communauté.
Idem, c'est bon
Firefox OS est basé sur Android (pour le kernel et les pilotes graphiques du moins) et ne pousse pas les utilisateurs à être libres. Il ne remonte pas non plus de grandes contributions au reste de l'écosystème, Jolla participe au développement de Qt et un peu toutes les briques qu'ils utilisent.
Ubuntu touch n'est pas encore réellement disponible, l'approche semble être celle d'avoir une Ubuntu complète avec une interface adaptée, ce qui serait plutôt bon. Il y a par contre un gros problème d'image vis-à-vis du libre : la réputation de non contribution et la décision de développer Mir au lieu de Wayland.
Debian veut avant tout faire progresser le logiciel libre. Pour ça il faut que ses logiciels soient facilement modifiables.
Dans le cas des images, c'est plus simple si les sources (svg, images avec calque ou image haute résolution) sont disponibles.
Techniquement ce n'est pas nécessaire pour distribuer un logiciel, mais ça l'est si le but est le logiciel libre.
Ne pas avoir dans les sources des produits générés me semble être une très bonne pratique.
Dans le cas du texte en png, quelqu'un voulant faire une traduction pourra le faire beaucoup plus facilement si l'image est générée.
Le svg sera plus facile à suivre dans le gestionnaire de versions, répond en partie à la problématique des résolutions multiples.
Dommage que ce soit du code incorrect (warning: dereferencing type-punned pointer will break strict-aliasing rules) et que ce soit moins performant qu'un calcul explicite avec sqrt.
C'est une curiosité intéressante mais je veux éviter d'avoir ce genre de chose dans mon code.
Merci à ceux qui appliquent ces principes, ça fait une semaine que je dois retracer ce que fait un fichier de 3000 lignes. Ça me fera très plaisir de le supprimer et faire la même chose en 2 ou 3 modules bien segmentés.
En EFI on peut spécifier sur quelle partition est l'application à démarrer. Je peux donc avoir WTF-OS qui utilise une partition WTF-FS pour placer son noyau/chargeur de démarrage. Si l'EFI sait lire la partition, tant mieux.
Maintenant je veux installer mon OS sur ce même ordinateur, d'après la norme je n'ai qu'a créer une partition FAT et définir une nouvelle variable qui référence mon chargeur de démarrage.
J'utilise depuis des années un noyau démarrable directement par EFI, j'ai un script qui lance la bonne commande magique efibootmgr dans mon installkernel.
Je peux donc choisir dans l'EFI lequel des noyaux je démarre.
En effet le noyau doit être installé pour chaque mise à jour du noyau, mais je peux difficilement faire autrement. la configuration EFI ajoute la nouvelle entrée et ne modifie pas les précédentes.
Ce que je vois c'est qu'on a l'EFI qui permet de choisir ce que l'on démarre, qui lance grub, qui permet de choisir ce qu'on démarre, qui charge le noyau.
L'EFI permet aussi de démarrer un shell, ce n'est pas la peine que le chargeur de démarrage fasse aussi le café comme c'est le cas de GRUB2.
Les implémentations ne sont pas actuellement acceptables, mais le principe lui-même est nettement meilleur que celui des anciens chargeurs de démarrage. Le firmware fournit une interface pour ajouter ou enlever des OS, pas la peine d'aller découvrir les autres potentiellement installés et se battre pour avoir la priorité sur les autres.
Heureusement, parfois le BIOS/UEFI n'a pas été écrit avec les pieds. Sur mon portable (ASUS N56VV), l'UEFI n'a aucun des problèmes décrits, et le multiboot/démarrer sur un DVD linux/whatever est très bien pris en charge.
Tu es certain qu'il marche vraiment ? Pour l'instant je n'en ai vu aucun qui n'ait pas de soucis. Les problèmes que j'ai vu:
* Impossible de lire dans des dossiers (Asrock)
* Parfois les noms de plus de 8 caractères ne sont pas reconnus (Asrock)
* Parfois il n'y a pas de place pour ajouter des variables efi (Asrock)
* L'entrée Windows boot manager disparait parfois lorsqu'on l'utilise
* L'ordre de boot est ignorée en mode automatique, bootx64.efi est utilisé (Samsung)
Et sinon pourquoi utiliser grub-efi ? Quel est son intérêt par rapport à l'EFI stub ?
Tant qu'à faire l'application peut elle-même vérifier si on est rentré à la maison en regardant la position, pour peu qu'on garde le mouchard téléphone sur soi.
Il y a aussi la question de la résilience. Si un processus plante (accès mémoire interdit par exemple), l'OS va l'arrêter.
Dans le cas d'un navigateur ayant un seul processus et un thread par onglet, tout le navigateur plante.
Dans le cas d'un navigateur ayant un processus par onglet, seul celui en erreur plante. Si le processus qui gère la fenêtre est bien fait, il peut simplement avertir l'utilisateur.
Avoir plusieurs processus complique la gestion, ajoute un léger surcoût pour les communications entre processus (gestion du cache partagé, cookies etc) mais est la seule solution pour avoir une isolation suffisante.
C'est vraiment une bonne chose que le navigateur lui-même soit encore développé, il y a des timides développements pour wayland aussi. Bientôt Firefox aura rattrapé son retard sur Epiphany.
Pour une institution il y a aussi le critère de l'indépendance économique et des retombées pour le reste des citoyens.
Si on fait le choix du logiciel propriétaire, il faut que ce soit l'organisme qui demande le logiciel qui en soit propriétaire pour ne pas dépendre d'un unique fournisseur.
Et pour ceux qui ont des sensibilités politiques de gauche/écologistes, le boulot d'un politicien est de faire progresser la société, pas uniquement de faire tourner le pays. Sinon on aurait déjà tout privatisé et laissé la main invisible du marché faire son travail.
Ah, excellent ! J'en étais resté aux applications certifiées et non privilégiées.
Du coup la limitation n'est que pour écouter sur les ports < 1024, ça reste dommage que Mozilla laisse le choix à l'opérateur encore.
C'est ce que je reproche le plus à Firefox OS.
Il n'est pas possible d'installer des applications natives, il me semble qu'il n'y a pas de terminal et on ne peut donc pas l'ajouter.
Firefox OS ne peut pas accéder à Internet mais uniquement au web, sauf pour les applications certifiées. Pas de serveur SSH, sauf si fourni par l'opérateur.
Je reste sur mon avis que Firefox OS donne plus de contrôle au constructeur et à l'opérateur, exactement l'opposé de ce que je souhaite.
Les .deb le permettre via apt-build ça n'est pas très compliqué à faire.
apt-build permet de choisir les options passées au configure ? Il permet de définir les dépendances en fonction de ces options de configuration ? Il permet de gérer les paquets à recompiler en cas de changement d'ABI ?
Je ne pense pas que ce soit possible, ni souhaitable d'ailleurs pour garder la cohérence de Debian. Les fonctionnalités avancées de Gentoo demandent une gestion très différente du système et donc un contenu tout autre dans les paquets.
Les dépassements de tampon sont toujours aussi répandus, principalement à cause des interfaces qui sont mal conçues.
Pour garder la compatibilité avec tous les langages on utilise le C comme base, et n'ayant pas de possibilité d'associer taille d'un tampon et données les dépassements sont monnaie courante et pas si évidents à déceler.
Il serait temps de réviser POSIX et trouver un moyen d'en finir avec les sockets, opérations sur les fichiers et les chaînes de caractères qui sont propices aux erreurs.
Une distribution dont le but est de rester la plus simple possible (Arch) ne va pas utiliser les scripts complexes pour mettre à jour la configuration, c'est laissé à l'utilisateur.
Une distribution dont le but est de permettre de tout choisir (Gentoo) ne peut pas fournir uniquement des paquets compilés, et les paquets sources doivent laisser la possibilité de configurer.
Il y a probablement d'autre usages qui nécessitent une configuration supplémentaire pour des questions de sécurité, pour des installations par utilisateur ou des besoins auxquels je ne pense pas.
On a donc déjà au moins une bonne raison d'avoir des formats de paquets différents, et comme ça a été déjà dit le contenu dépendra de la politique de la distribution.
Wayland est le protocole ainsi qu'une bibliothèque qui l'implémente.
Il permet à une application de gérer son affichage, recevoir ses évènements clavier et souris, gérer le copier-coller et probablement d'autres choses auxquelles je ne pense pas tout de suite.
Weston est un compositeur de référence, il permet d'avoir une démonstration du fonctionnement. C'est le compositeur qui expose l'interface wayland, il utilise donc la bibliothèque wayland pour être serveur.
Pour avoir un environnement de bureau complet il faut des interfaces supplémentaires : les commandes pour gérer les fenêtres, de demandes de capture d'écran, un moyen pour faire un clavier virtuel, de l'affichage distant etc. Ces fonctionnalités ne sont pas dans wayland directement (ou pas encore), elles peuvent être implémentées dans weston pour une démonstration ou simplement comme référence.
[^] # Re: Comparaison ?
Posté par Patrick Nicolas . En réponse au journal Journal Bookmark #2. Évalué à 4.
Il ne s'agit pas de supprimer les pointeurs, mais de les rendre moins dangereux.
Les "smart pointers" sont des objets qui encapsulent un pointeur pour offrir certaines garanties, ils existent depuis longtemps par la bibliothèque boost, et maintenant directement dans le standard avec C++11.
Un unique_ptr représente la propriété exclusive d'un pointeur, quand l'objet unique_ptr est détruit, l'objet vers lequel il pointe l'est également. Il n'est pas possible de le copier, il faut explicitement le déplacer. Du coup un objet contenant un unique_ptr ne pourra par défaut pas être copié et on évite le problème spécifique de l'article.
Un shared_ptr représente la propriété partagée d'un pointeur, on peut en faire des copies et lorsque la dernière est détruite l'objet pointé est détruit.
En C++ le compilateur ne va jamais prouver que le code ne fait pas d'erreur, mais les outils permettent si ils sont utilisés correctement de lever des alertes ou erreurs de compilations en cas de mauvais usage.
[^] # Re: Jolla et le libre
Posté par Patrick Nicolas . En réponse au journal Fiche produit Microsoft - N900. Évalué à 6.
Les kernels Android sont généralement issus de fork avec des modules ajoutés n'importe comment par les constructeurs. Rien n'est fait pour faire intégrer le support dans le kernel officiel, il n'y a donc aucun support sur le long terme (c'est à dire plus de 2 mois environ).
De plus ces kernels demande souvent une version précise du compilateur pour fonctionner, des paramètres très spécifiques du chargeur de démarrage et ne sont testés qu'avec une seule configuration.
On est donc dépendants du système d'exploitation fourni avec l'appareil et du bon vouloir du fabriquant.
Si demain Firefox OS décide qu'il faut utiliser une fonctionnalité du kernel 3.18 pour une raison quelconque, il sera impossible de faire la mise à jour sur un téléphone.
Pour ce qui est de la liberté des utilisateurs, voyons les réponses par rapport à la définition de la FSF:
0. la liberté d'exécuter le programme, pour tous les usages ;
Certaines APIs ne sont accessibles que par les programmes installés de base avec le système, et rien ne force un téléphone sous Firefox OS à permettre de flasher avec son propre OS
la liberté d'étudier le fonctionnement du programme et de l'adapter à ses besoins ;
Idem, la tivoization est possible
la liberté de redistribuer des copies du programme (ce qui implique la possibilité aussi bien de donner que de vendre des copies) ;
Ici ça a l'air bon
la liberté d'améliorer le programme et de distribuer ces améliorations au public, pour en faire profiter toute la communauté.
Idem, c'est bon
[^] # Re: Jolla et le libre
Posté par Patrick Nicolas . En réponse au journal Fiche produit Microsoft - N900. Évalué à 1.
Firefox OS est basé sur Android (pour le kernel et les pilotes graphiques du moins) et ne pousse pas les utilisateurs à être libres. Il ne remonte pas non plus de grandes contributions au reste de l'écosystème, Jolla participe au développement de Qt et un peu toutes les briques qu'ils utilisent.
Ubuntu touch n'est pas encore réellement disponible, l'approche semble être celle d'avoir une Ubuntu complète avec une interface adaptée, ce qui serait plutôt bon. Il y a par contre un gros problème d'image vis-à-vis du libre : la réputation de non contribution et la décision de développer Mir au lieu de Wayland.
[^] # Re: Débuggage
Posté par Patrick Nicolas . En réponse au message Exercice shell script. Évalué à 3.
Il existe aussi (du moins en bash) la commande set -x
Lorsque ce mode est activé, bash va afficher toutes les commandes avant de les exécuter.
[^] # Re: Bonnes pratiques
Posté par Patrick Nicolas . En réponse au journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?. Évalué à 1.
Debian veut avant tout faire progresser le logiciel libre. Pour ça il faut que ses logiciels soient facilement modifiables.
Dans le cas des images, c'est plus simple si les sources (svg, images avec calque ou image haute résolution) sont disponibles.
Techniquement ce n'est pas nécessaire pour distribuer un logiciel, mais ça l'est si le but est le logiciel libre.
# Bonnes pratiques
Posté par Patrick Nicolas . En réponse au journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?. Évalué à 4.
Ne pas avoir dans les sources des produits générés me semble être une très bonne pratique.
Dans le cas du texte en png, quelqu'un voulant faire une traduction pourra le faire beaucoup plus facilement si l'image est générée.
Le svg sera plus facile à suivre dans le gestionnaire de versions, répond en partie à la problématique des résolutions multiples.
[^] # Re: C'est quoi le délire avec les polices en taille 8px ?
Posté par Patrick Nicolas . En réponse à la dépêche Enlightenment DR 0.19 et autres nouveautés éclairées. Évalué à 3.
http://dotsies.org/ ? on en avait parlé sur ce journal.
[^] # Re: Plutôt beauté du design
Posté par Patrick Nicolas . En réponse au journal "beauté du code". Évalué à 4.
D'après https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723 lorsque l'on écrit 1/sqrt(x) et que l'on compile avec -ffast-math c'est plus rapide (et précis) que cette astuce.
Il optimise aussi sqrt(x) en x*1/sqtr(x) qui est plus rapide !
[^] # Re: Plutôt beauté du design
Posté par Patrick Nicolas . En réponse au journal "beauté du code". Évalué à 4.
Dommage que ce soit du code incorrect (warning: dereferencing type-punned pointer will break strict-aliasing rules) et que ce soit moins performant qu'un calcul explicite avec sqrt.
C'est une curiosité intéressante mais je veux éviter d'avoir ce genre de chose dans mon code.
[^] # Re: Ceci n'est pas un troll.
Posté par Patrick Nicolas . En réponse au journal "beauté du code". Évalué à 4.
Merci à ceux qui appliquent ces principes, ça fait une semaine que je dois retracer ce que fait un fichier de 3000 lignes. Ça me fera très plaisir de le supprimer et faire la même chose en 2 ou 3 modules bien segmentés.
# Journée du 30 août
Posté par Patrick Nicolas . En réponse au journal Le décompte pour la prochaine révolution est lancé . Évalué à 2.
Tu as posté ton journal le mauvais jour, il disparaîtra demain.
[^] # Re: Facile d'accuser n'importe quoi.
Posté par Patrick Nicolas . En réponse au journal UEFI, je chie ton nom. Évalué à 0.
En EFI on peut spécifier sur quelle partition est l'application à démarrer. Je peux donc avoir WTF-OS qui utilise une partition WTF-FS pour placer son noyau/chargeur de démarrage. Si l'EFI sait lire la partition, tant mieux.
Maintenant je veux installer mon OS sur ce même ordinateur, d'après la norme je n'ai qu'a créer une partition FAT et définir une nouvelle variable qui référence mon chargeur de démarrage.
[^] # Re: Facile d'accuser n'importe quoi.
Posté par Patrick Nicolas . En réponse au journal UEFI, je chie ton nom. Évalué à 1.
Pour déclarer un nouveau noyau: efibootmgr -c (plus les paramètres du noyau)
man efibootmgr
[^] # Re: Facile d'accuser n'importe quoi.
Posté par Patrick Nicolas . En réponse au journal UEFI, je chie ton nom. Évalué à 7.
J'utilise depuis des années un noyau démarrable directement par EFI, j'ai un script qui lance la bonne commande magique efibootmgr dans mon installkernel.
Je peux donc choisir dans l'EFI lequel des noyaux je démarre.
En effet le noyau doit être installé pour chaque mise à jour du noyau, mais je peux difficilement faire autrement. la configuration EFI ajoute la nouvelle entrée et ne modifie pas les précédentes.
Ce que je vois c'est qu'on a l'EFI qui permet de choisir ce que l'on démarre, qui lance grub, qui permet de choisir ce qu'on démarre, qui charge le noyau.
L'EFI permet aussi de démarrer un shell, ce n'est pas la peine que le chargeur de démarrage fasse aussi le café comme c'est le cas de GRUB2.
Les implémentations ne sont pas actuellement acceptables, mais le principe lui-même est nettement meilleur que celui des anciens chargeurs de démarrage. Le firmware fournit une interface pour ajouter ou enlever des OS, pas la peine d'aller découvrir les autres potentiellement installés et se battre pour avoir la priorité sur les autres.
[^] # Re: Facile d'accuser n'importe quoi.
Posté par Patrick Nicolas . En réponse au journal UEFI, je chie ton nom. Évalué à 7.
Tu es certain qu'il marche vraiment ? Pour l'instant je n'en ai vu aucun qui n'ait pas de soucis. Les problèmes que j'ai vu:
* Impossible de lire dans des dossiers (Asrock)
* Parfois les noms de plus de 8 caractères ne sont pas reconnus (Asrock)
* Parfois il n'y a pas de place pour ajouter des variables efi (Asrock)
* L'entrée Windows boot manager disparait parfois lorsqu'on l'utilise
* L'ordre de boot est ignorée en mode automatique, bootx64.efi est utilisé (Samsung)
Et sinon pourquoi utiliser grub-efi ? Quel est son intérêt par rapport à l'EFI stub ?
[^] # Re: Merci
Posté par Patrick Nicolas . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 5.
Tant qu'à faire l'application peut elle-même vérifier si on est rentré à la maison en regardant la position, pour peu qu'on garde le
mouchardtéléphone sur soi.[^] # Re: Process VS thread
Posté par Patrick Nicolas . En réponse au journal Des nouvelles d'Electrolysis. Évalué à 7.
Il y a aussi la question de la résilience. Si un processus plante (accès mémoire interdit par exemple), l'OS va l'arrêter.
Dans le cas d'un navigateur ayant un seul processus et un thread par onglet, tout le navigateur plante.
Dans le cas d'un navigateur ayant un processus par onglet, seul celui en erreur plante. Si le processus qui gère la fenêtre est bien fait, il peut simplement avertir l'utilisateur.
Avoir plusieurs processus complique la gestion, ajoute un léger surcoût pour les communications entre processus (gestion du cache partagé, cookies etc) mais est la seule solution pour avoir une isolation suffisante.
C'est vraiment une bonne chose que le navigateur lui-même soit encore développé, il y a des timides développements pour wayland aussi. Bientôt Firefox aura rattrapé son retard sur Epiphany.
[^] # Re: PRISM
Posté par Patrick Nicolas . En réponse au journal Munich ferait marche arrière. Évalué à 9.
Pour une institution il y a aussi le critère de l'indépendance économique et des retombées pour le reste des citoyens.
Si on fait le choix du logiciel propriétaire, il faut que ce soit l'organisme qui demande le logiciel qui en soit propriétaire pour ne pas dépendre d'un unique fournisseur.
Et pour ceux qui ont des sensibilités politiques de gauche/écologistes, le boulot d'un politicien est de faire progresser la société, pas uniquement de faire tourner le pays. Sinon on aurait déjà tout privatisé et laissé la main invisible du marché faire son travail.
[^] # Re: Deux, 3 trucs
Posté par Patrick Nicolas . En réponse au journal Firefox OS, mon avis !. Évalué à 1.
Ah, excellent ! J'en étais resté aux applications certifiées et non privilégiées.
Du coup la limitation n'est que pour écouter sur les ports < 1024, ça reste dommage que Mozilla laisse le choix à l'opérateur encore.
[^] # Re: Deux, 3 trucs
Posté par Patrick Nicolas . En réponse au journal Firefox OS, mon avis !. Évalué à 10.
C'est ce que je reproche le plus à Firefox OS.
Il n'est pas possible d'installer des applications natives, il me semble qu'il n'y a pas de terminal et on ne peut donc pas l'ajouter.
Firefox OS ne peut pas accéder à Internet mais uniquement au web, sauf pour les applications certifiées. Pas de serveur SSH, sauf si fourni par l'opérateur.
Je reste sur mon avis que Firefox OS donne plus de contrôle au constructeur et à l'opérateur, exactement l'opposé de ce que je souhaite.
[^] # Re: robertix ?
Posté par Patrick Nicolas . En réponse au message regulation temperature. Évalué à 1.
Mieux encore pour les processeurs récents: thermald
Tout ce que j'ai réussi à faire avec c'est obtenir des kernel panic, mais je ne crois pas que ce soit le moyen prévu de diminuer la chauffe.
[^] # Re: Un petit exemple
Posté par Patrick Nicolas . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 3.
apt-build permet de choisir les options passées au configure ? Il permet de définir les dépendances en fonction de ces options de configuration ? Il permet de gérer les paquets à recompiler en cas de changement d'ABI ?
Je ne pense pas que ce soit possible, ni souhaitable d'ailleurs pour garder la cohérence de Debian. Les fonctionnalités avancées de Gentoo demandent une gestion très différente du système et donc un contenu tout autre dans les paquets.
# Encore un dépassement de tampon
Posté par Patrick Nicolas . En réponse à la dépêche Nouvelle faille importante dans GnuTLS. Évalué à 6.
Les dépassements de tampon sont toujours aussi répandus, principalement à cause des interfaces qui sont mal conçues.
Pour garder la compatibilité avec tous les langages on utilise le C comme base, et n'ayant pas de possibilité d'associer taille d'un tampon et données les dépassements sont monnaie courante et pas si évidents à déceler.
Il serait temps de réviser POSIX et trouver un moyen d'en finir avec les sockets, opérations sur les fichiers et les chaînes de caractères qui sont propices aux erreurs.
[^] # Re: Un petit exemple
Posté par Patrick Nicolas . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 3.
Une distribution dont le but est de rester la plus simple possible (Arch) ne va pas utiliser les scripts complexes pour mettre à jour la configuration, c'est laissé à l'utilisateur.
Une distribution dont le but est de permettre de tout choisir (Gentoo) ne peut pas fournir uniquement des paquets compilés, et les paquets sources doivent laisser la possibilité de configurer.
Il y a probablement d'autre usages qui nécessitent une configuration supplémentaire pour des questions de sécurité, pour des installations par utilisateur ou des besoins auxquels je ne pense pas.
On a donc déjà au moins une bonne raison d'avoir des formats de paquets différents, et comme ça a été déjà dit le contenu dépendra de la politique de la distribution.
[^] # Re: Titre
Posté par Patrick Nicolas . En réponse au journal Wayland & Weston 1.5.0 sont publiés. Évalué à 8.
Wayland est le protocole ainsi qu'une bibliothèque qui l'implémente.
Il permet à une application de gérer son affichage, recevoir ses évènements clavier et souris, gérer le copier-coller et probablement d'autres choses auxquelles je ne pense pas tout de suite.
Weston est un compositeur de référence, il permet d'avoir une démonstration du fonctionnement. C'est le compositeur qui expose l'interface wayland, il utilise donc la bibliothèque wayland pour être serveur.
Pour avoir un environnement de bureau complet il faut des interfaces supplémentaires : les commandes pour gérer les fenêtres, de demandes de capture d'écran, un moyen pour faire un clavier virtuel, de l'affichage distant etc. Ces fonctionnalités ne sont pas dans wayland directement (ou pas encore), elles peuvent être implémentées dans weston pour une démonstration ou simplement comme référence.