xcomcmdr a écrit 3537 commentaires

En C#, on peut spécifier qu'on a un object (mais ça reste du typage statique -> vérifié par le compilateur), ou utiliser un type dynamic dont les appels sont résolus à l'exécution (grâce au Dynamic Language Runtime).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

le mariage n’est historiquement pas un privilège ni un symbole, mais une somme de devoirs et de contraintes visant à assurer non pas le bonheur des contractants, mais la survie de l’espèce

Et c'est bien pour ça que le mariage entre personnes stériles est légale depuis longtemps et que personne ne s'en offusque.

Ou pas…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Mais pour le coup, c'est justement de ne pas avoir son propre serveur web qui est tellement minitel 2.0.

Tu me paies l'électricité ? Le matériel ? Le temps passé à configurer ? La connexion Internet ? Les sauvegardes régulières ?
Et puis l'onduleur, tiens !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est moins compliqué et bien plus raide de changer de bootloader dans l'interface EFI que de remettre "le bon MBR" avec un Live-CD.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

De nouveau, pourquoi ajouter une option qui va faire peur a plein de gens (ouh la, ca efface des trucs), et qui ne sert qu'a moins de 1% de la population ?

C'est pas comme si c'était la première fois :
- l'inclusion du clavier américain par défaut (à qui ça sert ? Et c'est super sympa de se retrouver en qwerty le jour où on fait sans le savoir la combinaison de touches pour changer de clavier)
- l'aide qui te demande nawak
- Word qui me pose une question WTF

Mais je suis d'accord, ça n'a aucun intérêt. Et c'est même une question obsolète si on a une table de partition GPT, où chaque bootloader va se mettre sur la partition EFI, sans gêner les autres.

Adieu le MBR de merde !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est tellement beau, j'en ai le clavier que se blo

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

La solution, c'est plutôt, lorsqu'on se prétend développeur, d'écrire un code propre et maintenable avant de diffuser.

Ouais, je suis sur que les premières versions de Linux étaient tout aussi propres et maintenables que le Linux d'aujourd'hui… ou pas.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Le code que j'écris fonctionne en général.

code qui fonctionne ne veut pas forcément dire code lisible.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Les perfs sont puissantes. :p
(ou pas)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

On peut toujours vouloir appeler une fonction sur un pointeur NULL parce qu'elle a des effets de bord

Ah, la programmation par accidents, c'est une bonne méthode de nos jours ?

Tout se perd…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Fredon

Frodo.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je croyais que la politique de Linux était de refuser les patchs introduisant des régressions?

C'est surtout de refuser les patchs qui cassent l'user-space.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

démontrez à un DEV que 80% des problèmes de perf se situe dans le traitement … pas drôle non plus (surtout s'il ne vaut pas comprendre)

Un dév qui ne sait pas ça, c'est un mauvais dév', désolé.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Faut arrêter de se voiler la face. La stratégie du Patent Troll qui a un budget infini pour les frais de justice et en profite, elle est connue.

Et quand on regarde ce sur quoi portent les brevets, n'importe quel OS est concerné, c'est démentiel. Bientôt, y'aura le brevet sur le double clic…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ouais, ou pas.

Barnes & Noble Exposes Microsoft's "Trivial" Patents and Strategy Against Android

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je confirme, Ruby a une approche différente de l'OO de celle de Python ou Java.

http://www.sapphiresteel.com/Ruby-The-Smalltalk-Way-3-The-World

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Tu juges le Windows d'aujourd'hui avec la branche 9X qui est abandonnée depuis 14 ans, c'est pas mieux.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Que certains préfère une solution plutôt que l'autre justifie-t-il de traiter les minoritaires de relou, réfractaire, etc. ?

Faudrait peut-être pas inverser la lecture du fil de discussion, là.

Le tout premier message dit en essence que systemd say-trop-complexe et oh-mon-dieu-où-est-la-doc

Et les fils de discussion de ce genre où les réfractaires :

• disent que systemd est bloated sans même aller voir le code et sans même se documenter un minimum (ils sauraient alors que systemd c'est un coeur + une soixantaines de binaires indépendants qui font une seule chose et la font bien),

• disent que systemd ne te donne aucune abstraction et que c'est pas bien (les targets, les fichiers d'unit, les utilitaires autour… ce ne sont QUE des abstractions !),

• disent que systemd te donne des abstractions, et que c'est pas bien,

• disent que systemd te donne une rétro-compatibilité avec les scripts et qu'alors systemd n'a aucun intérêt,

• que les failles de sécurité dans 3000 scripts, c'est moins grave que dans un seul systemd
  -_-' (le concept de surface d'attaque est inconnu au bataillon. Et c'est quoi le plus simple ? Corriger systemd une fois ou corriger chaque script ? Je vous laisse deviner),

• disent que systemd c'est une usine à gaz faite pour le desktop - mythe N#7, sauf que systemd fonctionne très bien sur un système embarqué(mythe #7 encore), et que le premier client de systemd c'est RedHat qui n'est pas vraiment connu pour ses parts de marché dans le domaine du PC grand public,

• inventent des cas d'utilisation irréalistes de SysV pour rejeter systemd s'il ne sait pas les gérer,

• disent que les targets et le runlevels c'est du pareil au même (alors que justement les runlevels c'était de la merde parce que c'était différent selon la distro),

• disent qu'il n'y a pas de doc (alors qu'il y a bel et bien une doc', et bien longue en plus), et que SysV est documenté (QUOI ?),

• en veulent personnellement à Lennart Poettering,

• disent que les scripts éparpillés partout qui répètent de la logique entre eux on s'en fout (et le principe DRY, alors ? C'est pour les singes ?),

