Ça n’a jamais vraiment été la question. Si l’on fournit un compositeur Wayland pavant (c’est ce que propose ici Enlightenment), alors Wayland aura un gestionnaire de fenêtre pavant. Les questions qui restent sont :
sera-t-il facile de transposer/réécrire nos gestionnaires de fenêtres favoris pour Wayland ? Combien disparaîtront avec X ?
les applications joueront-elles le jeu ? Les applications Gnome 3 sont déjà ingérables avec n’importe quel compositeur à cause de leurs décorations côté client, pavant ou non. L’avenir dira si les dév’s Gnome entendront raison ou si c’est ce comportement qui va se généraliser et aboutir à des programmes spécialisés pour chaque gestionnaire de fenêtre/compositeur Wayland.
X n’est pas encore mort, et il ne disparaîtra pas tout de suite avec l’arrivée de Wayland, donc il reste encore beaucoup de raisons d’espérer et il est beaucoup trop tôt pour crier à la fin du monde. À titre personnel, j’aurais quand-même souhaité que la route vers le tout Wayland soit moins sinueuse pour les gestionnaires de fenêtres alternatifs.
Accessoirement, avec l'énergie renouvelable, je me demande si c'est toujours aussi pertinent?
Ça l’est d’autant plus. Réduire l’amplitude du pic de consommation journalier est LE défi principal qui limite la percée des énergies renouvelables (autres qu’hydrauliques). (bon, pas que, le gras est sûrement de trop, mais quand-même, c’est important et ça touche aussi d’autres problématiques énergétiques)
J'ai NeverWinter Nights (jeu datant de 2001) qui tourne bien sur ma Archlinux
Les commentaires de Riendf transpirent la mauvaise fois, mais pour le coup, le tien aussi n’est que partiellement vrai. Je n’arrive plus à faire tourner Neverwinter Nights depuis quelques temps sur ma Debian. J’obtiens soit des segfault, soit des polygones bizarres qui obstruent complètement la vision dans le jeu (le rendant injouable bien que non planté) selon les pilotes que j’utilise (Nvidia libres ou proprios, et Intel libres).
D’après mes investigations très limitées (le binaire de NwN vient sans source ni symboles de débogage évidemment), je suppose que cela provient d’un bug dans NwN mis en lumière par certains pilotes graphiques et certaines options de compilation “hardened” de bibliothèques. Je ne blâmerai donc pas tout de suite mon système, mais plutôt le développement arrêté de ce jeu. Pour autant, il ne tourne pas facilement sous Linux non plus (et c’est peut-être le même bug qui le fait planter avec un Windows récent).
Va falloir peu avant que tu changes tout le téléphone!
Oui, mais tu ne changes pas tout d’un coup, et quand tu rachètes ton nouvel écran (et donc la structure, si tu choisis une taille différente), tu peux garder la puce 4G, le GPS et le stockage interne de ton précédent téléphone.
Parce-que le processeur qui devient lent, l’écran trop petit, l’accès au réseaux mobiles plus modernes poussent déjà à changer de téléphone régulièrement, sauf qu’aujourd’hui on rachète 1 tout à chaque fois dès qu’un seul des composants paraît dépassé.
ou on le récupère d’un plus consommateur que nous, mais on change quand-même tout le téléphone. ↩
Ce que tu écris est vrai, sauf la conclusion, parce-que
Si un utilisateur malicieux arrive a obtenir un accès root a l’intérieur de la chroot
ça fait quand-même un gros « si ». Un chroot réduit quand-même considérablement la surface d’attaque, parce-que trouver une faille dans un programme c’est une chose, mais l’exploiter ensuite pour trouver une faille dans le système qui permet de passer « root », ça fait une grosse marche supplémentaire. Et ça ce jeu là, on pourrait rajouter, exploiter une faille qui fait planter SELinux pour le même prix parce-que tous les mécanismes de contrôle contiennent des bugs, ça reste des logiciels.
Donc chroot n’est pas la panacée, il faut savoir ce de quoi ça protège, mais c’est loin d’être nul comme en apport en matière de sécurité.
C’est encore plus flagrant en Fortran, qui ne propose rien de plus que le C à ce niveau, mais dont la syntaxe cache le passage de pointeur. On a bien des fonctions d’ordre supérieur sans fermeture.
La limitation par rapport aux fonctions citoyens de première classe est que, pour le C ou le Fortran, l’appel à la fonction qui utilise une autre fonction en paramètre n’est valide que tant que son paramètre est défini (on ne quitte pas la portée de sa définition).
Edit: dans la mesure ou l’étoile n’est même pas nécessaire en C, le Fortran ne change rien, le passage de pointeur est discret en C aussi.
il est aisé de concevoir que des commandes vectorielles doivent logiquement être plus efficaces
Sauf que toutes les boîtes à outils graphiques, à de rares (et vieilles) exceptions près, n’utilisent plus les commandes vectorielles de X.org mais dessinent et envoient directement leur rendu sous forme matricielle.
Et au final, comme ça ennuie tout le monde, on fourre tout sur le port 80 par facilité, et on se retrouve avec une version de TCP/IP à un seul port par adresse sur Internet.
Je ne vois pas la révolution, ni le pavé dans la marre, par rapport à 0install qui n’a jamais vraiment décollé. Ça utilise systemd et BTRFS donc c’est forcément mieux, mais à part ça ?
Debian testing au contraire, c'est de l'expérimental (d'où le nom "testing").
Pour l’expérimental, la branche correspondante de Debian c’est plutôt « experimental ». Ensuite, ce que tu décris ressemble plus à Sid (« unstable ») que « testing », mais ton commentaire reste vrai : « testing » n’est pas une rolling release au sens de Gentoo (mais pour Arch, ça se discute :-) ).
Tu trouve qu'aujourd'hui c'est comment entre chrome, firefox et konqueror par exemple ?
Raison de plus pour remettre les onglets côté gestionnaire de fenêtre :-) Quoiqu’en fait tes exemples sont particuliers, si ces programmes gèrent les onglets alors que le gestionnaire de fenêtres ne le fait pas c’est parce-qu’ils en ont un usage avancé, et proposent donc autour de ces onglets des ergonomies spécifiques qui restent utiles même avec un gestionnaire de fenêtre qui gère aussi des onglets.
Par contre, pour associer la fenêtre de mon gestionnaire de fichiers ouvert dans mon dossier de téléchargements à ma fenêtre de firefox, ou celle d’un terminal avec celle de VI et celle de ma visionneuse PDf quand je rédige en LateX, là il faut que le gestionnaire de fenêtre connaisse les onglets, et qu’il puisse les dessiner. Ce que fait par exemple Fluxbox, mais n’est pas possible à implémenter en l’état avec Wayland et est déjà complètement affreux avec les logiciels Gnome 3.
Posté par jyes .
En réponse au journal Cairo Dock pour Wayland.
Évalué à 5.
Dernière modification le 24 juin 2014 à 13:46.
En jouant sur les différents thèmes, on arrive souvent à accorder les différents toolkits graphiques (certains, comme Qt, y mettent vraiment du leur et peuvent utiliser les thèmes d’autres toolkits, d’autres nécessitent un peu de bricolage jusqu’au .Xresources). Mais à la limite la couleur des dégradés et de la sélection du texte on s’en fout pas mal. Le vrai problème des décorations côté client c’est la perte en fonctionnalités : quid des gestionnaires de fenêtres pavant ? des onglets ?
Si Kwin suit la voie des décorations côté gestionnaire de fenêtre, c’est parce-que c’est le seul généraliste à implémenter des fonctions avancées. À l’inverse, les programmes Gnome actuels sont dégueulasses dans Fluxbox, ils dessinent eux-mêmes leur transparence et leur ombre, sans se soucier des réglages du compositeur.
Dans ce cas autant partager un fichier chiffré avec GPG. Toute le monde peut alors transporter les données (aider à le faire transiter) mais seuls ses destinataires peuvent le déchiffrer. Bien sûr, on peut vouloir intégrer ça de façon plus couplée avec le protocole de partage pour gérer des droits ou du versionnement, mais dans ce cas l’approche de l’auteur me semble plus pertinente que je système de clefs asymétriques.
Ce que je trouve le plus dommage, c'est que l'application dessine le contour de la fenêtre, qu'il n'y ait pas de WM réellement séparé.
Espérons que des solutions standardisées émergeront. Je ne sais pas comment les logiciels KDE vont négocier ça avec Kwin, mais il y a de fortes chances que ça devienne le standard de fait. Espérons alors que les autres logiciels hors de KDE suivront. Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.
Tu pourrais tout à fait avoir un client local qui fait la même chose (c'est juste que je n'en connais pas).
Avec Gnome, il y a Gucharmap qui permet de faire des recherches hors ligne sur le descriptif des symboles Unicode et de regarder leur représentation dans différentes polices de caractères. Pour le moment, il n’inclut pas encore Unicode 7.0 il me semble, mais ce n’est qu’une question de temps.
donc savoir qui participe, pas facile sur une liste de diffusion
C’est évident que l’une des prémisses au chiffrement est de savoir à qui l’on destine son message.
Ensuite, pour une liste, il est sûrement plus pratique de partager un secret (qui peut toujours être une clé privée commune pour la liste, transmise une seule fois à chaque participant avec sa clé publique à lui, ce n’est pas une limitation de la crypto ou de PGP en soi).
C’est un fait, le chiffrement fonctionne mal pour les informations diffusées publiquement. Ses critiques souligneront que c’est fort dommage car ça ne permet pas de s’assurer que seul un destinataire inconnu parviendra à lire le message. Étonnant, non ?
En gros, au lieu d'avoir une structure simple derriere la table de hash, on fait appel a une structure un peu plus complexe qui permet de diminuer l'impact d'une collision. En passant a du O(log n) dans le pire cas.
C’est à mon avis nécessaire. Au delà de mon avis plus que réservé sur les décorations côté client, la richesse des environnement de bureaux dépasse largement Gnome et KDE. Les gestionnaires de fenêtres pavant, ou le groupement de fenêtres en onglets auront toujours des utilisateurs après le passage à Wayland… si les applications ne supportent pas un mode de décoration par le gestionnaire, la vie de ces utilisateurs sera bien moins belle quand « Linux sera prêt pour le desktop ».
ça joue pas toute les notes, mais je m'en fout, j'ai pas besoin du Do mineur
Les problèmes avec autofs, ou le boot sur partition chiffrée, etc me font penser que systemd n’est pas non plus un stradivarius. Personnellement, je pense que systemd est une piste intéressante, et sûrement le futur, mais il arrive beaucoup trop vite dans les distributions et est présenté par ses auteurs et défenseurs comme une solution qui surpasse toutes les précédentes, alors qu’il ne tient pas encore toutes ses promesses.
Je n’ai pas répondu « sécurité » au sondage car il y est explicitement fait référence à la réactivité. Cela me parait un bon argument, mais à destination des connaisseurs, et pas du tout du grand public non-informaticien. Par contre, dans mon entourage non informaticien, j’en trouve un certain nombre qui privilégient des logiciels libres par qu’il est en général plus facile de les trouver via des canaux « fiables ». Par fiable je n’entend pas ici un dépot et des paquets signés (ceux qui y seraient sensibles auraient déjà quitté Windows), mais pour les utilisateurs de Windows, au moins des installateurs qui ne pourrissent pas le système de logiciels tiers aux fonctionnalités pas très claires et de barres de recherche ou autres windowseries courantes.
Ce n’est pas vraiment un avantage inhérent au libre, mais les usages font que l’on trouve plus facilement des installateurs pour Windows propres pour des logiciels libres, sur les sites officiels des projets (et non sur télécharge-un-logiciel-gratuit-fourni-par-jenesaisqui.com). Je sais aussi combien cette habitude majoritaire n’est pas une règle absolue, Sourceforge ayant basculé du côte obscur maintenant, les mauvaises habitudes se répandent.
Donc ça m'agace un peu qu'on cite systématiquement ces logiciels en tant que tel.
En réalité, il faudrait parler de OwnCloud + service d'hébergement de serveur virtuel. Au final on se retrouve aussi dépendant du cloud
Donc, tu cherches une alternative à Dropbox, qui ne soit pas dépendante du cloud (en utilisant la définition qui transparaît de ton commentaire : à savoir un service hébergé, joignable par le réseau Internet) ? Effectivement, toute alternative qui te sera proposée risque de te décevoir.
"deb7u6" […] il y a t'il une signification spécifique derrière ça
"deb7u6" = Debian 7 (Wheezy) update 6.
Les mises à jour 5 et 6 (deb7u5, deb7u6) de l’équipe de sécurité servent justement à corriger la faille Heartbleed (cf. l’autre réponse de Xavier Claude pour le vérifier).
[^] # Re: Le gestionnaire de fenêtre pavant fonctionne t'il avec Wayland?
Posté par jyes . En réponse à la dépêche Enlightenment DR 0.19 et autres nouveautés éclairées. Évalué à 4.
Ça n’a jamais vraiment été la question. Si l’on fournit un compositeur Wayland pavant (c’est ce que propose ici Enlightenment), alors Wayland aura un gestionnaire de fenêtre pavant. Les questions qui restent sont :
X n’est pas encore mort, et il ne disparaîtra pas tout de suite avec l’arrivée de Wayland, donc il reste encore beaucoup de raisons d’espérer et il est beaucoup trop tôt pour crier à la fin du monde. À titre personnel, j’aurais quand-même souhaité que la route vers le tout Wayland soit moins sinueuse pour les gestionnaires de fenêtres alternatifs.
[^] # Re: Une précision
Posté par jyes . En réponse au journal Ubuntu is dying. Évalué à 3.
Ça l’est d’autant plus. Réduire l’amplitude du pic de consommation journalier est LE défi principal qui limite la percée des énergies renouvelables (autres qu’hydrauliques). (bon, pas que, le gras est sûrement de trop, mais quand-même, c’est important et ça touche aussi d’autres problématiques énergétiques)
[^] # Re: introspection
Posté par jyes . En réponse à la dépêche GNOME 3.14 rebat les cartes. Évalué à 5.
Les commentaires de Riendf transpirent la mauvaise fois, mais pour le coup, le tien aussi n’est que partiellement vrai. Je n’arrive plus à faire tourner Neverwinter Nights depuis quelques temps sur ma Debian. J’obtiens soit des segfault, soit des polygones bizarres qui obstruent complètement la vision dans le jeu (le rendant injouable bien que non planté) selon les pilotes que j’utilise (Nvidia libres ou proprios, et Intel libres).
D’après mes investigations très limitées (le binaire de NwN vient sans source ni symboles de débogage évidemment), je suppose que cela provient d’un bug dans NwN mis en lumière par certains pilotes graphiques et certaines options de compilation “hardened” de bibliothèques. Je ne blâmerai donc pas tout de suite mon système, mais plutôt le développement arrêté de ce jeu. Pour autant, il ne tourne pas facilement sous Linux non plus (et c’est peut-être le même bug qui le fait planter avec un Windows récent).
[^] # Re: mouais
Posté par jyes . En réponse au journal [BOOKMARK] Google Ara, smartphones modulaires. Évalué à 3.
Oui, mais tu ne changes pas tout d’un coup, et quand tu rachètes ton nouvel écran (et donc la structure, si tu choisis une taille différente), tu peux garder la puce 4G, le GPS et le stockage interne de ton précédent téléphone.
Parce-que le processeur qui devient lent, l’écran trop petit, l’accès au réseaux mobiles plus modernes poussent déjà à changer de téléphone régulièrement, sauf qu’aujourd’hui on rachète 1 tout à chaque fois dès qu’un seul des composants paraît dépassé.
ou on le récupère d’un plus consommateur que nous, mais on change quand-même tout le téléphone. ↩
[^] # Re: OpenBSD
Posté par jyes . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 4.
Ce que tu écris est vrai, sauf la conclusion, parce-que
ça fait quand-même un gros « si ». Un chroot réduit quand-même considérablement la surface d’attaque, parce-que trouver une faille dans un programme c’est une chose, mais l’exploiter ensuite pour trouver une faille dans le système qui permet de passer « root », ça fait une grosse marche supplémentaire. Et ça ce jeu là, on pourrait rajouter, exploiter une faille qui fait planter SELinux pour le même prix parce-que tous les mécanismes de contrôle contiennent des bugs, ça reste des logiciels.
Donc chroot n’est pas la panacée, il faut savoir ce de quoi ça protège, mais c’est loin d’être nul comme en apport en matière de sécurité.
[^] # Re: lecture oui, écriture non
Posté par jyes . En réponse au journal int *(*(*foo[])(int))(float*);. Évalué à 1. Dernière modification le 15 septembre 2014 à 09:09.
C’est encore plus flagrant en Fortran, qui ne propose rien de plus que le C à ce niveau, mais dont la syntaxe cache le passage de pointeur. On a bien des fonctions d’ordre supérieur sans fermeture.
La limitation par rapport aux fonctions citoyens de première classe est que, pour le C ou le Fortran, l’appel à la fonction qui utilise une autre fonction en paramètre n’est valide que tant que son paramètre est défini (on ne quitte pas la portée de sa définition).
Edit: dans la mesure ou l’étoile n’est même pas nécessaire en C, le Fortran ne change rien, le passage de pointeur est discret en C aussi.
[^] # Re: prix en Europe et aux USA
Posté par jyes . En réponse au journal Et comme prévu, ça a fait... pffffuit. Évalué à 10.
Il est en Suisse.
[^] # Re: troll velu avec systemd
Posté par jyes . En réponse au journal Sur systemd, btrfs & co. Évalué à 7.
Sauf que toutes les boîtes à outils graphiques, à de rares (et vieilles) exceptions près, n’utilisent plus les commandes vectorielles de X.org mais dessinent et envoient directement leur rendu sous forme matricielle.
[^] # Re: Heureusement, il y a des solutions
Posté par jyes . En réponse au journal Dominique Loiselet, Blue Coat : « généraliser le HTTPS va rendre la sécurité aveugle ». Évalué à 6. Dernière modification le 02 septembre 2014 à 15:31.
Et au final, comme ça ennuie tout le monde, on fourre tout sur le port 80 par facilité, et on se retrouve avec une version de TCP/IP à un seul port par adresse sur Internet.
[^] # Re: Wahou
Posté par jyes . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 9.
Je ne vois pas la révolution, ni le pavé dans la marre, par rapport à 0install qui n’a jamais vraiment décollé. Ça utilise systemd et BTRFS donc c’est forcément mieux, mais à part ça ?
[^] # Re: Pourquoi ne pas prendre une "rolling release" comme ArchLinux
Posté par jyes . En réponse au journal OpenMandriva Lx 2014, sortie presque inaperçu… . Évalué à 3.
Pour l’expérimental, la branche correspondante de Debian c’est plutôt « experimental ». Ensuite, ce que tu décris ressemble plus à Sid (« unstable ») que « testing », mais ton commentaire reste vrai : « testing » n’est pas une rolling release au sens de Gentoo (mais pour Arch, ça se discute :-) ).
[^] # Re: Manque de comparaison
Posté par jyes . En réponse au journal Cairo Dock pour Wayland. Évalué à 2.
Raison de plus pour remettre les onglets côté gestionnaire de fenêtre :-) Quoiqu’en fait tes exemples sont particuliers, si ces programmes gèrent les onglets alors que le gestionnaire de fenêtres ne le fait pas c’est parce-qu’ils en ont un usage avancé, et proposent donc autour de ces onglets des ergonomies spécifiques qui restent utiles même avec un gestionnaire de fenêtre qui gère aussi des onglets.
Par contre, pour associer la fenêtre de mon gestionnaire de fichiers ouvert dans mon dossier de téléchargements à ma fenêtre de firefox, ou celle d’un terminal avec celle de VI et celle de ma visionneuse PDf quand je rédige en LateX, là il faut que le gestionnaire de fenêtre connaisse les onglets, et qu’il puisse les dessiner. Ce que fait par exemple Fluxbox, mais n’est pas possible à implémenter en l’état avec Wayland et est déjà complètement affreux avec les logiciels Gnome 3.
[^] # Re: Manque de comparaison
Posté par jyes . En réponse au journal Cairo Dock pour Wayland. Évalué à 5. Dernière modification le 24 juin 2014 à 13:46.
En jouant sur les différents thèmes, on arrive souvent à accorder les différents toolkits graphiques (certains, comme Qt, y mettent vraiment du leur et peuvent utiliser les thèmes d’autres toolkits, d’autres nécessitent un peu de bricolage jusqu’au .Xresources). Mais à la limite la couleur des dégradés et de la sélection du texte on s’en fout pas mal. Le vrai problème des décorations côté client c’est la perte en fonctionnalités : quid des gestionnaires de fenêtres pavant ? des onglets ?
Si Kwin suit la voie des décorations côté gestionnaire de fenêtre, c’est parce-que c’est le seul généraliste à implémenter des fonctions avancées. À l’inverse, les programmes Gnome actuels sont dégueulasses dans Fluxbox, ils dessinent eux-mêmes leur transparence et leur ombre, sans se soucier des réglages du compositeur.
[^] # Re: ID
Posté par jyes . En réponse à la dépêche Rakoshare, un outil de synchronisation de dossiers pour tout le monde. Évalué à 3.
Dans ce cas autant partager un fichier chiffré avec GPG. Toute le monde peut alors transporter les données (aider à le faire transiter) mais seuls ses destinataires peuvent le déchiffrer. Bien sûr, on peut vouloir intégrer ça de façon plus couplée avec le protocole de partage pour gérer des droits ou du versionnement, mais dans ce cas l’approche de l’auteur me semble plus pertinente que je système de clefs asymétriques.
[^] # Re: Comment c’est possible ?
Posté par jyes . En réponse au journal [bookmark] 30 ans de X. Évalué à 2.
Espérons que des solutions standardisées émergeront. Je ne sais pas comment les logiciels KDE vont négocier ça avec Kwin, mais il y a de fortes chances que ça devienne le standard de fait. Espérons alors que les autres logiciels hors de KDE suivront. Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.
[^] # Re: je suis curieux
Posté par jyes . En réponse au journal Unicode 7.0 is out. Évalué à 4.
Avec Gnome, il y a Gucharmap qui permet de faire des recherches hors ligne sur le descriptif des symboles Unicode et de regarder leur représentation dans différentes polices de caractères. Pour le moment, il n’inclut pas encore Unicode 7.0 il me semble, mais ce n’est qu’une question de temps.
[^] # Re: Segmentation et dé-segmentation dans le développement mobile
Posté par jyes . En réponse au journal Apple annonce Swift, son nouveau langage de programmation. Évalué à 7.
Shippeur, arrête de shipper.
[^] # Re: Pourquoi je ne chiffre jamais mes courriels
Posté par jyes . En réponse au sondage Chiffrez/signez-vous vos courriels?. Évalué à 2. Dernière modification le 20 mai 2014 à 14:48.
Je réagissais surtout à
C’est évident que l’une des prémisses au chiffrement est de savoir à qui l’on destine son message.
Ensuite, pour une liste, il est sûrement plus pratique de partager un secret (qui peut toujours être une clé privée commune pour la liste, transmise une seule fois à chaque participant avec sa clé publique à lui, ce n’est pas une limitation de la crypto ou de PGP en soi).
[^] # Re: Pourquoi je ne chiffre jamais mes courriels
Posté par jyes . En réponse au sondage Chiffrez/signez-vous vos courriels?. Évalué à 8.
C’est un fait, le chiffrement fonctionne mal pour les informations diffusées publiquement. Ses critiques souligneront que c’est fort dommage car ça ne permet pas de s’assurer que seul un destinataire inconnu parviendra à lire le message. Étonnant, non ?
[^] # Re: Solution alternative
Posté par jyes . En réponse au journal OpenJDK JEP 180: HashMap, collisions & attaques par la complexité. Évalué à 10.
Tu as lu le journal avant de commenter ?
[^] # Re: Capture d'ecran sous linux ?
Posté par jyes . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 4.
C’est à mon avis nécessaire. Au delà de mon avis plus que réservé sur les décorations côté client, la richesse des environnement de bureaux dépasse largement Gnome et KDE. Les gestionnaires de fenêtres pavant, ou le groupement de fenêtres en onglets auront toujours des utilisateurs après le passage à Wayland… si les applications ne supportent pas un mode de décoration par le gestionnaire, la vie de ces utilisateurs sera bien moins belle quand « Linux sera prêt pour le desktop ».
[^] # Re: If it works, don't fix it.
Posté par jyes . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 6.
Les problèmes avec autofs, ou le boot sur partition chiffrée, etc me font penser que systemd n’est pas non plus un stradivarius. Personnellement, je pense que systemd est une piste intéressante, et sûrement le futur, mais il arrive beaucoup trop vite dans les distributions et est présenté par ses auteurs et défenseurs comme une solution qui surpasse toutes les précédentes, alors qu’il ne tient pas encore toutes ses promesses.
# Sécurité (installation)
Posté par jyes . En réponse au sondage Quels sont les critères de choix pour adopter un logiciel libre pour un non informaticien ?. Évalué à 2.
Je n’ai pas répondu « sécurité » au sondage car il y est explicitement fait référence à la réactivité. Cela me parait un bon argument, mais à destination des connaisseurs, et pas du tout du grand public non-informaticien. Par contre, dans mon entourage non informaticien, j’en trouve un certain nombre qui privilégient des logiciels libres par qu’il est en général plus facile de les trouver via des canaux « fiables ». Par fiable je n’entend pas ici un dépot et des paquets signés (ceux qui y seraient sensibles auraient déjà quitté Windows), mais pour les utilisateurs de Windows, au moins des installateurs qui ne pourrissent pas le système de logiciels tiers aux fonctionnalités pas très claires et de barres de recherche ou autres windowseries courantes.
Ce n’est pas vraiment un avantage inhérent au libre, mais les usages font que l’on trouve plus facilement des installateurs pour Windows propres pour des logiciels libres, sur les sites officiels des projets (et non sur télécharge-un-logiciel-gratuit-fourni-par-jenesaisqui.com). Je sais aussi combien cette habitude majoritaire n’est pas une règle absolue, Sourceforge ayant basculé du côte obscur maintenant, les mauvaises habitudes se répandent.
[^] # Re: Alternatives ?
Posté par jyes . En réponse au journal Condoleezza Rice nommée au conseil de direction de Dropbox. Évalué à 5.
Donc, tu cherches une alternative à Dropbox, qui ne soit pas dépendante du cloud (en utilisant la définition qui transparaît de ton commentaire : à savoir un service hébergé, joignable par le réseau Internet) ? Effectivement, toute alternative qui te sera proposée risque de te décevoir.
[^] # Re: Debian stable wheezy à jour mais version 1.0.1e
Posté par jyes . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.
"deb7u6" = Debian 7 (Wheezy) update 6.
Les mises à jour 5 et 6 (deb7u5, deb7u6) de l’équipe de sécurité servent justement à corriger la faille Heartbleed (cf. l’autre réponse de Xavier Claude pour le vérifier).