Anonyme a écrit 62265 commentaires

Tout ce que je dit est que j'ai un système qui fonctionne très bien sans systemd, et que je ne vois par conséquent aucun avantage à changer de système d'init pour un autre qui a autant de bugs. Je ne parle pas que des forums, mais aussi des bugzillas. Je ne sais pas si le record est battu, mais je sait que systemd est parmi les programmes qui ont vraiment beaucoup de bugs. C'est un fait, alors qu'on arrête de nous vendre ce truc comme un programme stable et bien testé.

C'est pas un fait, on ne sait meme pas de quels bugs tu parles. Si ca se trouve ce sont juste des problemes mineurs, des fonctionnalités avancées en cours de developement, ou des cas particuliers qui ne fonctionnent pas non plus avec l'ancien systeme d'init.

https://bugzilla.kernel.org/ a 1746 bugs ouverts actuellement. C'est pas pour ca qu'on peut dire que le noyau Linux n'est pas un OS stable et bien testé.

Si au lieu de te baser sur de vagues recherches google tu l'utilisais vraiment avant de parler de sa stabilité ?
Moi j'ai pas besoin d'une recherche google pour voir qu'il fonctionne sans problème particulier sur toutes mes machines ou il est installé.

Je n'aime pas systemd. On met un bout de texte dans un fichier de configuration, et le truc fait de la magie et voilà. Il faut juste faire confiance. Ceci dit, systemd est loin d'être le seul à faire ça (penser à mount et fstab par exemple).
Moi, j'aime bien contrôler. Avec des scripts shells, c'est exactement ça qu'on a : Le contrôle.

Non, tu n'as pas non plus le controle. Avec ton script shell, tu mets des commandes dans un fichier, et le truc fait de la magie et voilà. Ton shell va executer des commandes, mais tu ne sais pas trop comment, quelles seront les instructions assembleur, les appels systeme, les fichiers ouverts, etc … Il faut juste faire confiance.

Si tu veux vraiment le controle, le plus simple c'est d'ecrire ton programme sur des cartes perforées. Et non pas avec une boite noire tel qu'un editeur de texte ou tu n'as aucun controle sur ce qui est vraiment ecrit sur le disque ! Sans parler du systeme de fichier à qui l'editeur de texte doit juste faire confiance: un empilement de boites noires sur des boites noires ! Une fois que c'est fait, le mieux ensuite c'est d'executer les instructions dans ta tete. Ne surtout pas passer par une boite noire comme un microprocesseur qui execute des instructions sans que tu saches vraiment comment.

Ça en fait des raisons largement suffisantes pour expliquer sont adoption massive, sans avoir à aller chercher des raisons comme « maintenir des scripts shell c’était trop dur », tu ne penses pas ?

Ca n'est pas la seule raison, mais ca fait partie des raisons frequement citées.

Oui il existe un doc complète. Le problème n'est pas là. Le problème pour comprendre systemd est que ce logiciel évolue à toute vitesse et que pour le comprendre et suivre cette évolution, il faut être un développeur payé à plein temps pour ça.

Tout comme le noyau linux qui evolue tout le temps.

Une autre conséquence de cette évolution rapide est que ce logiciel est tous sauf stable et bien testé. Il s'agit au mieux d'un soft de qualité béta.

Tout comme le noyau linux.

Et sinon tu es tombé sur des vrais problemes de stabilité ou tu dis juste ca au hasard ?

Linux, bloat ? Va falloir me le démontrer ça. T'a un noyau avec moins de ligne de code compilées avec à peu près autant de fonctionnalités à proposer ?

Minix par exemple a beaucoup moins de lignes de code que Linux. Et la difference du nombre de fonctionnalités entre Minix et Linux doit etre à peu près comparable à SysVinit et systemd.

Et la qualité du code est incomparable avec systemd ou la plupart des autres logiciels que tu utilise.

Tu te bases sur quoi pour juger la qualité du code de systemd ?

La charge de travail de quoi ? De l'écriture du script d'init ? Désolé mais elle reviens à l'auteur upstream du démon qui doit fournir un script LSB (sous Linux). Libre aux distributions de patcher ce script si elles veulent améliorer les choses.

Oui, en théorie, "il suffit de" prendre le script fait par upstream, et tout fonctionne parfaitement sans jamais aucun probleme.

Tout comme il suffit de faire "./configue; make; make install" pour installer n'importe quel programme. Tout fonctionne, il n'y a jamais aucun probleme de compilation, d'incompatibilité avec une lib ou autre. En theorie.

En fait c'est vraiment simple de créer une distribution. En theorie il n'y a rien à faire, tout est fait par upstream.