• disent que systemd est une boîte noire (un logiciel libre, bien écrit, et bien documenté, c'est une boîte noire !),

• disent que les mainteneurs de distro qui ont choisi systemd ne font que suivre la mode

• …

Y'en a plein linuxfr Internet.

On a aussi souvent droit sur linuxfr aux "arguments" suivants (liste non-exhaustive) :

• systemd c'est une tentative de contrôle des distributions tierces de la part de RedHat

• systemd c'est un enfant du syndrome NIH (bah voyons)

• Un des principaux objectifs de systemd est un boot rapide et qu'on s'en fout d'un boot rapide (alors que ce n'est qu'un effet de bord de la manière dont systemd fonctionne)

Je sais pas, un moment, il faudrait se renseigner un MINIMUM sur systemd pour pas passer totalement pour une bande de personnes qui ne savent pas du tout de quoi elles parlent ! Ou alors, dire clairement qu'on est là pour le troll.

Et l'analogie ci-dessus fonctionne mieux que tu ne le penses: il y a beaucoup de cas d'utilisation d'un IDE qui sont juste impossibles avec un éditeur de texte (refactoring qui touche plusieurs projets, par exemple).

Il y a aussi beaucoup de cas (comme lancer/arrêter les services en réponse à un évènement - connexion Internet trouvée/perdue par exemple -) qui sont juste impossibles ou trop complexes avec SysV.

Ce n'est pas qu'une histoire de style (cf. fichiers "à la ini" VS "scripts sh").

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Tu as regardé dans les extensions ? le about:config ? Et le mode plein-écran (F11) ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je dirais plutôt assez sûr et pas depuis longtemps.
J’ai lancé l’arrêt d’une Fedora 17 un soir, le lendemain elle était toujours bloquée en cours d’arrêt…

Fedora 17, ça date de mai 2012. Bref, ce bug, c'était sur les vielles, vielles versions de systemd. Ça ne m'est pas arrivé depuis très longtemps sous Archlinux.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

arathorn:~# man systemctl
No manual entry for systemctl

Euh…

max@max-laptop% man systemctl

SYSTEMCTL(1) systemctl SYSTEMCTL(1)

NAME
systemctl - Control the systemd system and service manager

SYNOPSIS
systemctl [OPTIONS…] COMMAND [NAME…]

DESCRIPTION
systemctl may be used to introspect and control the state of the
systemd(1) system and service manager.

OPTIONS
The following options are understood:
…

Donc bon, avant d'argumenter, sachez installer des paquets proprement… -_-

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

oui, les scripts Debian sont compatibles avec des distributions utilisant des scripts Debian, les scripts RedHat sont compatibles avec des distributions utilisant des scripts RedHat, et les scripts/unités systemd sont compatibles avec les distributions utilisant des scripts/unités systemd. Super.

Non, c'est plutôt :
1.Les scripts d'une distribution X ne sont pas forcément compatibles avec la distribution Y, voire avec la distribution X.VersionZ. Les unit files systemd sont écrits une seule fois par le projet upstream, et utilisés à l'identique par toutes les distributions compatibles (celles qui utilisent systemd, ou qui implémentent un équivalent. Après tout, ce n'est pas comme si les unit files n'étaient pas documentés)

2.Les scripts répètent de la logique entre eux, et n'offrent pas tous les mêmes compatibilités. l'un ne fonctionne pas avec SELinux, l'autre fonctionne avec AppArmor mais pas SELinux, etc… Tout ça est pris en charge par systemd.

3.Ah oui, on a arrêté les runlevels idiots avec des définitions différentes selon la distro pour utiliser à la place quelque chose de plus puissant et pour lesquels il n'y a qu'une seule définition : les targets.

4.Grâce aux control groups, quand on arrête un service, on est sûr et certain qu'il va s'arrêter. ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ben non.

Le principe avec les unit files de systemd, c'est qu'un seul fichier soit upstream, et que toutes les distributions utilisent le fichier fourni par upstream (cf. le(s) développeurs(s) du projet X qui en a besoin).

Et si c'était un script, on pourrait parler de souffrance. Avec les unit files de systemd, c'est plutôt une joie. ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

systemd est 99% rétro-compatible avec les scripts, hein.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Lire pour troller ? Et puis quoi encore ? Savoir argumenter, ne pas rester dans le flou, lire avant de cliquer sur "inutile" ou "pertinent" ?

Y'a que 24 heures dans une journée, naméo ! ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)