Ce qu'il faut prendre en compte, c'est que généralement le destinataire a un antispam derrière la vérification SPF. Le SPF va influer sur le score qu'il lui donne. Souvent, si il y a un champ SPF et que l'adresse est explicitement autorisée, le mail a un meilleur score sur l'antispam.
Si tu mets 'v=spf1 mx -all', ce qui sera envoyé par le MX sera autorisé, le reste sera directement rejeté.
Si tu mets 'v=spf1 mx +all' ou 'v=spf1 +all', ça ne sert pas à grand chose effectivement
Si tu mets 'v=spf1 mx ~all', ce qui n'est pas envoyé par le MX sera accepté, mais avec un moindre score sur l'antispam. Typiquement, il risque de se retrouver dans le dossier spams.
Si tu mets 'v=spf1 mx ?all', ce qui n'est pas envoyé par le MX sera vu comme neutre, on ne lui augmente pas son score mais on ne le diminue pas non plus.
EDIT : quand je parle de « meilleur score », je veux dire qu'il ne sera pas vu comme du spam (les antispams fonctionnent en général dans l'autre sens : plus le score est elevé, plus le mail est vu comme spam).
Si je comprends bien ton script, il prend comme argument le fichier Makefile.
L'exercice dit « Votre commande admettra un argument, le nom de la cible à atteindre », donc pas le Makefile mais la cible ($APRES dans ton script)
Personnellement, $DEPENDANCES et $CIBLE me parlent plus que $AVANT et $APRES.
Ça n'empêchera pas que si un user peut monter n'importe quel volume, si le volume contient des exécutables suid root, il pourra les lancer avec les droits root.
Je vois plutôt d'un côté le principe « un programme pour une tache » contre de l'autre côté une bonne intégration.
Par exemple, j'ai un screen avec un mutt, un vim et un irssi. Je pourrais avoir aussi simplement un emacs qui ferait la même chose.
Dans le premier cas, j'ai bien un programme pour une tache, mais ils ne sont pas bien intégrés ensemble. En revanche, si je préfère weechat à irssi, ou tmux à screen, je peux le remplacer et garder le reste comme tel.
Dans le second cas, si je n'aime pas comment emacs gère l'IRC ben je ne peux pas le changer sans perdre cette intégration, mais j'ai une meilleure intégration du tout, avec mêmes couleurs et mêmes raccourcis claviers sans avoir à bidouiller les confs de X softs.
On peut facilement faire un parrallèle avec d'un côté SysV+scripts+monit+inetd+cron et de l'autre Systemd. Le premier permet de remplacer n'importe qu'elle brique par une que l'on préfère, le second permet d'avoir un tout mieux intégré, avec une configuration homogène.
Personnellement, je suis plutôt « un programme pour une tâche », mais je dois reconnaitre que le deuxième choix est très appréciable aussi. Alors, pour arriver à mettre tout le monde d'accord là-dessus…
Posté par kna .
En réponse au message [Réseau] - Intérêt d'une DMZ ?.
Évalué à 4.
Dernière modification le 23 novembre 2014 à 20:36.
Pas forcément, tu peux avoir une DMZ avec un seul pare-feu, mais 2 interfaces.
Le cas que tu décris est :
+----------+ +----------+
Internet ---- | Firewall |--- DMZ ---| Firewall |--- Réseau local
+----------+ +----------+
Mais tu peux avoir :
+----------+
Internet ---| Firewall |--- DMZ
+----------+
|
|
|
Réseau local
Le pare-feu a simplement des règles différentes pour les deux interfaces, il sera plus permissif pour l'interface reliée à la DMZ et bloquera tout ce qui rentre sur l'interface relié au réseau local, que ça vienne de l'extérieur ou de la DMZ.
EDIT : je ne dis pas que c'est ce que font les machinbox. Je n'en sais rien là.
Les sauvegardes peuvent être automatisée via un script cron.
… en montant un deuxième serveur pour ça. Pour bien faire, chez un hébergeur.
Blague mise à part, il faut monitorer aussi, hein ? Parce que c'est pas plaisant de t'apercevoir que tes backups ne sont plus fonctionnels au moment où tu as besoin d'en restaurer un.
L'utilisateur a bien sûr la possibilité de choisir les versions des applications qu'il souhaite (ce serait géré par un programme spécifique de la distribution). Soit la version stable, soit la version récente. Par défaut, la version récente par exemple.
C'est là qu'il y aura un peu de boulot, il faudra aussi gérer les lanceurs qui fassent automatiquement chroot /chemin/vers/sid /chemin/vers/appli.
Une autre solution, qui donnerait plus de boulot pour le mainteneur, mais rien à dev, serait de faire un dépôt backport avec les applis (on peut s'appuyer sur les paquets source de sid), en gardant les libs et la base du système du dépôt stable. On met une haute priorité à ce dépôt. L'utilisateur avancé peut même décider d'utiliser une version stable d'une appli particulière en faisant du pinning.
En même temps, si on « musèle » les petits partis, c'est logique qu'ils fassent du populisme pour attirer les gens ; et ceux qui voudraient vraiment faire bouger les choses, ils ont encore moins de chance de percer.
Franchement, si tu fais une migration de ce type sans avoir fait aucun test avant, tu es quand même un sacré boulet.
Mais en pratique, effectivement tu n'auras pas pu tester à 100% que tout est OK, et tu vas avoir des soucis à gérer post-migration ; parce que pour raison historique tu n'as pas des configs homogènes à la base ; parce que tu n'en as pas un inventaire complet, parce que tes utilisateurs vont t'avoir dit que c'est OK, mais te remonter tout de même des problème post-migration, parce qu'on est des humains et parfois on oublie des choses, parce que le truc marche bien en test, mais s'effondre passé X utilisateurs.
Moi, j'utilse les bangs de duckduckgo, parce que je suis une grosse feignasse et que comme ça j'ai qu'un seul moteur de recherche à configurer dans mon brouteur.
Selon la distribution, il peut ne pas être dans les dépôts. Mais il y a tmpwatch qui est équivalent.
Sinon, un bon vieux find des familles fait le boulot aussi.
Quand je l'ai passé (en 2000), c'était autorisé dans les matières scientifiques. Plutôt ça dépendait du sujet : on savait au début de l'épreuve si c'était autorisé ou non (mais généralement c'était utilisé en maths, physique, rarement en bio).
Quand j'étais à la fac, c'était interdit à la demande d'étudiants qui se trouvaient désavantagés par rapport à ceux qui pouvaient se payer une calculatrice à 500F (ils n'avaient pas de téléphones à 1000EUR à l'époque).
Ça m'arrangeait, 500F c'était effectivement trop pour que j'annonce à mes parents que j'avais briqué ma TI-89 :)
J'ai déjà vu des scripts utilisant [ x$1 = x ] (sans les guillemets)
J'avais trouvé comme explication : si tu mets comme test [ $1 = "" ], le test va échouer si $1 est vide (après interprétation par le shell, le test va lire [ = "" ], ce qui ne veut rien dire)
Du coup certains contournaient le problème en mettant [ x$1 = x ]. Mais [ "$1" = "" ] ou [ -z $1 ] fonctionnent très bien (et tu peux même mettre [ -z "$1" ] si tu as peur).
C'est un peu lié : à l'installation/upgrade du paquet :
- le démon est activé
- le démon est lancé
Faire un seul des deux serait bizarre (dans un cas, le démon ne serait pas lancé, mais le serait au prochain boot ; dans l'autre il serait lancé, mais ne serait pas relancé au prochain boot). Mais personnellement, je préfère qu'il ne fasse aucun des deux.
À l'époque, sur debian, la solution pour désactiver un service de façon permanente était de trouver un /etc/default/ qui contenait une variable qui était lu par le script init. Si la variable était sur « disabled » par exemple, le script init ne lançait pas le démon, même s'il était actif.
Je ne sais pas si c'est toujours le cas sur les debian récentes mais pré-systemd. Ni comment ça se passe avec systemd…
Il n'y a pas que les scripts dans la vie. Pour l'utilisation en ligne de commande intéractive, Powershell est plus adapté que Python ou Ruby (malgré ses commandes à rallonge).
Si le mainteneur se retrouve à se battre avec des outils complexe pour créer un paquet, suivre toutes les règles pour que son paquet soit accepté ; pour l'utilisateur en contrepartie, il est assuré d'avoir un paquet bien intégré comme il faut à la distrib, avec tout ce qu'il attend d'un tel paquet. Il n'as pas un truc qui juste marche mais est empaqueté comme un goret avec des fichiers se retrouvant à des endroits improbables ou un paquet sans page man.
Tu vois CentOS, mais moi j'ai dis que je voyais pas ArchLinux, ma distribution de prédilection…
Si ton hébergeur te fournit un système de rescue (il y en a qui ne le font pas ?), t'auras un système live accessible en SSH. Tu pourras monter tes partitions et y installer ce que tu veux, ce qui dans le cas d'Archlinux est la méthode d'install de base.
Comparer des ports a des paquets précompilés est un peu biaisé comme comparaison, mais je pense que tu as tout de même raison : c'est compliqué de faire un paquet debian.
On peut aussi garder PAGER="less", et mettre les options dans la variable LESS (par exemple : LESS="-R").
Pour les couleurs, il y a les variables LESS_TERMCAP_*, pour ma part je m'étais contenté de pomper un exemple sur le net, pour avoir des manpages en couleur :
export LESS_TERMCAP_mb=$'\E[01;37m'
export LESS_TERMCAP_md=$'\E[01;37m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_so=$'\E[40;36m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_us=$'\E[36m'
export LESS_TERMCAP_ue=$'\E[0m'
Oui, du coup ça te garantie quand même qu'il y a un driver qui fonctionne sous Linux. Selon la distrib que tu choisis, il faudra peut-être te battre un peu pour l'avoir (firmware, kernel trop vieux), mais tu sais que tu pourras faire fonctionner ton matos.
Marrant, la première fois que j'ai installé Linux, j'ai trouvé ça vraiment hardu et incomplet, mais c'était à une époque lointaine (une Mandrake6, je crois).
J'ai réessayé il y a, ooh, 8 ans déjà, et j'ai été bluffé par l'évolution ! En parrallèle, entre Windows98 et XP, il y avait eu très peu de changements (les seuls trucs que j'ai apprécié ont été l'apparition de… firefox et vlc!).
Et à cette époque, on pouvait déjà installer libdvdcss en faisant clic-clic dans synaptic. Après, il est clair que sur les forums on donne souvent une solution CLI, qui est plus générique.
Finalement, j'ai abandonné windows, d'une part parce qu'avec le temps j'ai commencé à apprécier les trucs de barbus qui, une fois que tu as passé l'étape de l'apprentissage, s'avèrent redoutables d'efficacité, d'autre part parce que je trouve le gestionnaire de fenêtres de windows beaucoup trop archaïque en comparaison de tous ceux que j'ai testé ; mais aussi parce que « out-the-box », je ne peux rien faire avec Windows, pour le moindre truc il faut télécharger un utilitaire obscur livré avec 2 virus et 3 toolbars.
Tout n'est pas parfait sous Linux, loin de là. Mais pour un système beaucoup plus jeune, à l'origine fait par les geeks pour eux-même, ça évolue tout de même pas trop mal.
# c'est pas très compliqué en fait
Posté par kna . En réponse au message SPF : autoriser l'envoi par un autre SMTP. Évalué à 2. Dernière modification le 05 décembre 2014 à 20:15.
Ce qu'il faut prendre en compte, c'est que généralement le destinataire a un antispam derrière la vérification SPF. Le SPF va influer sur le score qu'il lui donne. Souvent, si il y a un champ SPF et que l'adresse est explicitement autorisée, le mail a un meilleur score sur l'antispam.
La doc openspf dit :
Si tu mets 'v=spf1 mx -all', ce qui sera envoyé par le MX sera autorisé, le reste sera directement rejeté.
Si tu mets 'v=spf1 mx +all' ou 'v=spf1 +all', ça ne sert pas à grand chose effectivement
Si tu mets 'v=spf1 mx ~all', ce qui n'est pas envoyé par le MX sera accepté, mais avec un moindre score sur l'antispam. Typiquement, il risque de se retrouver dans le dossier spams.
Si tu mets 'v=spf1 mx ?all', ce qui n'est pas envoyé par le MX sera vu comme neutre, on ne lui augmente pas son score mais on ne le diminue pas non plus.
EDIT : quand je parle de « meilleur score », je veux dire qu'il ne sera pas vu comme du spam (les antispams fonctionnent en général dans l'autre sens : plus le score est elevé, plus le mail est vu comme spam).
# $1 != Makefile
Posté par kna . En réponse au message Faire un script reproduisant une commande. Évalué à 2.
Si je comprends bien ton script, il prend comme argument le fichier Makefile.
L'exercice dit « Votre commande admettra un argument, le nom de la cible à atteindre », donc pas le Makefile mais la cible ($APRES dans ton script)
Personnellement, $DEPENDANCES et $CIBLE me parlent plus que $AVANT et $APRES.
[^] # Re: Sécurité
Posté par kna . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 1.
Ça n'empêchera pas que si un user peut monter n'importe quel volume, si le volume contient des exécutables suid root, il pourra les lancer avec les droits root.
[^] # Re: Sécurité
Posté par kna . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 2.
Moui, enfin là on parle d'un montage qui n'est pas dans fstab, sinon il y a l'option user aussi
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par kna . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
Je vois plutôt d'un côté le principe « un programme pour une tache » contre de l'autre côté une bonne intégration.
Par exemple, j'ai un screen avec un mutt, un vim et un irssi. Je pourrais avoir aussi simplement un emacs qui ferait la même chose.
Dans le premier cas, j'ai bien un programme pour une tache, mais ils ne sont pas bien intégrés ensemble. En revanche, si je préfère weechat à irssi, ou tmux à screen, je peux le remplacer et garder le reste comme tel.
Dans le second cas, si je n'aime pas comment emacs gère l'IRC ben je ne peux pas le changer sans perdre cette intégration, mais j'ai une meilleure intégration du tout, avec mêmes couleurs et mêmes raccourcis claviers sans avoir à bidouiller les confs de X softs.
On peut facilement faire un parrallèle avec d'un côté SysV+scripts+monit+inetd+cron et de l'autre Systemd. Le premier permet de remplacer n'importe qu'elle brique par une que l'on préfère, le second permet d'avoir un tout mieux intégré, avec une configuration homogène.
Personnellement, je suis plutôt « un programme pour une tâche », mais je dois reconnaitre que le deuxième choix est très appréciable aussi. Alors, pour arriver à mettre tout le monde d'accord là-dessus…
[^] # Re: DMZ = 2 parefeux, pas le cas chez toi
Posté par kna . En réponse au message [Réseau] - Intérêt d'une DMZ ?. Évalué à 4. Dernière modification le 23 novembre 2014 à 20:36.
Pas forcément, tu peux avoir une DMZ avec un seul pare-feu, mais 2 interfaces.
Le cas que tu décris est :
Mais tu peux avoir :
Le pare-feu a simplement des règles différentes pour les deux interfaces, il sera plus permissif pour l'interface reliée à la DMZ et bloquera tout ce qui rentre sur l'interface relié au réseau local, que ça vienne de l'extérieur ou de la DMZ.
EDIT : je ne dis pas que c'est ce que font les machinbox. Je n'en sais rien là.
[^] # Re: Je ne peux que t'encourager à continuer dans cette démarche, c'est ça le vrai "Internet".
Posté par kna . En réponse au journal Mon retour d'expérience sur l'auto-hébergement. Évalué à 2.
… en montant un deuxième serveur pour ça. Pour bien faire, chez un hébergeur.
Blague mise à part, il faut monitorer aussi, hein ? Parce que c'est pas plaisant de t'apercevoir que tes backups ne sont plus fonctionnels au moment où tu as besoin d'en restaurer un.
[^] # Re: Une réalisation simple ?
Posté par kna . En réponse au journal Une idée de distribution Linux. Évalué à 1.
C'est là qu'il y aura un peu de boulot, il faudra aussi gérer les lanceurs qui fassent automatiquement chroot /chemin/vers/sid /chemin/vers/appli.
Une autre solution, qui donnerait plus de boulot pour le mainteneur, mais rien à dev, serait de faire un dépôt backport avec les applis (on peut s'appuyer sur les paquets source de sid), en gardant les libs et la base du système du dépôt stable. On met une haute priorité à ce dépôt. L'utilisateur avancé peut même décider d'utiliser une version stable d'une appli particulière en faisant du pinning.
[^] # Re: Oui, et ?
Posté par kna . En réponse au journal "Comment les multinationales (y compris françaises) font de l’évasion fiscale au Luxembourg". Évalué à 2.
En même temps, si on « musèle » les petits partis, c'est logique qu'ils fassent du populisme pour attirer les gens ; et ceux qui voudraient vraiment faire bouger les choses, ils ont encore moins de chance de percer.
[^] # Re: Not a big deal
Posté par kna . En réponse au journal Libreoffice 4.3 : Bug 81633 du tri : "It's not a bug, it's a feature !". Évalué à 3.
Je ne serait pas aussi binaire que vous.
Franchement, si tu fais une migration de ce type sans avoir fait aucun test avant, tu es quand même un sacré boulet.
Mais en pratique, effectivement tu n'auras pas pu tester à 100% que tout est OK, et tu vas avoir des soucis à gérer post-migration ; parce que pour raison historique tu n'as pas des configs homogènes à la base ; parce que tu n'en as pas un inventaire complet, parce que tes utilisateurs vont t'avoir dit que c'est OK, mais te remonter tout de même des problème post-migration, parce qu'on est des humains et parfois on oublie des choses, parce que le truc marche bien en test, mais s'effondre passé X utilisateurs.
[^] # Re: /tmp, vraiment ?
Posté par kna . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 1.
C'est triste ton avis sur les familles…
# Je suis un salaud !
Posté par kna . En réponse au journal Rechercher au plus juste, ça sauve des bébés morses ! Et toi ?. Évalué à 1.
Moi, j'utilse les bangs de duckduckgo, parce que je suis une grosse feignasse et que comme ça j'ai qu'un seul moteur de recherche à configurer dans mon brouteur.
Les bébés morses ne me remercient pas…
[^] # Re: /tmp, vraiment ?
Posté par kna . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 1.
Selon la distribution, il peut ne pas être dans les dépôts. Mais il y a tmpwatch qui est équivalent.
Sinon, un bon vieux find des familles fait le boulot aussi.
[^] # Re: super soft !
Posté par kna . En réponse à la dépêche Une calculatrice scientifique libre sous Linux (materiel). Évalué à 3.
Quand je l'ai passé (en 2000), c'était autorisé dans les matières scientifiques. Plutôt ça dépendait du sujet : on savait au début de l'épreuve si c'était autorisé ou non (mais généralement c'était utilisé en maths, physique, rarement en bio).
Quand j'étais à la fac, c'était interdit à la demande d'étudiants qui se trouvaient désavantagés par rapport à ceux qui pouvaient se payer une calculatrice à 500F (ils n'avaient pas de téléphones à 1000EUR à l'époque).
Ça m'arrangeait, 500F c'était effectivement trop pour que j'annonce à mes parents que j'avais briqué ma TI-89 :)
[^] # Re: Question de condition (je sais, ce n'est pas le plus important)
Posté par kna . En réponse au journal Scripter la génération de certificat. Évalué à 1.
J'ai déjà vu des scripts utilisant
[ x$1 = x ](sans les guillemets)J'avais trouvé comme explication : si tu mets comme test
[ $1 = "" ], le test va échouer si$1est vide (après interprétation par le shell, le test va lire[ = "" ], ce qui ne veut rien dire)Du coup certains contournaient le problème en mettant
[ x$1 = x ]. Mais[ "$1" = "" ]ou[ -z $1 ]fonctionnent très bien (et tu peux même mettre[ -z "$1" ]si tu as peur).[^] # Re: Doc à jour ?
Posté par kna . En réponse à la dépêche systemd pour les administrateurs, parties 3, 4 et 5. Évalué à 1.
C'est un peu lié : à l'installation/upgrade du paquet :
- le démon est activé
- le démon est lancé
Faire un seul des deux serait bizarre (dans un cas, le démon ne serait pas lancé, mais le serait au prochain boot ; dans l'autre il serait lancé, mais ne serait pas relancé au prochain boot). Mais personnellement, je préfère qu'il ne fasse aucun des deux.
À l'époque, sur debian, la solution pour désactiver un service de façon permanente était de trouver un /etc/default/ qui contenait une variable qui était lu par le script init. Si la variable était sur « disabled » par exemple, le script init ne lançait pas le démon, même s'il était actif.
Je ne sais pas si c'est toujours le cas sur les debian récentes mais pré-systemd. Ni comment ça se passe avec systemd…
[^] # Re: Presque d'accord ...
Posté par kna . En réponse à la dépêche Revue des techniques de programmation en shell. Évalué à 0.
Il n'y a pas que les scripts dans la vie. Pour l'utilisation en ligne de commande intéractive, Powershell est plus adapté que Python ou Ruby (malgré ses commandes à rallonge).
[^] # Re: End of an era
Posté par kna . En réponse au journal Et comme prévu, ça a fait... pffffuit. Évalué à 2.
Les vrais informaticiens™ verrouillent leur session, et on un mot de passe fort, donc difficile à taper à l'aveugle.
[^] # Re: Point par point
Posté par kna . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 3.
et pour savoir quoi mettre dans ton PKGBUILD, tu télécharges les sources pour lire le README…
[^] # Re: Résumons
Posté par kna . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 2.
Si le mainteneur se retrouve à se battre avec des outils complexe pour créer un paquet, suivre toutes les règles pour que son paquet soit accepté ; pour l'utilisateur en contrepartie, il est assuré d'avoir un paquet bien intégré comme il faut à la distrib, avec tout ce qu'il attend d'un tel paquet. Il n'as pas un truc qui juste marche mais est empaqueté comme un goret avec des fichiers se retrouvant à des endroits improbables ou un paquet sans page man.
[^] # Re: Mauvais exemple
Posté par kna . En réponse au message Auto hébergement et consommation électrique. Évalué à 2.
Si ton hébergeur te fournit un système de rescue (il y en a qui ne le font pas ?), t'auras un système live accessible en SSH. Tu pourras monter tes partitions et y installer ce que tu veux, ce qui dans le cas d'Archlinux est la méthode d'install de base.
# c'est pour qui le paquet ?
Posté par kna . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 10.
Comparer des ports a des paquets précompilés est un peu biaisé comme comparaison, mais je pense que tu as tout de même raison : c'est compliqué de faire un paquet debian.
Du moins, c'est compliqué de faire intégrer un paquet dans debian. Parce que si tu veux juste faire un paquet pour toi, tu peux utiliser dpkg-deb : http://alp.developpez.com/tutoriels/debian/creer-paquet/
[^] # Re: troff | less
Posté par kna . En réponse au journal Troff, l'enthousiasme. Évalué à 2.
On peut aussi garder PAGER="less", et mettre les options dans la variable LESS (par exemple : LESS="-R").
Pour les couleurs, il y a les variables LESS_TERMCAP_*, pour ma part je m'étais contenté de pomper un exemple sur le net, pour avoir des manpages en couleur :
export LESS_TERMCAP_mb=$'\E[01;37m'
export LESS_TERMCAP_md=$'\E[01;37m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_so=$'\E[40;36m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_us=$'\E[36m'
export LESS_TERMCAP_ue=$'\E[0m'
[^] # Re: LinuxBooks
Posté par kna . En réponse au journal Retour d'expérience Achat Portable Clevo. Évalué à 4.
Oui, du coup ça te garantie quand même qu'il y a un driver qui fonctionne sous Linux. Selon la distrib que tu choisis, il faudra peut-être te battre un peu pour l'avoir (firmware, kernel trop vieux), mais tu sais que tu pourras faire fonctionner ton matos.
[^] # Re: Linux est-il prêt pour le desktop ? Je passe le prendre à quelle heure ?
Posté par kna . En réponse au journal C'est vendredi, c'est trolldi, c'est permis : l'open source n'est pas secure. Évalué à 2.
Marrant, la première fois que j'ai installé Linux, j'ai trouvé ça vraiment hardu et incomplet, mais c'était à une époque lointaine (une Mandrake6, je crois).
J'ai réessayé il y a, ooh, 8 ans déjà, et j'ai été bluffé par l'évolution ! En parrallèle, entre Windows98 et XP, il y avait eu très peu de changements (les seuls trucs que j'ai apprécié ont été l'apparition de… firefox et vlc!).
Et à cette époque, on pouvait déjà installer libdvdcss en faisant clic-clic dans synaptic. Après, il est clair que sur les forums on donne souvent une solution CLI, qui est plus générique.
Finalement, j'ai abandonné windows, d'une part parce qu'avec le temps j'ai commencé à apprécier les trucs de barbus qui, une fois que tu as passé l'étape de l'apprentissage, s'avèrent redoutables d'efficacité, d'autre part parce que je trouve le gestionnaire de fenêtres de windows beaucoup trop archaïque en comparaison de tous ceux que j'ai testé ; mais aussi parce que « out-the-box », je ne peux rien faire avec Windows, pour le moindre truc il faut télécharger un utilitaire obscur livré avec 2 virus et 3 toolbars.
Tout n'est pas parfait sous Linux, loin de là. Mais pour un système beaucoup plus jeune, à l'origine fait par les geeks pour eux-même, ça évolue tout de même pas trop mal.