Donc, comme je doute qu’il réponde à ta requète si tu leur commande je ne sais quel virus mortel
Moi je n’en doute pas. Tout ce que tu as besoin de fournir, c’est la séquence d’ADN brute, sur laquelle il n’est pas écrit qu’il s’agit du génome viral d’Ebola. À moins de faire une comparaison avec les banques d’ADN connus, la séquence n’est pas identifiable. Une telle analyse n’est pas difficile (ça se fait par exemple en quelques minutes avec le service du NCBI), mais les deux sociétés auprès desquelles j’ai commandé des synthèses de gène ne la font pas — la seule analyse qu’ils font consiste à détecter les parties de la séquence pouvant poser des problèmes de synthèse.
J’ai déjà commandé un gène faisant partie du génome du virus de l’hépatite C (pas le génome entier, certes), on ne m’a opposé aucune difficulté.
Plus sérieusement, n'est-ce pas là un grand danger potentiel ? S'il est possible de facilement manipuler un brin d'ADN pour y écrire à volonté une séquence arbitraire […]
Pour ça, nul nesoin de ces recherches sur le stockage ADN, c’est déjà tout-à-fait possible. Techniquement ce n’est pas à la portée de tout le monde, mais financièrement ça l’est : aujourd’hui des sociétés de biotech peuvent te synthétiser de l’ADN à la demande pour quelques centaines d’euros (prix moyen constaté : entre 0,20 et 0,60 € par paire de bases, dégressif avec la taille totale de la séquence).
[…] serait-il très difficile juste ensuite d'embarquer ce brin dans une coquille de protéines […]
À priori, non. Je le fais même régulièrement, en fait. C’est assez facile, on laisse des cellules en culture se charger d’exprimer les protéines nécessaires, encapsider le génome viral avec, puis on récupère les virus ainsi générés. Et là encore, des boîtes de biotech peuvent le faire pour toi si tu n’as pas le matériel nécessaire (je ne connais pas les prix en revanche).
[…] et obtenir ainsi une « imprimante 3D » à virus biologiques ?
Là en revanche j’ai des doutes sur la possibilité d’automatiser l’ensemble du processus dans une machine. Mais après tout, il y a quelques années je n’aurais pas cru qu’on pourrait séquencer un génome humain en quelques jours (alors qu’il a fallu près de dix ans pour le faire la première fois)…
Pour 30 cycles, à partir d'une séquence d'ADN, on obtient en théorie 2³⁰ copies. Soit environ 1 milliard.
En pratique on en obtient moins, admettons 1 million. Ça se fait en 2-3 heures habituellement.
Si la quantité de données est petite, disons 1Go […]
Deux-trois heures, c’est le temps nécessaire pour amplifier un petit fragment d’ADN (quelques kb maximum).
Et un gigaoctet, ça représente 8 Gbp (en codant un bit par paire de bases), ce qui n’est pas du tout petit et ne s’amplifie pas aussi facilement (les polymérases ont une vitesse de synthèse limitée à environ 1000 bp par minute).
On peut essayer de paralléliser au maximum en multipliant les sites d’hybridation (genre, en insérant un site de priming tous les 5 kb), mais là je trouve qu’on pousse les limites de la PCR un peu loin. À choisir, je mettrais plutôt la séquence dans des cosmides et je laisserais des bactéries se charger de l’amplifier, elles font ça très bien.
comme tout ça n'est que de la théorie on ne peut rien affirmer totalement.
Absolument, mais la réflexion est amusante tout de même.
Je ne sais pas pour grub 1 ou 2, mais avec LILO,¹ ça marche. Un initrd est toujours nécessaire, mais le noyau et l’initrd en question peuvent être chargés depuis un /boot à « l’intérieur » de la matrice RAID.
¹ Oui, oui, LILO existe encore, y en a même qui l’utilisent.
D'ailleurs, la gestion des processus par cgroups de systemd ( pour en revenir au sujet ) implique de dire à sshd de se "détacher" des processus utilisateurs pour éviter de les tuer lors d'un restart, et d'avoir son propre cgroups par utilisateur ( ce qui permet d'appliquer des quotas cpu/ram/etc par utilisateur via les cgroups, justement ). Et pour ça, le moyen le plus propre est de passer par pam, qui va voir au login qu'il y a un utilisateur et qui va le changer de cgroups.
Sans ça, tout les utilisateurs sont dans le cgroup de sshd, et se font donc tuer sans pitié en cas de restart du demon. ( il y a une méthode pour faire autrement, mais c'était tirer par les cheveux et j'ai oublié ).
Euh, moi je fais ça avec les outils de libcgroup (fourni en standard par Slackware), notamment cgrulesengd, ça fonctionne très bien. Si c’est l’autre méthode à laquelle tu pensais, en quoi est-elle « tirée par les cheveux » ?
Ces mécanismes certes existent, mais lorsque que le niveaux "d'agressions" externe est trop important, ils s'avèrent inefficaces
Mais il n’y a guère que lors des catastrophes industrielles que le « niveau d’agression » est suffisamment élevé pour saturer les mécanismes de réparation. En temps normal, ces mécanismes sont amplement suffisants pour faire face aux sources naturelles de dommages.
Empêcher l’exposition à des sources industrielles (en ne stockant pas l’ADN à proximité immédiate d’un réacteur nucléaire par exemple) serait probablement une meilleure idée que d’inventer des mécanismes de réparation taillés pour y faire face.
Effectivement, même si ça ne représente pas grand chose par rapport à copier un million de fois fichier.
[référence nécessaire] Parce qu’entre l’énergie nécessaire pour faire tourner un disque à 5400 rpm le temps de la copie, et l’énergie nécessaire pour faire varier la température d’un bloc chauffant successivement à 95, 55 puis 72℃ pendant trente cycles, je ne suis pas sûr que le disque dur soit plus gourmand… C’est possible, mais je demande à voir des chiffres.
Et bien sûr les thermocyclers dans lesquelles se font les PCR ne demandent pas d’électricité… Et les enzymes nécessaires à la réplication ne coûtent évidemment rien et ne font pas l’objet de querelles de brevet…
Enfin, pour rappeler qu’être visionnaire n'est pas une condition nécessaire pour réussir dans les nouvelles technologies, une citation bien connue de Bill:
640 Ko de mémoire devraient suffire à tout le monde
mais j’aimerais vraiment savoir s'il existe un moyen d'ajouter, une bonne fois pour toutes et sans manipulation subséquente, le support MIDI sur une installation utilisant Pulseaudio.
Si la carte son possède un synthétiseur MIDI matériel (ce n’est jamais le cas si la « carte » son est en réalité un chipset intégré à la carte mère, ce qui est semble-t-il le cas le plus courant aujourd’hui), le support MIDI est présent d’office.
Dans le cas (fréquent donc) contraire, il faut un synthétiseur logiciel, supportant PulseAudio et utilisable en mode démon (Fluidsynth par exemple). Lancé au démarrage,¹ il créera une interface MIDI virtuelle que pourra utiliser n’importe quel logiciel. C’est aussi simple que ça, il ne reste aux distributions qu’à installer un tel synthétiseur logiciel par défaut. Lesquelles le font ? Aucune idée.
¹J’imagine qu’avec systemd, il devrait être possible de ne lancer le synthétiseur logiciel que lorsqu’une application en a besoin, de façon transparente. Mais ça ne change rien au principe.
Quand au spam, je reste mitigé: ok sur le principe, mais je suis ne pas certains que sans l'intervention des FAI l'autohébergement des mails serait possible…
Je ne suis pas sûr de comprendre : tu voudrais auto-héberger tes mails mais quand même compter sur le FAI pour intercepter le spam pour toi ? Euh, à quoi bon auto-héberger alors, autant utiliser directement les serveurs du FAI…
Je me souviens d'une époque ou on pouvais faire plein de choses sans internet. Genre, jouer à des jeux, travailler.
Moi aussi, mais apparemment ce qui était évident à l’époque ne l’est plus maintenant. La preuve, maintenant la possibilité de travailler offline (travailler tout court, quoi) est une fonctionnalité qui doit être mise en avant comme telle :
you can edit documents even without an Internet connection
C'est quand même une solution très puissante et plutôt ouverte non ?
Je ne dis pas le contraire. Mais les connecteurs CalDAV/CardDAV ne sont pas fournis par Google, qui voit probablement ces connecteurs comme des moyens de se passer de ses propres services de calendrier et de carnet d’adresses (qui, eux, sont synchronisables « out-of-the-box » avec Android) et n’a donc pas grand-intérêt à les supporter.
Mon point est que Microsoft n’est pas « le seul à ne pas gérer CalDAV/CardDAV », et que Google (comme les autres) supporte les protocoles standards quand ça l’arrange.
Y'a que Microsoft pour ne pas gérer calDAV et cardDAV
Euh, non, Android ne le gère pas non plus. Au moins sur Android 2.3 et 4.1 (et probablement toutes les autres versions, j’imagine), il faut installer des outils tiers (non fournis par Google) pour synchroniser calendrier et carnet d’adresses avec des serveurs CalDAV/CardDAV arbitraires.
Peut être qu'ils veulent que le code soit aussi compilable avec un compilateur C des années 70 (ce qui ne m'étonnerait pas).
Seulement pour les programmes qui sont déjà compilables avec un compilateur pré-C89, dont les mainteneurs sont invités à ne pas changer ça. Sinon, c’est laissé à la discrétion des développeurs.
1989 Standard C is widespread enough now that it is ok to use its features in new programs. […] However, it is easy to support pre-standard compilers in most programs, so if you know how to do that, feel free. If a program you are maintaining has such support, you should try to keep it working.
Je ne pense pas que le pilotage au clavier soit la caractéristique marquante de Awesome ; en tout cas, ce n’est pas celle qui m’intéresse le plus. Pour moi, le principal intérêt d’Awesome est davantage sa grande « bidouillabilité ».
Après, ce n’est pas le seul gestionnaire de fenêtres bidouillable, certes. wmii, que j’utilisais auparavant, est aussi très bien de ce point de vue (à mon avis il est même mieux, en fait, parce qu’il laisse le choix du langage de script au lieu d’imposer Lua) — mais il gère très mal les écrans multiples, à la différence de Awesome.
Après, on peut ne pas approuver cette position de la FSF (auquel cas, ça tombe bien, on est libre de n’en avoir rien à cirer). Mais la position est clairement définie et non pas hypocritement laissée dans l’obscurité pour pouvoir la changer « à la tête du client » comme certains le disent.
J’utilise Friendica pour ma part, et comme toutes mes connaissances (je réserve le terme « amis » à un cercle très restreint de personnes) sont sur Facebook, j’ai aussi un compte Facebook auquel mon compte Friendica est lié : je poste depuis Friendica, mes connaissances voient mes messages sur Facebook ; elles écrivent sur Facebook, je vois leurs messages depuis Friendica.
J’aurais préféré ne pas avoir à créer de compte Facebook pour ça (c’est comme s’il fallait créer un compte GMail pour recevoir des messages venant d’utilisateurs de GMail), mais c’est le meilleur compromis que j’ai trouvé. De cette façon, j’évite de casser les pieds à tous ceux qui utilisent Facebook et n’envisagent pas d’utiliser autre chose juste pour me faire plaisir, sans pour autant obliger à mon tour mes interlocuteurs à utiliser Facebook (ils peuvent utiliser au choix Friendica, Diaspora, StatusNet et Facebook).
Euh, s’il fallait choisir entre l’intuitivité et l’ergonomie, je prendrais l’ergonomie personnellement…
Je préfère une IHM confortable et saine à utiliser sur le long terme, quitte à devoir prendre un peu de temps au début pour comprendre comment elle fonctionne, à une IHM que je comprends intuitivement mais qui se révèle pénible à utiliser.
Si on peut combiner les deux propriétés, tant mieux, mais sinon, sacrifier l’ergonomie me semble inexcusable pour une IHM.
Personne n'a jamais dit qu'il fallait intégrer screen au système d'init.
Pas « intégrer » au sens de « implémenter les fonctionnalités de screen dans systemd », mais au sens de « faire le nécessaire pour que screen fonctionne correctement en présence de systemd ». Au moins deux utilisateurs ici admettent qu’une telle « intégration » est nécessaire : Xavier Claude à qui je répondais (« mauvaise intégration de screen avec systemd ») et Zenitram (« screen: bug d'intégration, indépendant de systemd »).
Cette histoire de "screen" n'est qu'un FUD.
Ben non. Le passage à systemd impose des adaptations, c’est un fait. Ce n’est pas forcément grand’chose, certainement rien d’insurmontable et c’est peut-être insignifiant par rapport aux bénéfices de systemd, mais tout de même. Balayer ces problèmes d’adaptation d’un revers de la main à coup de « FUD », « c’est pas la faute de systemd », « c’est les intégrateurs qui font n’importe quoi », etc. ne va pas aider.
le problème avec screen n'est pas lié à systemd (il marche très bien dans Fedora) mais à la mauvaise intégration de screen avec systemd dans la distribution de l'auteur du journal.
En même temps, sur ma distro sans systemd, il n’y a pas besoin « d’intégrer » screen au système d’init… Pourquoi systemd requiert-il que des programmes n’ayant rien à voir avec l’init soient « intégrés » avec lui ? Quels autres systèmes d’init requièrent ce genre de choses ?
La on dit "un élève perturbe le cours, le prof le puni, il refuse la punition, le prof le vire, il sort pas". Je trouve tout a fait légitime que le prof refuse de poursuivre le cours temps que l'élève est pas sorti
Moi pas (je ne trouve pas ça légitime). Pourquoi les autres élèves, qui ne perturbaient pas le cours, devraient être responsables des agissements du seul élément perturbateur ?
Parce qu’ils n’ont pas pris l’initiative « d’expulser manu militari » l’élève fautif ? Mais est-ce vraiment à eux de le faire ?
En plus d’être illégitime, c’est très con, parce que l’élève qui perturbait la classe n’en a probablement rien à faire que le prof ne fasse pas son cours, contrairement aux autres élèves. Donc en fin de compte le prof pénalise tout le monde sauf le responsable.
Non mais attend, cette regle est juste stupide. Pourquoi devrais-je nettoyer la salle juste parce que je suis assis au dernier rang ?
Je ne sais pas quelle était l’intention de l’auteur de la diapo. Mais j’ai déjà donné des cours dans des salles où il y avait trois ou quatre fois plus de places que d’étudiants, et là, la dynamique des étudiants est toujours la même : les deux premiers rangs sont toujours vides. Vu le ton général de la diapo, je suppose que cette « règle » est simplement une façon de dire, « il y a de la place au premier rang (et le prof ne postillonne pas) ».
Après, si ce n’est pas qu’une façon d’inciter les étudiants à occuper les premiers rangs et que la règle est réellement appliquée (donc que les étudiants restant au fond se voient vraiment contraint de nettoyer la salle), je suis d’accord que c’est stupide. Personnellement, j’invite explicitement les étudiants à se rapprocher, ils le font tant mieux, ils ne le font pas tant pis.
Ben, même les programmes de ce genre supportent généralement très bien le passage d’une version du noyau à une autre. J’utilise actuellement une Slackware 14.0 dont tous les programmes ont été compilés contre un noyau 3.2.29 (le noyau fourni avec la distribution), et tous ces programmes fonctionnent sans problèmes une fois le noyau mis à jour en 3.6.6.
Et précédemment, sous Slackware 13.37, les programmes compilés contre un noyau 2.6.37 (fourni avec la distribution) fonctionnaient sans problèmes avec un noyau 3.4.2.
Même le passage d’un noyau 2.4 à un noyau 2.6, sous Slackware 11, n’avait pas nécessité de recompilation des programmes en userland, y compris les programmes « fortement couplés » au noyau comme udev, modprobe & co.
[^] # Re: Anti-virus ?
Posté par gouttegd . En réponse au journal L'ADN, le stockage de demain. Évalué à 2.
Moi je n’en doute pas. Tout ce que tu as besoin de fournir, c’est la séquence d’ADN brute, sur laquelle il n’est pas écrit qu’il s’agit du génome viral d’Ebola. À moins de faire une comparaison avec les banques d’ADN connus, la séquence n’est pas identifiable. Une telle analyse n’est pas difficile (ça se fait par exemple en quelques minutes avec le service du NCBI), mais les deux sociétés auprès desquelles j’ai commandé des synthèses de gène ne la font pas — la seule analyse qu’ils font consiste à détecter les parties de la séquence pouvant poser des problèmes de synthèse.
J’ai déjà commandé un gène faisant partie du génome du virus de l’hépatite C (pas le génome entier, certes), on ne m’a opposé aucune difficulté.
[^] # Re: Anti-virus ?
Posté par gouttegd . En réponse au journal L'ADN, le stockage de demain. Évalué à 3.
Pour ça, nul nesoin de ces recherches sur le stockage ADN, c’est déjà tout-à-fait possible. Techniquement ce n’est pas à la portée de tout le monde, mais financièrement ça l’est : aujourd’hui des sociétés de biotech peuvent te synthétiser de l’ADN à la demande pour quelques centaines d’euros (prix moyen constaté : entre 0,20 et 0,60 € par paire de bases, dégressif avec la taille totale de la séquence).
À priori, non. Je le fais même régulièrement, en fait. C’est assez facile, on laisse des cellules en culture se charger d’exprimer les protéines nécessaires, encapsider le génome viral avec, puis on récupère les virus ainsi générés. Et là encore, des boîtes de biotech peuvent le faire pour toi si tu n’as pas le matériel nécessaire (je ne connais pas les prix en revanche).
Là en revanche j’ai des doutes sur la possibilité d’automatiser l’ensemble du processus dans une machine. Mais après tout, il y a quelques années je n’aurais pas cru qu’on pourrait séquencer un génome humain en quelques jours (alors qu’il a fallu près de dix ans pour le faire la première fois)…
[^] # Re: Énergie
Posté par gouttegd . En réponse au journal L'ADN, le stockage de demain. Évalué à 2.
Deux-trois heures, c’est le temps nécessaire pour amplifier un petit fragment d’ADN (quelques kb maximum).
Et un gigaoctet, ça représente 8 Gbp (en codant un bit par paire de bases), ce qui n’est pas du tout petit et ne s’amplifie pas aussi facilement (les polymérases ont une vitesse de synthèse limitée à environ 1000 bp par minute).
On peut essayer de paralléliser au maximum en multipliant les sites d’hybridation (genre, en insérant un site de priming tous les 5 kb), mais là je trouve qu’on pousse les limites de la PCR un peu loin. À choisir, je mettrais plutôt la séquence dans des cosmides et je laisserais des bactéries se charger de l’amplifier, elles font ça très bien.
Absolument, mais la réflexion est amusante tout de même.
[^] # Re: Serveurs
Posté par gouttegd . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
Je ne sais pas pour grub 1 ou 2, mais avec LILO,¹ ça marche. Un initrd est toujours nécessaire, mais le noyau et l’initrd en question peuvent être chargés depuis un
/bootà « l’intérieur » de la matrice RAID.¹ Oui, oui, LILO existe encore, y en a même qui l’utilisent.
[^] # Re: rapidité, changement
Posté par gouttegd . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Euh, moi je fais ça avec les outils de libcgroup (fourni en standard par Slackware), notamment cgrulesengd, ça fonctionne très bien. Si c’est l’autre méthode à laquelle tu pensais, en quoi est-elle « tirée par les cheveux » ?
[^] # Re: Altération des données ?
Posté par gouttegd . En réponse au journal L'ADN, le stockage de demain. Évalué à 3.
Mais il n’y a guère que lors des catastrophes industrielles que le « niveau d’agression » est suffisamment élevé pour saturer les mécanismes de réparation. En temps normal, ces mécanismes sont amplement suffisants pour faire face aux sources naturelles de dommages.
Empêcher l’exposition à des sources industrielles (en ne stockant pas l’ADN à proximité immédiate d’un réacteur nucléaire par exemple) serait probablement une meilleure idée que d’inventer des mécanismes de réparation taillés pour y faire face.
[^] # Re: Énergie
Posté par gouttegd . En réponse au journal L'ADN, le stockage de demain. Évalué à 4.
[référence nécessaire] Parce qu’entre l’énergie nécessaire pour faire tourner un disque à 5400 rpm le temps de la copie, et l’énergie nécessaire pour faire varier la température d’un bloc chauffant successivement à 95, 55 puis 72℃ pendant trente cycles, je ne suis pas sûr que le disque dur soit plus gourmand… C’est possible, mais je demande à voir des chiffres.
[^] # Re: Énergie
Posté par gouttegd . En réponse au journal L'ADN, le stockage de demain. Évalué à 6.
Et bien sûr les thermocyclers dans lesquelles se font les PCR ne demandent pas d’électricité… Et les enzymes nécessaires à la réplication ne coûtent évidemment rien et ne font pas l’objet de querelles de brevet…
[^] # Re: Altération des données ?
Posté par gouttegd . En réponse au journal L'ADN, le stockage de demain. Évalué à 2.
De tels mécanismes existent déjà dans n’importe quelle cellule vivante, y compris les plus anciennes bactéries.
[^] # Re: Prédication réaliste
Posté par gouttegd . En réponse au journal Futurologue. Évalué à 4.
Pour information et pour ce que ça vaut, l’intéressé dément avoir jamais dit ça.
[^] # Re: Le midi sous Linux avec Pulseaudio
Posté par gouttegd . En réponse au journal For musicians only (*). Évalué à 3.
Si la carte son possède un synthétiseur MIDI matériel (ce n’est jamais le cas si la « carte » son est en réalité un chipset intégré à la carte mère, ce qui est semble-t-il le cas le plus courant aujourd’hui), le support MIDI est présent d’office.
Dans le cas (fréquent donc) contraire, il faut un synthétiseur logiciel, supportant PulseAudio et utilisable en mode démon (Fluidsynth par exemple). Lancé au démarrage,¹ il créera une interface MIDI virtuelle que pourra utiliser n’importe quel logiciel. C’est aussi simple que ça, il ne reste aux distributions qu’à installer un tel synthétiseur logiciel par défaut. Lesquelles le font ? Aucune idée.
¹J’imagine qu’avec systemd, il devrait être possible de ne lancer le synthétiseur logiciel que lorsqu’une application en a besoin, de façon transparente. Mais ça ne change rien au principe.
[^] # Re: « Le débat oppose deux grandes idées » ah non !
Posté par gouttegd . En réponse au journal Quelques pistes pour améliorer le web ?. Évalué à 2.
Je ne suis pas sûr de comprendre : tu voudrais auto-héberger tes mails mais quand même compter sur le FAI pour intercepter le spam pour toi ? Euh, à quoi bon auto-héberger alors, autant utiliser directement les serveurs du FAI…
[^] # Re: La maintenance nulle (et Noël)
Posté par gouttegd . En réponse au journal Le laptop le plus vendu par Amazon en décembre tourne sous Google/Linux. Évalué à 10.
Moi aussi, mais apparemment ce qui était évident à l’époque ne l’est plus maintenant. La preuve, maintenant la possibilité de travailler offline (travailler tout court, quoi) est une fonctionnalité qui doit être mise en avant comme telle :
Ben merde, encore heureux…
[^] # Re: euh
Posté par gouttegd . En réponse au journal Google : don't be evil, la suite. Évalué à 3.
Je ne dis pas le contraire. Mais les connecteurs CalDAV/CardDAV ne sont pas fournis par Google, qui voit probablement ces connecteurs comme des moyens de se passer de ses propres services de calendrier et de carnet d’adresses (qui, eux, sont synchronisables « out-of-the-box » avec Android) et n’a donc pas grand-intérêt à les supporter.
Mon point est que Microsoft n’est pas « le seul à ne pas gérer CalDAV/CardDAV », et que Google (comme les autres) supporte les protocoles standards quand ça l’arrange.
[^] # Re: euh
Posté par gouttegd . En réponse au journal Google : don't be evil, la suite. Évalué à 7.
Euh, non, Android ne le gère pas non plus. Au moins sur Android 2.3 et 4.1 (et probablement toutes les autres versions, j’imagine), il faut installer des outils tiers (non fournis par Google) pour synchroniser calendrier et carnet d’adresses avec des serveurs CalDAV/CardDAV arbitraires.
[^] # Re: Prochain mainteneur pour sed ?
Posté par gouttegd . En réponse au journal Grabuge à la FSF : GnuTLS quitte le projet GNU et sed perd son mainteneur. Évalué à 3.
Seulement pour les programmes qui sont déjà compilables avec un compilateur pré-C89, dont les mainteneurs sont invités à ne pas changer ça. Sinon, c’est laissé à la discrétion des développeurs.
Extrait des GNU Coding Standards :
[^] # Re: vs fluxbox ?
Posté par gouttegd . En réponse à la dépêche Awesome 3.5. Évalué à 3.
Je ne pense pas que le pilotage au clavier soit la caractéristique marquante de Awesome ; en tout cas, ce n’est pas celle qui m’intéresse le plus. Pour moi, le principal intérêt d’Awesome est davantage sa grande « bidouillabilité ».
Après, ce n’est pas le seul gestionnaire de fenêtres bidouillable, certes. wmii, que j’utilisais auparavant, est aussi très bien de ce point de vue (à mon avis il est même mieux, en fait, parce qu’il laisse le choix du langage de script au lieu d’imposer Lua) — mais il gère très mal les écrans multiples, à la différence de Awesome.
[^] # Re: l'infamant sceau du non-libre
Posté par gouttegd . En réponse au journal La FSF, de dangereux crétins réactionnaires. Évalué à 4.
Seulement si on ne veut pas le voir, parce que les deux pages suivantes me semblent assez explicites :
* Guidelines for Free System Distributions
* Explaining Why We Don't Endorse Other Systems
Après, on peut ne pas approuver cette position de la FSF (auquel cas, ça tombe bien, on est libre de n’en avoir rien à cirer). Mais la position est clairement définie et non pas hypocritement laissée dans l’obscurité pour pouvoir la changer « à la tête du client » comme certains le disent.
# Friendica + “Facebook-over-Friendica”
Posté par gouttegd . En réponse au sondage Mon réseau social principal…. Évalué à 2.
J’utilise Friendica pour ma part, et comme toutes mes connaissances (je réserve le terme « amis » à un cercle très restreint de personnes) sont sur Facebook, j’ai aussi un compte Facebook auquel mon compte Friendica est lié : je poste depuis Friendica, mes connaissances voient mes messages sur Facebook ; elles écrivent sur Facebook, je vois leurs messages depuis Friendica.
J’aurais préféré ne pas avoir à créer de compte Facebook pour ça (c’est comme s’il fallait créer un compte GMail pour recevoir des messages venant d’utilisateurs de GMail), mais c’est le meilleur compromis que j’ai trouvé. De cette façon, j’évite de casser les pieds à tous ceux qui utilisent Facebook et n’envisagent pas d’utiliser autre chose juste pour me faire plaisir, sans pour autant obliger à mon tour mes interlocuteurs à utiliser Facebook (ils peuvent utiliser au choix Friendica, Diaspora, StatusNet et Facebook).
[^] # Re: intuitive != d'utilisable
Posté par gouttegd . En réponse au journal Moment de détente. Évalué à 7.
Euh, s’il fallait choisir entre l’intuitivité et l’ergonomie, je prendrais l’ergonomie personnellement…
Je préfère une IHM confortable et saine à utiliser sur le long terme, quitte à devoir prendre un peu de temps au début pour comprendre comment elle fonctionne, à une IHM que je comprends intuitivement mais qui se révèle pénible à utiliser.
Si on peut combiner les deux propriétés, tant mieux, mais sinon, sacrifier l’ergonomie me semble inexcusable pour une IHM.
[^] # Re: Le vendredi c'est permis
Posté par gouttegd . En réponse à la dépêche Retard++ de Fedora 18 et nom de code quantique pour la version 19. Évalué à 0.
Pas « intégrer » au sens de « implémenter les fonctionnalités de screen dans systemd », mais au sens de « faire le nécessaire pour que screen fonctionne correctement en présence de systemd ». Au moins deux utilisateurs ici admettent qu’une telle « intégration » est nécessaire : Xavier Claude à qui je répondais (« mauvaise intégration de screen avec systemd ») et Zenitram (« screen: bug d'intégration, indépendant de systemd »).
Ben non. Le passage à systemd impose des adaptations, c’est un fait. Ce n’est pas forcément grand’chose, certainement rien d’insurmontable et c’est peut-être insignifiant par rapport aux bénéfices de systemd, mais tout de même. Balayer ces problèmes d’adaptation d’un revers de la main à coup de « FUD », « c’est pas la faute de systemd », « c’est les intégrateurs qui font n’importe quoi », etc. ne va pas aider.
[^] # Re: Le vendredi c'est permis
Posté par gouttegd . En réponse à la dépêche Retard++ de Fedora 18 et nom de code quantique pour la version 19. Évalué à 0. Dernière modification le 17 novembre 2012 à 19:01.
En même temps, sur ma distro sans systemd, il n’y a pas besoin « d’intégrer » screen au système d’init… Pourquoi systemd requiert-il que des programmes n’ayant rien à voir avec l’init soient « intégrés » avec lui ? Quels autres systèmes d’init requièrent ce genre de choses ?
[^] # Re: Pour une fois
Posté par gouttegd . En réponse au journal Interview de Linus à LinuxCon Europe 2012. Évalué à 2.
Moi pas (je ne trouve pas ça légitime). Pourquoi les autres élèves, qui ne perturbaient pas le cours, devraient être responsables des agissements du seul élément perturbateur ?
Parce qu’ils n’ont pas pris l’initiative « d’expulser manu militari » l’élève fautif ? Mais est-ce vraiment à eux de le faire ?
En plus d’être illégitime, c’est très con, parce que l’élève qui perturbait la classe n’en a probablement rien à faire que le prof ne fasse pas son cours, contrairement aux autres élèves. Donc en fin de compte le prof pénalise tout le monde sauf le responsable.
[^] # Re: Pour une fois
Posté par gouttegd . En réponse au journal Interview de Linus à LinuxCon Europe 2012. Évalué à 4.
Je ne sais pas quelle était l’intention de l’auteur de la diapo. Mais j’ai déjà donné des cours dans des salles où il y avait trois ou quatre fois plus de places que d’étudiants, et là, la dynamique des étudiants est toujours la même : les deux premiers rangs sont toujours vides. Vu le ton général de la diapo, je suppose que cette « règle » est simplement une façon de dire, « il y a de la place au premier rang (et le prof ne postillonne pas) ».
Après, si ce n’est pas qu’une façon d’inciter les étudiants à occuper les premiers rangs et que la règle est réellement appliquée (donc que les étudiants restant au fond se voient vraiment contraint de nettoyer la salle), je suis d’accord que c’est stupide. Personnellement, j’invite explicitement les étudiants à se rapprocher, ils le font tant mieux, ils ne le font pas tant pis.
[^] # Re: plop
Posté par gouttegd . En réponse au journal Si on commençait un nouvel OS libre de bureau aujourd'hui.... Évalué à 2.
Ben, même les programmes de ce genre supportent généralement très bien le passage d’une version du noyau à une autre. J’utilise actuellement une Slackware 14.0 dont tous les programmes ont été compilés contre un noyau 3.2.29 (le noyau fourni avec la distribution), et tous ces programmes fonctionnent sans problèmes une fois le noyau mis à jour en 3.6.6.
Et précédemment, sous Slackware 13.37, les programmes compilés contre un noyau 2.6.37 (fourni avec la distribution) fonctionnaient sans problèmes avec un noyau 3.4.2.
Même le passage d’un noyau 2.4 à un noyau 2.6, sous Slackware 11, n’avait pas nécessité de recompilation des programmes en userland, y compris les programmes « fortement couplés » au noyau comme udev, modprobe & co.