freem a écrit 5059 commentaires

… enfin, pas que.

En gros, ta consommation électrique va varier en fonction du taux d'occupation de la RAM, de l'usage du CPU (et du GPU s'il y à lieu) ainsi que du disque dur.

Ce qui bouffe les ressources, ce sont les programmes lancés, que ce soit en avant plan ou en tâche de fond. Par exemple, si Ubuntu est comme une Debian par défaut, tu as un serveur d'impression (cups), ainsi qu'un MTA (logiciel de transfert de mail, par exemple exim).
C'est outils ne sont pas nécessairement utiles en permanence, voire même jamais, donc les désinstaller ou les désactiver en fonction de ton usage est important pour diminuer ta consommation de ressources.

Dans les programmes lancés, j'inclue également l'environnement de bureau (aussi appelé DE, de l'anglais Desktop Environment, c'est l'ensemble des applications qui te permettent d'explorer tes fichiers, de te connecter, et pas mal d'autres choses en fonction de celui utilisé).
Utiliser un DE léger (je peux citer LXDE ou XFCE, mais il existe d'autres alternatives nécessitant plus ou moins de connaissance du système) aidera, sachant que par défaut, Ubuntu intègre Unity, qui n'est pas vraiment ce qu'on peut appeler léger.
Ceci étant valable également sous windows. Si windows t'indique le même temps d'autonomie avec et sans navigateur ouvert, alors c'est soit qu'ils ont inventé le mouvement perpétuel, soit qu'ils mentent, soit que le navigateur est fait lancé en permanence sans que tu le sache. Ou alors c'est un bug :)

Il y à aussi la possibilité de régler les modes de ta machine, comme sous windows, par exemple baisser automatiquement l'intensité de l'écran quand tu es sur batterie, brider le CPU, etc.

Bon, sinon, je sais qu'Ubuntu n'a pas la réputation d'une distribution super légère, mais… bon, chacun prêchera pour sa paroisse, et les paroisses linux sont légion. Pour ma part, j'ai une préférence pour Debian, mais j'aime mettre le nez dans mon système, et Debian est moins triviale à configurer correctement qu'Ubuntu.
En plus accessible et peut-être plus efficace en consommation énergétique, j'ai entendu beaucoup de bien de Mint mais je ne l'ai jamais testée.

La stégano bien faite est indétectable

D'un autre côté, un chiffrement bien fait est "incassable", si l'on passe par là. Je veux dire que dans l'idéal, les moyens de protection sont impénétrables, mais dans la pratique, j'avoue avoir un peu de mal à imaginer que des organisations gouvernementales spécialisées dans l'espionnage n'aient aucun outil pour contrecarrer ce type de techniques. C'est au moins aussi vieux que le chiffrement, après tout.

Du coup, vous utilisez quoi pour faire des TU sur shell? Juste un autre script qui appelle la fonction, ou des outils plus chiadés?

Merci pour les infos.
L'option "-x" ne sert qu'a afficher la commande exécutée, c'est ça? (man bash ne dis rien au sujet de cette option)
Enfin, on est loin d'un réel débogage tout de même.

Toujours aussi percutants les arguments des anti-systemd!

Ne mets pas toutes les personnes qui n'apprécient pas systemd dans le même sac s'il te plaît. Il est possible que j'échoue à ça, mais j'essaie de rester objectif, et j'accorde même un certain nombre d'excellents points à systemd.

Et a, b, c, et bien il y a environ 0 autres langages de programmation mainstream qui le permettent.

Perl ne le permets pas? (c'est une vraie question)

Rien n'est reproché au script lui-même, qui est effectivement relativement lisible, pour du shell.

Maintenant, un extrait au hasard:

case "$1" in
  start)
    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC " "$NAME"
    do_start
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
  ;;

J'ai quelques vagues notions de shell, par exemple je sais que [] est l'équivalent de l'appel à "test". Bon, c'est plus court à taper, et quand on sait que ça veut dire un test, ça va. Enfin, ça va, tant qu'il n'y à pas de "-eq", "-z" ou autre joyeusetés.
Ensuite, bon, la technique d'utiliser l'opérateur logique AND en lieu et place d'un if, c'est cool, tous les dev et admin linux confirmés doivent savoir s'en servir, mais c'est pas aussi trivial que ça.
Dernier point, pourquoi l'auteur a-t-il mis deux ";" à la suite à chaque ligne?
Autrement dit, 9 lignes, 3 WTF pour un curieux qui débarquerait sous Linux et souhaiterais apprendre. Je ne parlerais pas du fait que le langage est incohérent, bien sûr: "if/fi", "case/esac", "for/do/done"? Je ne suis pas sûr pour les while, je ne les ai jamais utilisés, mais j'imagine que c'est similaire à for… Ah, ben du coup je viens de tilter, l'écriture à la con en inversé, c'est juste pour les sauts conditionnels? WTF!

Et puis la, on à du bol, il n'y à pas mixes de chaînes de caractères, ces fameux mixes qui me donnent souvent un mal de chien: "" et '', surtout quand il faut faire appel à des outils tiers qui utilisent eux aussi ce genre de joyeusetés.

En plus c'est tres facile a developper et deboguer car on peut facilement isoler un element du pipe pour l'ausculter, faire du mocking (avec cat)…

Si je comprend bien, le "mocking", c'est l'art de déboguer à coup d'affichage intempestif? Dans ce cas, navré, mais il va falloir que tu changes ta définition de "facile à déboguer", le debug à coup d'affichage, et donc de modif du code, c'est la pire façon de déboguer qui soit, le dernier recours.
Si ce n'est pas ça, je veux bien que tu expliques ce qu'est le mocking, parce que dans ce cas ça m'intéresse.

C'est quoi ZMV?
Je n'ai pas réussi à trouver des infos qui semblent pertinentes avec le sujet?

Même si je suis plutôt d'accord avec les points que tu soulèves, je dirais qu'il faut distinguer clair et accessible en programmation.
Le langage Java est conçu pour être très accessible, mais un code long sera plus embrouillé qu'un équivalent dans d'autres langages, notamment à cause de la verbosité.
Dans le cas du code awk, il est effectivement plus clair, mais vachement moins accessible. En même temps, awk, sed, shell sont des langages qui me semblent plutôt conçus pour des programmes courts, contrairement à des langages comme Java.
Et cette opinion est la raison même qui fait que je trouve regrettable que les scripts d'init soient faits en shell (passé les 60 lignes de codes, je n'appelle plus ça "court") et non dans un langage plus adapté, éventuellement déclaratif.

J'ai appris quelque chose.

Dans mon cas, plus d'une, alors que je n'ai pas encore tout lu. Article super intéressant, et… accessible aux néophytes, ce qui n'est pas toujours le cas :)

Le droit ne dépend pas de la morale.

En même temps, heureusement: de la morale de qui devrait-il dépendre? Lors de sa jeunesse ou de son âge plus avancé? Comment définir la morale? J'imagine que c'est pour (éviter?) ces questions là qu'Hans Kelven à fait ses travaux.

Mais bon, dans la pratique, au final la loi dépend de la morale de celui qui va l'écrire, la seule garantie théorique étant le fait que la loi est censée respecter un ensemble de normes.

Le mien semble correspondre aux besoin. Extrêmement bonne résistance aux mauvais traitements (vérifiée par mon frère qui à brossé son téléphone de service au sortir d'une usine avec pas mal de poussière de carbone, en fonctionnement et sous l'eau, et par moi qui ai fait quelques crash tests au mien), la batterie tiens… largement assez à mon avis, mais j'ai un trafic faible et le haut parleur me satisfait aussi.

Pas d'écran tactile, par contre, pas d'http à ce que je sais, probablement moyen de récup les mails malgré tout, un agenda potable, et fais bien son office de réveil.

Je qualifie ce truc de téléphone de chantier, en fait, mais on pourrais l'appeler le 3310 des temps modernes, je suppose. Par contre, oui, téléphone à 12 touches pour les textos, mais bon, perso ça me dérange pas. Chacun son besoin, en même temps, mais j'imagine mal un téléphone avec plus de touche être aussi solide.

Grr… timeout…

M'enfin, pour le reste, il y à un nombre assez impressionnant de méthodes qui peuvent être contrées par les techniques de base, à savoir, juste ne pas cliquer n'importe où, séparer son identité réelle de son pseudo (bon, dans mon cas, je sais qu'une recherche pourrait me faire trouver, mais ce serait bien cher pour ne rien trouver d'utile).
Et puis, ça parle beaucoup de crypto, mais quid de la stéganographie? Je n'ai vu aucune info concernant leurs outils pour contrecarrer la stéga, est-ce parce que c'est plus compliqué à "casser"?

Oui mais non car ils ont en meme temps fait voter des lois style patriot act qui sous le pretexte de terrorisme leur permet de faire tout et n'importe quoi et en particulier de s'assoir sur la constitution, les droits de l'homme etc.

Il me semble que théoriquement la constitution prévaut sur les lois. Mais bon, les états ne respectent déjà pas leurs propres lois, alors leurs constitutions…

Chez moi, gtk3 à des dépendances à systemd si on suit la cascade de dépendances.

en fait, un systeme d'init base sur le shell est base sur un systeme bien compris par un admin.

Mais tous les utilisateurs de systèmes non windows ne sont pas nécessairement, ni ne veulent être, de bons admin. Admin, c'est un métier, qui à l'air super intéressant de mon point de vue et aller fouiller dans les scripts et autres man ne me fait pas peur quoiqu'on puisse penser de mes propos, mais en premier contact ce n'est pas vraiment aisé.

c'est une situation bien moins atroce que ce que tu depeins.

Peut-être. Toujours est-il que j'ai essayé de le faire à ma façon sous Debian, c'est à dire en fouillant dans le man et en lisant le code source. Franchement, j'ai été largué, mais c'est vrai aussi que je suis bien plus habitué à des langages type Java, C++ et compagnie.
Après, peut-être aussi que sur d'autres systèmes les scripts sont plus clairs. Je songe justement à aller tester un des BSD depuis quelques temps, histoire de voir de quelle couleur est l'herbe à côté.

Zut, je pensais que c'était un équivalent de LSD :p (bon ok je sors)

Mais il faut en avoir le besoin, pour moi, systemd démontre que ce n'est pas nécessaire pour l'init.

Yep, je suis bien d'accord.

J’ai du mal à voir l’intérêt d’un faible couplage entre le système d’init et le noyau quand on voit les avantages notamment en terme de sécurité et de fonctionnalité.

Pour les fonctionnalités, je veux bien. Pour la sécurité, je veux bien… que tu développes un peu plus.
Sinon, le couplage faible avec le noyau, ok, c'est pas utile. Mais j'ai parlé du système, moi, pas juste du noyau, et même si ce n'est pas la faute de systemd si GTK et KDE commencent manifestement à intégrer des dépendances en dur à celui-ci, c'est malgré tout regrettable.
Sinon, le fait de faire des choses portables nécessite en général un couplage plus faible. Et la portabilité permets, selon moi mais c'est juste une opinion, d'améliorer la qualité des logiciels, autant en perfs qu'en sécurité (plus de compilos utilisables, plus de warnings détectés, par exemple). Mais bon, déjà, ça marche, c'est excellent en soit et il m'arrive d'utiliser des softs non portables, quand ils m'apportent une réelle plus-value. Donc peut-être que je me laisserai convaincre par systemd un de ces 4, après tout, j'ai quand même quelques attirances pour certains de ses aspects.

Et puis c’est pas comme si systemd était compatible avec rien: il peut fonctionner sur toutes les distributions GNU/Linux!

Euh… hum… ouai, en fait, tu dis que systemd peut marcher avec tous les kernel linux. Humhum.

Tous les logiciels n'ont pas pour objectif d'être Michu-compliant.

C'est vrai, mais je pense que complexifier la personnalisation (au niveau administration principalement, puis logiciel) d'un système n'est pas une bonne chose. Systemd est sur ce point intéressant pour moi, mais je trouve regrettable d'un autre côté qu'il complexifie de façon injustifiée --à mes yeux-- le plus bas niveau (dépendances des logiciels de plus en plus dures, une archi "modulaire" au couplage douteux, ce genre de choses. Mais je dis peut-être des conneries, je n'ai pas la prétention de maîtriser le sujet.).
M'enfin, on va pas recommencer un troll sur systemd. De toute façon, même si je n'ai manifestement pas l'usage de cet outil, je considère que c'est une bonne chose qu'il soit arrivé: même si ça génère un bruit monstre, un coup de pied dans la fourmilière Linux à plus de chance d'améliorer les choses que le contraire: dans le pire des cas, des distros seront forkées, et que le meilleur gagne.