Et après ca ils viennent nous parler de charge de travail, quelle bande de faineants !

Au fait, tu as deja maintenu un paquet avec un script d'init dans une distribution ?

pourquoi ils n’ont pas choisi un de ces projets il y a des années ? parce que le bash de 2009 était maintenable mais le bash de 2014 ne l’est plus ?

Peu etre par ce que ces projets avaient d'autres problemes ?

pourquoi slackware, maintenu par une seule personne donc en première ligne pour les questions de difficulté de maintenance, veut retarder le plus possible son adoption ? masochisme ?

Par ce qu'un systeme de boot ca ne se change pas en 5mn, et donc on ne peut pas s'attendre à ce que 100% des distributions migrent tout de suite. Je trouve ca deja impressionnant le nombre de distributions ayant migré en si peu de temps.

pourquoi les BSD n’abandonnent pas les initscripts si c’est une telle charge de travail à maintenir ?

Peu etre par ce que systemd ne fonctionne pas sur BSD, et par ce que personne n'a encore pris le temps d'implementer un equivalent ?

Vraiment, j’aimerais que tu m’expliques comment tu arrives à réconcilier ta théorie « les distribs migrent vers systemd parce que les .unit c’est plus maintenable que des scripts bash » avec ces faits.

Il te faudrait quoi ? Que 100% des distributions l'aient fait ?

Il ne t’est pas venu à l’esprit que ceux qui ont décidé de passer à systemd l’ont fait pour d’autres raisons que « c’est trop dur de maintenir des scripts shell » ?

Tu veux dire qu'ils mentent quand ils donnent ca parmis leurs raisons pour le faire ? Et qu'ils ont d'autres raisons cachées ?

Donc pour résumer, systemd c'est nul, ca fait trop de choses donc c'est du bloatware. Mais par contre system-networkd c'est nul, c'est pas assez du bloatware, ca ne fonctionne qu'avec un systeme de boot particulier sous pretexte de simplifier les choses.

En terme logiciel on appelle ça du bloat et du code non-maintenable. Et oui, c'est une critique parfaitement valide: si un logiciel qui est censé fournir une fonctionnalité simple se retrouve à être un monstre de complexité incompréhensible par un non-spécialiste parce qu'il fourni une masse de fonctionnalité en un bloc qui ne sont pas utiles pour tout le monde, alors oui il y a un problème.

Tu veux parler du noyau Linux par exemple, avec ses milliers de drivers et options qui ne sont pas utiles pour tout le monde ?

Et sinon booter une machine ca n'est pas "une fonctionnalité simple".

Parce que avant, n'importe quel développeur pouvait se lire la doc d'inittab et les scripts d'init de son système (ou du système des autres) et comprendre immédiatement ce que est censé faire son système quand il boote. Il pouvait aussi lire le code du processus PID 1 qui n'est pas très gros. Certes ça ne lui servait pas à grand chose parce que ça faisait exactement ce qui était écrit dans la doc et ce qui pourrai être dans l'imagination du développeur si c'était lui qui devait le programmer.

C'est une blague ? J'ai jamais vu de doc correcte pour l'ancien systeme d'init, et lire du vieux code shell plein de hacks n'a rien de simple. Maintenant avec systemd il y a plein de doc très bien faite et generalement pas besoin d'aller lire le code pour comprendre comment ca marche.

je te dirai bien de faire quelques bidouille genre changer d'init, relancer TTY, mais :
j'ai sous ma responsabilité
ca n'incite pas a testouiller des trucs. Décharger le module matrox (gma de memoire) ou le relancer me parait le plus propre dans un premier temps.

lsmod et
man modprobe

personnellement je ne le ferais pas sans avoir prévu un redémarrage au cas où ca foire. Tant que ssh fonctionne, je n'y toucherai pas.

Celle-là ?

Hi

When Len and I created the Full-Disclosure list way back in July 2002,
we knew that we'd have our fair share of legal troubles along the way.  
We were right.  To date we've had all sorts of requests to delete 
things, requests not to delete things, and a variety of legal threats 
both valid or otherwise.  However, I always assumed that the turning 
point would be a sweeping request for large-scale deletion of 
information that some vendor or other had taken exception to.

I never imagined that request might come from a researcher within the 
'community' itself (and I use that word loosely in modern times).  But 
today, having spent a fair amount of time dealing with complaints from 
a particular individual (who shall remain nameless) I realised that 
I'm done.  The list has had its fair share of trolling, flooding, 
furry porn, fake exploits and DoS attacks over the years, but none of 
those things really affected the integrity of the list itself.  
However, taking a virtual hatchet to the list archives on the whim of 
an individual just doesn't feel right.  That 'one of our own' would 
undermine the efforts of the last 12 years is really the straw that 
broke the camel's back.

