Et accessoirement, il n'y à pas besoin de connaître le C pour être "informaticien" ou même développeur. Ce n'est rien d'autre qu'un langage comme un autre, ce n'est ni le seul langage ancien, ni le seul langage bas niveau, ni le seul langage compilé, ni le seul langage portable, ni le seul langage que l'on peut utiliser "gratuitement".
Et c'est encore moins le seul langage qui cumule ces qualificatifs.
Moui enfin, d'un autre côté, ça reviens à foutre dans une lib (statique) le code non portable, donc on déplace le problème du fait que le kernel comporte du code qui n'est pas faisable en C standard.
je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.
Contrairement à python pour la psychorigidité? Ou alors le contraire, je trouve le ; de fin moins rigide que la fin d'instruction en \n, parce que ça me permets de formater mon code.
D'ailleurs, si j'ai bonne mémoire, le python à justement été créé pour enseigner, car justement le fait d'imposer un coding style permets de faire sauter à l'œil les bugs… ou pas (en fait si, mais c'est plus compliqué que juste prendre en compte les espaces blancs dans le code source…).
Essayes de les démarrer de la console, tu verras peut-être des messages qui t'indiqueront le problème.
Une autre solution pour choper de l'info, c'est d'utiliser xev (à lancer à partir de la console) et de vérifier en cliquant sur la fenêtre de ton choix et en faisant le raccourcis clavier qui va bien, que tout est ok. Attention, xev est verbeux, très verbeux.
Utiliser des extensions dans du code kernel ça ne me choque pas, dans du code applicatif c’est déjà plus discutable.
L'arrivée de clang à permis d'en nettoyer une partie… et d'implémenter dans clang une partie des extensions gnu. Malgré tout ça, il y à encore pas mal de paquets qui ne compilent pas, au moins sous Debian, avec clang (5.7% aux dernières news).
Et sinon, je me demande quelle est la proportion moyenne des kernels *BSD qui n'est pas écrite en C standard? Quelqu'un aurait une info la dessus? (après tout, il s'agit des seuls kernels libres capables d'être utilisés au quotidien sur un bureau que je connaisse, en plus de linux, et donc les seuls dont les stats soient d'une certaine pertinence?)
Depuis quelques temps, j'ai réussi à choper des écrans pour peupler ma 2nde carte graphique (du bas de gamme, que j'avais soupçonné à tord d'être HS, et que je conservais donc, au cas ou).
Elles sont équipées de chipset NVidia (donc si on veut se retreindre au LL, faut se coltiner nouveau et son absence d'accélération matérielle pour la 3D).
Il m'est pour le moment impossible de faire reconnaître par i3 les écrans placés sur la 2nde carte graphique, et ce, même avec le pilote propriétaire (à noter qu'il s'agit d'une seconde instance de Xorg je pense) mais ils s'allument bien.
J'ai fait quelques expérimentations contre ma volonté avec Ubutun, et je me suis aperçu que ça fonctionne, en fonction du DE utilisé: gnome ou unity sont les seuls qui prennent en charge aisément une seconde carte graphique. Pourquoi, je n'en ai aucune fichue idée, honnêtement.
Autre point "amusant", sous Debian stable, xrandr ne repère même pas la 2nde carte, tandis que sous Ubuntu (la dernière mouture en date, me semble), selon le DE, il voit (gnome/unity), ou pas(xfce,kde,lxde), les écrans.
PS: squeeze est la old-stable (certes encore maintenue car promue au rang de LTS), pour rappel. Sauf raison précise, tu devrais peut-être songer à upgrader, quitte à faire une machine virtuelle (XEN par exemple) avec squeeze. Enfin bon, tu fais comme tu le sens.
PPS: quand je parle des DE d'Ubuntu, j'ai installé les différentes variantes séparément, il est très probable qu'il y ait une différence de paquets installés au delà du DE, mais vu le bordel que c'est dans cette distro, je n'ose creuser… près de 2000 paquets installés par défaut, ça me fait mal au cœur, surtout que les flags d'installation automatique ne sont pas placés correctement, voire pas du tout!
Et comme pour compiler linux il faut GCC, ça supporte GNU/Linux? (je sais, c'est moyen, mais je me souviens qu'on m'avait répondu ça, un jour, je ne sais plus où…)
c'est quand même parce qu'un compilateur C bien configuré
Admettons. Et pour le cast vers et depuis du void*, tu rétorques quoi? (casts qui sont obligatoires dès lors que l'on veut interagir avec une lib dynamique au runtime, et non au démarrage de l'appli, pour rappel, à moins qu'il existe autre chose que dlsym?)
Franchement, j'aimerai beaucoup qu'il y ait plus sécurité au niveau des casts en C. Parce que dans les langages qui ont des capacités de plus haut niveau, on subit cette faiblesse quand on doit utiliser une lib codée en C, pour une raison X ou Y (j'ai pris l'exemple de dlfcn.h ici, mais ce n'est qu'un exemple, hein, ça pourrait être une lib maison qu'il est obligé d'utiliser, peu importe.).
mais reinterpret_cast ou static_cast ne sont pas non plus la panacée.
Comme je l'ai dis. D'ailleurs le reinterpret_cast est l'égal du transtypage du C, à un très gros avantage près: il est super long à taper (sauf avec une auto-complete potable, mais celle de vim étant ce qu'elle est…)/lire, et du coup, ça décourage :)
Oulah, attention, parce qu'il en existe aussi de vraies grosses, du genre que quand tu poses la main dessus, ton poignet est obligatoirement à 5cm de la table.
Mais bon, je te rejoins: c'est inutilisable, les souris sur lesquelles tu as du mal à poser un doigt sans appuyer sur 2 boutons à la fois…
Je ne sais pas quel brouteur tu utilises mais, dans le mien, à côté de la barre d'URI, il y à une liste déroulante avec cette fameuse liste. Tu sélectionnes un moteur, tu tapes ta recherche, et HOP!
En plus, ça te permets de faire la même recherche d'un moteur à l'autre, simplement en changeant le moteur sélectionné: pas besoin de retaper la recherche, elle n'a pas été effacée…
Vimperator, j'ai essayé vite fait, je ne suis pas convaincu. J'ai aussi utilisé uzbl plus longuement, mais, non, je ne trouve pas cette façon de faire très efficace avec le web.
pentadactyl, connaissais pas par contre, vais tester ça. En espérant ne pas être trop agacé par les choses de FF que je n'apprécie pas.
M'est avis que tu dois sur-estimer les capacités du C toi… le C, c'est quand même le langage dont le typage est tellement sûr, que tu peux transformer l'adresse d'un float en chaîne de caractères ou plus drôle encore, en pointeur de fonction, et le tout, sans warning, même en -Wall -Wextra.
En C++ aussi, c'est vrai, parce que C++ est capable de compiler les horreurs du C, mais si on utilise sagement les améliorations du C++, à savoir [static|dynamic|reinterpret|const]_cast, on sait au moins quand on est en train de faire une grosse connerietime-bomb section de code très dangereuse: c'est le seul moment ou l'on utilise reinterpret_cast ou const_cast.
Rien que pour ça, le C++ bats le C à plate couture (je me demande d'ailleurs s'il existe des warning pour avertir de la présence casts C-style dans du code C++…).
Il n'y a aucune raison d'aller lire/modifier le code de systemd dans le cas d'une utilisation normale, pas plus que tu vas aller lire/modifier le code C de ton shell pour faire fonctionner un script d'init.
Dans son cas, j'ai l'impression qu'il ne parle pas du source de l'init, mais des modules que l'init utilise. Dans le cas de systemd, ces modules sont écrits en C, donc compilés, donc pas directement modifiables.
Dans le cas de sysV, ils sont écrits en… euhh… ça dépend de la configuration j'imagine (c'est vrai d'abord, je me demande si, quelqu'un d'original ne pourrait pas utiliser un autre langage au final?), mais traditionnellement en shell, qui n'est pas compilé (jusqu'à preuve du contraire), et donc dont le source est accessible.
De là à qualifier le shell de plus lisible que du C, je ne m'aventurerai pas, mais je suis biaisé.
Ma foi, j'aurai plutôt parlé de regex à ta place. Pour comparer des chaînes de caractères c'est assez simple dans tous les langages (bon, certes, il faut appeler explicitement une fonction quand les langages sont pas objets). La ou shell dépote, c'est pour appeler des programmes et filtrer le texte.
Bon, ça va résumer un peu certains commentaires précédents, et je vais ajouter un peu de mon côté au passage:
L’idée qui anime notre projet est de rehausser le niveau de sécurité des emails, POUR TOUS, c’est-à-dire pour le boulanger, l’employée du bureau, la dessinatrice de mode, mon grand-père, mes enfants, les profs…
C'est une vraie raison pour ne pas imposer de technique impliquant aux utilisateurs d'utiliser un système de clé privée/publique (l'utilisateur moyen ne comprendra pas qu'il faut se trimballer une clé et se souvenir d'une passphrase). En revanche, ce n'est pas une bonne raison pour bloquer cette possibilité.
Par rapport à l'envoi de mot de passe (je n'ai pas regardé les sources, je me base sur les commentaires précédents) via le net, l'alternative serait de déporter la mécanique de protection côté client, via du JS (je dis ça, alors qu'en général j'ai tendance à bloquer le JS… allez comprendre!).
Bon, je suis vraiment pas très bon en sécurité, alors je me plante peut-être, ce n'est peut-être pas faisable proprement.
Ce type d’offre manquait cruellement en France…
C'est vrai, l'existant est délicat à trouver, en général ce sont de petites associations. Mais il en existe. Ceci étant dit, une plus grosse structure, qui ait pour objectif de grossir et non de faire des boutures n'est pas une mauvaise chose.
à condition toutefois que leur contribution aille au-delà du sarcasme (du français dans le code ! quelle horreur… du français ! ;-)
Ce n'est pas uniquement sarcastique (mais il faut être habitué à linuxfr il est vrai, pour comprendre entre les lignes), c'est surtout que le code source pointé (chaine.c) révèle plusieurs problèmes:
le fait de réinventer la roue (string_ajout, au nom, je dirait que ça réimplémente strcat… p'tet strncat éventuellement, voire pire… std::string::operator+= ).
Et, oui, le fait que le code soit en français EST un problème dans le monde du libre. Du code franchouillard, c'est illisible pour un non-francophone, et difficile à lire pour un dev rôdé à coder en anglais… qui sont, amha, majoritaires dans le libre.
Enfin, pour en finir au sujet de ce fichier que j'ai lu très vite, et revenir à ma remarque sur std::string::operator+=, pourquoi utiliser le C si c'est pour réimplémenter CFront, limite? Autant utiliser C++ en interdisant les features qui vous gênent (ça se fait très bien à la compil, de virer les exceptions et la RTTI, et quand aux méthodes virtuelles et autres héritages, des règles de codages claires ainsi qu'un ou deux scripts hookés dans le .git peuvent empêcher l'introduction accidentelle. Le C++ n'est pas un langage objet, mais juste orienté objet… c'est un choix du dev qui l'utilise, et si on utilise pas, on paye pas.)
Enfin, je dirais que roundcube est… spartiate, dans le meilleur des cas. Peut-être avez-vous activé un module qui permets de gérer des règles de filtrage, car il semble que dans la version que j'utilise habituellement, ça n'existe pas, et c'est un manque des plus pénibles, quand on est abonné à une ou deux mailing lists.
Raté, ce vote n'a pas pour ambition de changer la décision concernant l'init par défaut, mais de s'assurer que Debian ne se fasse pas enfermer par systemd en garantissant le fait qu'un programme doive avoir l'obligation de pouvoir fonctionner, ne serait-ce qu'en mode dégradé, avec un init différent.
Cette obligation ne concernerait évidemment pas les programmes qui ont pour unique rôle celui de gérer le système d'init.
Ce vote ne remets en cause aucune décision, il souhaite simplement préciser de manière claire que Debian supportera les autres systèmes d'init, dans le temps.
Sur le fond, on sent quand même la rage du conservatisme.
Tu vois, dans ton post, je vois plutôt la rage du modernisme…
[^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 9.
Et accessoirement, il n'y à pas besoin de connaître le C pour être "informaticien" ou même développeur. Ce n'est rien d'autre qu'un langage comme un autre, ce n'est ni le seul langage ancien, ni le seul langage bas niveau, ni le seul langage compilé, ni le seul langage portable, ni le seul langage que l'on peut utiliser "gratuitement".
Et c'est encore moins le seul langage qui cumule ces qualificatifs.
[^] # Re: A defaut de GNU, il y a Linux
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 3.
Moui enfin, d'un autre côté, ça reviens à foutre dans une lib (statique) le code non portable, donc on déplace le problème du fait que le kernel comporte du code qui n'est pas faisable en C standard.
[^] # Re: Décalage
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 3.
Contrairement à python pour la psychorigidité? Ou alors le contraire, je trouve le ; de fin moins rigide que la fin d'instruction en \n, parce que ça me permets de formater mon code.
D'ailleurs, si j'ai bonne mémoire, le python à justement été créé pour enseigner, car justement le fait d'imposer un coding style permets de faire sauter à l'œil les bugs… ou pas (en fait si, mais c'est plus compliqué que juste prendre en compte les espaces blancs dans le code source…).
[^] # Re: Dans un navigateur…
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 5.
Windev quoi…
# de la console
Posté par freem . En réponse au message [Résolu] Raccourcis avec les logiciels utilisant qt comme interface graphique. Évalué à 2.
Essayes de les démarrer de la console, tu verras peut-être des messages qui t'indiqueront le problème.
Une autre solution pour choper de l'info, c'est d'utiliser xev (à lancer à partir de la console) et de vérifier en cliquant sur la fenêtre de ton choix et en faisant le raccourcis clavier qui va bien, que tout est ok. Attention, xev est verbeux, très verbeux.
[^] # Re: A defaut de GNU, il y a Linux
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 3.
L'arrivée de clang à permis d'en nettoyer une partie… et d'implémenter dans clang une partie des extensions gnu. Malgré tout ça, il y à encore pas mal de paquets qui ne compilent pas, au moins sous Debian, avec clang (5.7% aux dernières news).
Et sinon, je me demande quelle est la proportion moyenne des kernels *BSD qui n'est pas écrite en C standard? Quelqu'un aurait une info la dessus? (après tout, il s'agit des seuls kernels libres capables d'être utilisés au quotidien sur un bureau que je connaisse, en plus de linux, et donc les seuls dont les stats soient d'une certaine pertinence?)
# bon courage
Posté par freem . En réponse au message quatre ou six ecrans. Évalué à 3.
Depuis quelques temps, j'ai réussi à choper des écrans pour peupler ma 2nde carte graphique (du bas de gamme, que j'avais soupçonné à tord d'être HS, et que je conservais donc, au cas ou).
Elles sont équipées de chipset NVidia (donc si on veut se retreindre au LL, faut se coltiner nouveau et son absence d'accélération matérielle pour la 3D).
Il m'est pour le moment impossible de faire reconnaître par i3 les écrans placés sur la 2nde carte graphique, et ce, même avec le pilote propriétaire (à noter qu'il s'agit d'une seconde instance de Xorg je pense) mais ils s'allument bien.
J'ai fait quelques expérimentations contre ma volonté avec Ubutun, et je me suis aperçu que ça fonctionne, en fonction du DE utilisé: gnome ou unity sont les seuls qui prennent en charge aisément une seconde carte graphique. Pourquoi, je n'en ai aucune fichue idée, honnêtement.
Autre point "amusant", sous Debian stable, xrandr ne repère même pas la 2nde carte, tandis que sous Ubuntu (la dernière mouture en date, me semble), selon le DE, il voit (gnome/unity), ou pas(xfce,kde,lxde), les écrans.
PS: squeeze est la old-stable (certes encore maintenue car promue au rang de LTS), pour rappel. Sauf raison précise, tu devrais peut-être songer à upgrader, quitte à faire une machine virtuelle (XEN par exemple) avec squeeze. Enfin bon, tu fais comme tu le sens.
PPS: quand je parle des DE d'Ubuntu, j'ai installé les différentes variantes séparément, il est très probable qu'il y ait une différence de paquets installés au delà du DE, mais vu le bordel que c'est dans cette distro, je n'ose creuser… près de 2000 paquets installés par défaut, ça me fait mal au cœur, surtout que les flags d'installation automatique ne sont pas placés correctement, voire pas du tout!
[^] # Re: Xrandr
Posté par freem . En réponse au message quatre ou six ecrans. Évalué à 2.
IL ne demande pas comment contrôler ses écrans, mais comment en avoir beaucoup.
Sinon, pour ton xrandr à la main… je te conseille d'aller voir la doc de .xinitrc, ça t'évitera de t'emmerder à faire les choses à chaque fois.
[^] # Re: C++
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 3.
Pire, tu dis n'imp :) ce warn n'est absolument pas lié au problème qui nous intéresse ici…
[^] # Re: A defaut de GNU, il y a Linux
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 2.
Et comme pour compiler linux il faut GCC, ça supporte GNU/Linux? (je sais, c'est moyen, mais je me souviens qu'on m'avait répondu ça, un jour, je ne sais plus où…)
[^] # Re: C++
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 3.
Admettons. Et pour le cast vers et depuis du void*, tu rétorques quoi? (casts qui sont obligatoires dès lors que l'on veut interagir avec une lib dynamique au runtime, et non au démarrage de l'appli, pour rappel, à moins qu'il existe autre chose que dlsym?)
Franchement, j'aimerai beaucoup qu'il y ait plus sécurité au niveau des casts en C. Parce que dans les langages qui ont des capacités de plus haut niveau, on subit cette faiblesse quand on doit utiliser une lib codée en C, pour une raison X ou Y (j'ai pris l'exemple de dlfcn.h ici, mais ce n'est qu'un exemple, hein, ça pourrait être une lib maison qu'il est obligé d'utiliser, peu importe.).
Comme je l'ai dis. D'ailleurs le reinterpret_cast est l'égal du transtypage du C, à un très gros avantage près: il est super long à taper (sauf avec une auto-complete potable, mais celle de vim étant ce qu'elle est…)/lire, et du coup, ça décourage :)
[^] # Re: Que l’on me jette l’opprobre
Posté par freem . En réponse au sondage mon dispositif de pointage habituel est…. Évalué à 1. Dernière modification le 22 octobre 2014 à 11:39.
Rien que pour me l'avoir fait découvrir, je te plussoie!
Ceci étant dit, je n'ai acheté qu'une fois un clavier MS, et je ne le referai jamais.
[^] # Re: Grosse souris
Posté par freem . En réponse au sondage mon dispositif de pointage habituel est…. Évalué à 3.
Oulah, attention, parce qu'il en existe aussi de vraies grosses, du genre que quand tu poses la main dessus, ton poignet est obligatoirement à 5cm de la table.
Mais bon, je te rejoins: c'est inutilisable, les souris sur lesquelles tu as du mal à poser un doigt sans appuyer sur 2 boutons à la fois…
[^] # Re: Page dédiée à la recherche ?
Posté par freem . En réponse au journal Rechercher au plus juste, ça sauve des bébés morses ! Et toi ?. Évalué à 2.
Je ne sais pas quel brouteur tu utilises mais, dans le mien, à côté de la barre d'URI, il y à une liste déroulante avec cette fameuse liste. Tu sélectionnes un moteur, tu tapes ta recherche, et HOP!
En plus, ça te permets de faire la même recherche d'un moteur à l'autre, simplement en changeant le moteur sélectionné: pas besoin de retaper la recherche, elle n'a pas été effacée…
[^] # Re: Ben... le clavier, what else?
Posté par freem . En réponse au sondage mon dispositif de pointage habituel est…. Évalué à 2.
Vimperator, j'ai essayé vite fait, je ne suis pas convaincu. J'ai aussi utilisé uzbl plus longuement, mais, non, je ne trouve pas cette façon de faire très efficace avec le web.
pentadactyl, connaissais pas par contre, vais tester ça. En espérant ne pas être trop agacé par les choses de FF que je n'apprécie pas.
[^] # Re: Ben... le clavier, what else?
Posté par freem . En réponse au sondage mon dispositif de pointage habituel est…. Évalué à 2.
Mais merci de l'info :)
[^] # Re: C++
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 5.
M'est avis que tu dois sur-estimer les capacités du C toi… le C, c'est quand même le langage dont le typage est tellement sûr, que tu peux transformer l'adresse d'un float en chaîne de caractères ou plus drôle encore, en pointeur de fonction, et le tout, sans warning, même en -Wall -Wextra.
En C++ aussi, c'est vrai, parce que C++ est capable de compiler les horreurs du C, mais si on utilise sagement les améliorations du C++, à savoir [static|dynamic|reinterpret|const]_cast, on sait au moins quand on est en train de faire une
grosse connerietime-bombsection de code très dangereuse: c'est le seul moment ou l'on utilise reinterpret_cast ou const_cast.Rien que pour ça, le C++ bats le C à plate couture (je me demande d'ailleurs s'il existe des warning pour avertir de la présence casts C-style dans du code C++…).
[^] # Re: Forkons Fedora !
Posté par freem . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 3.
Dans son cas, j'ai l'impression qu'il ne parle pas du source de l'init, mais des modules que l'init utilise. Dans le cas de systemd, ces modules sont écrits en C, donc compilés, donc pas directement modifiables.
Dans le cas de sysV, ils sont écrits en… euhh… ça dépend de la configuration j'imagine (c'est vrai d'abord, je me demande si, quelqu'un d'original ne pourrait pas utiliser un autre langage au final?), mais traditionnellement en shell, qui n'est pas compilé (jusqu'à preuve du contraire), et donc dont le source est accessible.
De là à qualifier le shell de plus lisible que du C, je ne m'aventurerai pas, mais je suis biaisé.
[^] # Re: Forkons Fedora !
Posté par freem . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 2.
Ma foi, j'aurai plutôt parlé de regex à ta place. Pour comparer des chaînes de caractères c'est assez simple dans tous les langages (bon, certes, il faut appeler explicitement une fonction quand les langages sont pas objets). La ou shell dépote, c'est pour appeler des programmes et filtrer le texte.
[^] # Re: L'esprit de Mailden
Posté par freem . En réponse au journal Que penses-tu du service mail Mailden ?. Évalué à 5.
Bon, ça va résumer un peu certains commentaires précédents, et je vais ajouter un peu de mon côté au passage:
C'est une vraie raison pour ne pas imposer de technique impliquant aux utilisateurs d'utiliser un système de clé privée/publique (l'utilisateur moyen ne comprendra pas qu'il faut se trimballer une clé et se souvenir d'une passphrase). En revanche, ce n'est pas une bonne raison pour bloquer cette possibilité.
Par rapport à l'envoi de mot de passe (je n'ai pas regardé les sources, je me base sur les commentaires précédents) via le net, l'alternative serait de déporter la mécanique de protection côté client, via du JS (je dis ça, alors qu'en général j'ai tendance à bloquer le JS… allez comprendre!).
Bon, je suis vraiment pas très bon en sécurité, alors je me plante peut-être, ce n'est peut-être pas faisable proprement.
C'est vrai, l'existant est délicat à trouver, en général ce sont de petites associations. Mais il en existe. Ceci étant dit, une plus grosse structure, qui ait pour objectif de grossir et non de faire des boutures n'est pas une mauvaise chose.
Ce n'est pas uniquement sarcastique (mais il faut être habitué à linuxfr il est vrai, pour comprendre entre les lignes), c'est surtout que le code source pointé (chaine.c) révèle plusieurs problèmes:
Enfin, je dirais que roundcube est… spartiate, dans le meilleur des cas. Peut-être avez-vous activé un module qui permets de gérer des règles de filtrage, car il semble que dans la version que j'utilise habituellement, ça n'existe pas, et c'est un manque des plus pénibles, quand on est abonné à une ou deux mailing lists.
En tout cas, bonne chance et bonne continuation.
[^] # Re: Ceci est une révolution
Posté par freem . En réponse au journal Ubuntu a 10 ans. Évalué à 2.
Les icônes ne sont pas en SVG? Si c'est le cas, il est possible qu'elles ne soient pas réduites par le fait d'une trop haute résolution?
[^] # Re: linuxfr.xxx
Posté par freem . En réponse au journal Création du groupe de travail IETF sur « DNS et vie privée ». Évalué à 2.
Pour ça, rien ne vaut le condom :) ça évite de laisser des traces derrière soi.
Ça colle…
Bon, ok, je sors
[^] # Re: Oubli ?
Posté par freem . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 4.
J'imagine que ces systèmes sont nettement plus interchangeables, et nettement moins invasifs, que systemd.
[^] # Re: Écrans Nucléaires
Posté par freem . En réponse à la dépêche Sortie de Linux 3.17. Évalué à 1.
Et le pire quand même, c'est que vivre tue…
[^] # Re: Oubli ?
Posté par freem . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 10.
Raté, ce vote n'a pas pour ambition de changer la décision concernant l'init par défaut, mais de s'assurer que Debian ne se fasse pas enfermer par systemd en garantissant le fait qu'un programme doive avoir l'obligation de pouvoir fonctionner, ne serait-ce qu'en mode dégradé, avec un init différent.
Cette obligation ne concernerait évidemment pas les programmes qui ont pour unique rôle celui de gérer le système d'init.
Ce vote ne remets en cause aucune décision, il souhaite simplement préciser de manière claire que Debian supportera les autres systèmes d'init, dans le temps.
Tu vois, dans ton post, je vois plutôt la rage du modernisme…