C'est un format qui est nativement […]

Accessoirement, c'est surtout un format qui est réellement lisible par l'homme, tous les hommes, y compris ceux n'ayant pour eux qu'une simple curiosité (mais pas de connaissance réelle de l'informatique).
C'est également un format efficace, tant au niveau de la mémoire (et je parle à la fois de la RAM et du stockage ici) que des performances CPU: il suffit d'un simple scanf pour parser une ligne d'un fichier INI, contrairement aux langages véritable horribles que l'on voit fleurir: XML, JSon, pour ne citer qu'eux.
Enfin, je trolle sur ces techno, mais en fait je ne le pense pas, pas complètement du moins. Je pense juste qu'ils sont mal utilisés 80% du temps.
Quant aux logiciels qu'il faut configurer via un langage de script, comme l'ancien init (auquel je reste, mais pour des raisons différentes: j'aime les choses qui ont un couplage faible avec le reste du système, ce que systemd n'est pas. Entres autres.) ils sont probablement l'une des raisons pour lesquelles un certain nombre de personnes pensent que Linux n'est pas prêt pour être utilisé par Monsieur tout le monde sur un PC.
Ben oui, quand il faut apprendre un langage à la syntaxe à la con (avouez: la gestion des chaînes de caractères est loin d'être triviale en shell, sans parler des nombres. Et ce ne sont que des exemples, qui n'aident pas la lisibilité selon moi.) afin d'être capable d'analyser le code existant, dispatché dans de nombreux fichiers eux-mêmes disséminés dans l'arborescence, gérant toutes les situations de tous les systèmes possibles, ce n'est pas une aide, mais une gêne.

Même si je n'apprécie pas systemd, il faut lui reconnaître ça: c'est pour un béotien un vrai bonheur de lire les fichiers de configuration de systemd, comparé aux scripts shell de sysV.

Surtout que, bah, j'ai du mal à voir ce qu'on peut reprocher à Intel dans le libre, j'ai l'impression (mais je me plante sûrement, je n'ai jamais fouiné de ce côté là) que les firmware que j'utilise pour leurs produits sont dans le repo non-free. Et désolé pour les anglicismes, que je vais jusqu'à abréger.

Oui. En 1998-1999 quand j'ai commencé c'était clairement moins facile à utiliser que 98 ou XP, en 2014 c'est beaucoup plus simple et ergonomique que 8.

J'en doute… XP n'étant sorti qu'en… 2001?

Bof… le jour ou on me diras en face qu'un système est choisi uniquement pour des raisons purement (j'insiste) techniques dans le milieu pro, je pense que je faire deux choses: demander des preuves, et comme il n'y en aura probablement pas de convaincantes, trouver un moyen de tourner au ridicule l'assertion première de mon interlocuteur.

Pour moi, on choisit un système en fonction, dans l'ordre:

• de la résistance au changement des équipes
• de la compétence actuelle des équipes
• de la réputation du système et des goûts personnels du DSI
• du prix

Les caractéristiques techniques… je pense qu'un Windows bien reconfiguré peut être sûr. Qu'un Linux mal configuré est un vrai gruyère. Même si, à l'époque de XP, par défaut Windows était un gruyère, ça ne veut pas dire que ce n'était pas sécurisable (commencer par virer/désactiver les services inutiles --type accès à distance au registre, notamment-- et désactiver le partage administratif sur C: étant un bon début).
Si ce n'était pas le cas, je ne crois pas que quasi tout le monde tournerait avec des OS qui nécessitent plus de 1Gio pour faire du traitement de texte, quand des systèmes tout aussi modernes sont capable de fournir la fonctionnalité utilisée par 80% des gens avec moins d'1 Gio. Entres autres.

Tu as vraiment pris au sérieux un journal dont le titre contient "aujourd'hui c'est permis" ?