I'm not willing to fight this fight any longer.  It's getting harder 
to operate an open forum in today's legal climate, let alone a 
security-related one.  There is no honour amongst hackers any more.  
There is no real community.  There is precious little skill.  The 
entire security game is becoming more and more regulated.  This is all 
a sign of things to come, and a reflection on the sad state of an 
industry that should never have become an industry.

I'm suspending service indefinitely.  Thanks for playing.

Cheers
- John

tiens vous savez comment cela se prononce huawei ?

ouawail

Aller hop, un sac de terreau, des semences (si possibles non stériles tiens !), Tomate et zou :)

prenons ma dernière facture réel de 885€

total de votre consommation d'électricité : 466 € dont 163 € acheminement

soit 303€ de consommation, jusque la tous va bien tous correspond avec tes chiffres. Je pense que tous le monde sera d'accord sur le fait que l'acheminement ce n'est pas de l'electricité.

heure pleine : 6000

ah oui merde ca fait 0,14, bon ok le fait que je paye 885€ pour 300€ consomé m'avais hautement surpris, d'ou le raccourci de mon poste plus haut sans prendre le temps de le faire a tête reposé

merci de m'avoir ouvert les yeux !

le prix du Kwh est pas trop chère en france, mais ils en profitent pour mettre plein de taxe à la con :)

pour mon exemple : je paye 800 € / an a EDF sur ces 800 € j'ai 400 € de taxe diverse et varié et la tva sur tous cela :D

en 2011 pour la france : 0,142
pour l'allemagne : 0,253

source :
http://epp.eurostat.ec.europa.eu/statistics_explained/index.php?title=File:Half-yearly_electricity_and_gas_prices,_second_half_of_year,_2009-2011_%28EUR_per_kWh%29-fr.png&filetimestamp=20130923111451

au finale ce que je paye c'est plutôt proche de 0,30 :(, avoir le Kwh le moins chère Europe c'est un blague je m'en fous un peu si j'ai 300 % de taxe dessus !

d'ailleurs je trouvais réellement bizarre tous ce gargarisme du Kwh le moins chère dans notre pays ou rien n'est pas chère !

sinon dans les salles d'attentes dans les urgences, ca a pas mal de succès, sa change de gala, voici etc … tous ceux que j'ai déposé disparaissaient petit a petit.

LUTim, pardon :)

parser != ecrire.

Ecrire du XML sans utiliser une lib faite pour ca, ca se fait sans problème. Le parser non.

C'est surtout rigolo de voir à quel point il peut être utilisé à outrance dans des cas où d'autres formats plus simple (un fichier ini par exemple, qui je rappelle n'est pas un gros mot) aurai rendu la chose plus facile.

Un fichier ini, c'est un peu limité quand meme, meme si parfois ca suffit. En general je préfère un fichier YAML, ca reste simple et lisible par un humain. Et c'est suffisement évolué pour permettre de serializer à peu près toutes les structures de données possibles dans la plupars des languages.

tiens ca me fait penser a ceux qui code par chez moi :D

C'est pas faux.

**meaningless** jumps or gotos

Un if/elsif/else peut tout autant être meaningless qu'un goto… tout comme un goto peut être correctement utilisé. Suffit de ne pas vérifier les bons éléments :D

Par contre comme il n'y a plus de sous, nous recréons un puits sans fond pole d'exellence, cluster de champion français innovant pour être le leader mondial de la robotique. La France rayonnera de son savoir faire.

J'y pense juste maintenant, ce n'est pas ce qui c'est passé avec airbus et le TGV ? ne jetons pas toute l'eau du bain avec le bébé.

Je n'ai rien pour ou contre 'systemd', je veux juste conserver ma liberté de choisir ce qui me va le mieux indépendamment des autres briques logiciels que j'ai sur ma machine.

Tu es libre d'essaier de faire fonctionner ces differentes briques entre elles, voir que ca ne fonctionne pas et faire le travail pour que ca puisse fonctionner, mais pas d'imposer aux developpeurs de faire ce travail pour toi si ils n'en ont pas envie.

Peu importe qu'ils hebergent des noeuds ou pas en fait.

Si la question est de savoir si la NSA peut voir le contenu des connections non chiffrées, la réponse est la meme qu'on utilise tor ou pas, il y a une possibilité importante que oui.

Si la question est de savoir si la NSA a la possibilité de savoir de qui provient une connection ou ce que fait une personne, personne ne peut le dire avec certitude (en dehors des gens qui travaillent la bas), mais les documents de Snowden semblent plutot indiquer que cela leur pose de gros problemes pour le faire quand la personne utilise tor.