moi1392 a écrit 740 commentaires

J'espère pour toi que tu plaisantes…

C'est n'était absolument pas le point important de ma réponse… même si au passage il reste entièrement vrai :
je ne connais aucune version sortie de Debian qui ait des clés ssh non aléatoires…
Blâmer une version de développement en informatique, c'est un peu limite pour un informaticien, déjà que même les version .0 et les premiers patchs sont souvent évités par ceux qui recherchent la stabilité (en terme de fonctionnement) et la sécurité.

Quand ça arrive sur du libre, "ouais, c'est corrigé dans le SVN, alors n'en parlez plus"
Quand ça arrive au non libre : "c'était il y a 5 ans, mais parlons en, c'est horrible".

Deux poids, deux mesures.

Pareil, je parle ici de culture de développement d'un boite.
Quand tu parles de libre du parle de quel projet ??
Moi j'en connais qui sont archi nuls en terme de sécurité, d'autres en terme de stabilité, d'autres en terme de consistance, et d'autres qui sont très bien. Et c'est souvent assez constant sur ces projets, il faut pas mal de temps avec le renouvellement d'une bonne partie des équipes de développement pour que ces cultures de développement évoluent au sein de ces projets.
En tant que développeur, qui en plus suis un peu l'actualité du développement de logiciels, tu devrais savoir ça.

Je pense qu'ils ont compris que c'est LE tourant qu'ils ont raté jusqu'à présent et qu'ils ont intérêt à prendre s'il ne veulent pas finir comme une "grosse boite d'informatique" comme les autres.

À mon avis, l'IHM classique va arriver pour les versions professionnelles (de toute façon, les pro ne mettrons pas à jour avant quelques temps) mais le plus important pour eux et de mettre en avant de toutes leurs forces un message du genre "regarder, on est super prêt et super au point pour les tablettes et le téléphone, viendez tous bosser avec nous, ça va être super, et les gens achetez chez nous, c'est trop bien on fait plus que ça maintenant, promis on vous jure et même que si on ment, apple et google vont en enfer !"

Et c'est un peu normal de leur point de vue je pense, s'ils ratent ça et que ça prends mal, dans 4 ou 5 ans ça ne sera plus un des acteurs majeur de l'informatique.

peut-être..

Mais premièrement, je ne connais aucune version sortie de Debian qui ait des clés ssh non aléatoires…

Et surtout, deuxièmement, c'est plus un symptôme de la culture du logiciel ce qui est décrit.
Evidemment que quand un gros soucis arrive, il peut-être reglé rapidement et on fait taire les détracteur à coups de "Mais c'est reglé depuis 1948 alors t'arrêtes spaice de méchant troll avec des poils dans les nœils !"
Mais la culture de développement d'une grosse boite, ça ne se change pas à coup de fixes sur les problèmes, fussent-ils fixés depuis longtemps.

L'idée est compréhensible et j'adhère dans la théorie (l'extension est du détail technique)

Pas moi, l'idée de se servir de l'extension, et donc d'une partie du nom du nom du fichier, pour décider de quel type il est et avec quel logiciel il faut essayer de le traiter est une très très très très très mauvaise idée !

la commande file est le type mime sont des contournement passables, mais la vrai solution serait des méta données associées au fichier, que ça soit par le biais du système de fichier ou d'un service externe qui gère des méta données.

Et au final on se retrouve avec des systèmes qui cachent l'extension à l'utilisateur, donc une partie du nom de leur fichier, une mauvaise solution pour résoudre un mauvais problème…

Ça change effectivement la donne.
Après on peut toujours rêver un peu :)

Je me mets à la place d'une organisation commerciale, j'ai le choix entre une population aisée et compulsivement acheteuse, et une autre, sans doute moins nombreuse et plus qu'habituée au gratuit, je n'hésite pas beaucoup.

La différence importante dans ce cas là est la produit vendu :)
Les acheteur mac aiment ce qui est récent, kikolol et qui coute cher !
C'est pas dit que tu y trouveras plus d'acheteur de vieux jeux de la fin des années 90 que sous linux.

moi je viens de voir pas mal de jeux bullfrog.
Que de souvenirs, je les acheterais sans hésiter s'ils devaient être porté sous linux :)

Ça a l'air sympa à première vue, mais en fait, ça ressemble beaucoup aux éditeur html qu'on a vu pendant longtemps (dreamweaver et autres).
Et on est sacrément revenu dessus.

Pour moi ça reste limité à des sous-sous domaines très particuliers qui de toute façon ne se font pas en c++ et on déjà des éditeurs dans le genre très évolués (flash par exemple)

Le seul cas pratique que j'y vois, c'est le test rapide d'une petite fonction utilitaire qui prends des paramètres simples sans avoir à écrire un petit binaire complet. Et ça, c'est la merde sous windows peut-être, mais sous linux, écrire un main avec un appel et le compiler, ça me prends 30 secondes avec un pattern que j'ai.
Parce que tester avec des fonctions qui prennent des paramètre super complexes, il va falloir écrire le code qui fait le rendu de ce paramètre, et qui sait le créer et modifier ses valeurs.
Et souvent, le plus dur, c'est d'imaginer ce que ça va être ce code, et on se rends compte que dans 80% des cas, le code en question, et bien on est en train de l'écrire, c'est l'appli qu'on fait… Donc s'il faut écrire l'appli pour pouvoir écrire plus facilement l'appli, on avance pas des masses.

les dernières info de marseille

-quand on coupe la tête des dirigeants !

comme Richard Cochien ?

En français, le "/" signifie le choix exclusif entre plusieurs alternatives.

Dans le cas présent, si j'ai bien compris, il s'agit d'un animal qui serait à la fois un cochon et un chien, et pas soit un cochon, soit un chien, donc cochon-chien et pas cochon/chien.

Ça ne m'a pas fait peur ;) d'ailleurs je l'ai fait.

Mais j'ai trouvé ça compliqué et lourdingue !
De mon point de vu de développeur, c'est vraiment mal fichu !!
Mettre du code (script bash) dans de la config (ce qui doit être démarré, où et comment), je trouve ça très pourri comme design.
Après, peut-être que pour les adim de machine, c'est indispensable, mais j'aurais plutôt tendance à penser que c'est parce que le système d'init est très très incomplet, mal fichu et mal pensé, donc il délègue la complexité sur les fichier de config en les laissant gérer eux même la façon dont ils veulent faire les choses.

En tous cas, quand je code, la config, c'est de la config, il n'y a aucune logique dedans. Ensuite, l'appli lit et interprète la config, c'est elle qui sait comment bien faire les choses ! Séparer la logique des données est un concept de base dans le design d'un logiciel chez moi, et à chaque fois que j'ai prototypé un truc à la va vite et que je ne l'ai pas fait correctement, j'ai du revenir dessus par la suite.

McCann, c'est ceux qui en parlent le plus qui en codent le moins ???

Je la maintiens à jour, de la à me considérer comme un administrateur…

ça j'aurais pu le faire avec le démarrage de ma session.
les 2 soucis que j'ai c'est que :

1) je veux que ça tourne même quand je ne suis pas logué

2) mon jouet lance certaines commandes depuis des requêtes sur le réseau, et pour lancer ces commandes il faut être root. (c'est pas sécurisé, plein de buffer overflow et autres joyeusetés…) donc à lancer en root.

Donc je n'ai pas trouvé d'autres moyens que de la lancer avec un script de démarrage.

Mais si tu veux changer ton pot… tu vas chez le garagiste.

Si je n'ai pas d'autre choix que d'aller chez mon garagiste pour changer mon pot de voiture, c'est qu'il y a un problème de conception de ma voiture.

Par contre, je peux décider d'aller chez mon garagiste changer mon pot car c'est plus pratique, simple, je trouve préfère payer le prix que de m'embêter à le faire moi même, …

Mais quand je transpose ça au problème systemd, ce que j'en pense c'est qu'il doit être possible de faire ce que l'on veut (c'est une des choses que j'aime le moins dans les logiciels et systèmes non libres), et que c'est mieux si c'est simple à faire, et c'est ce dernier point qu'il est important de discuter.

Donc j'oubliais, faire un case $1, et faire 3 lignes de commentaire à la bonne syntaxe (en s'inspirant d'un autre script par ex) , si tu trouves que c'est vraiment trop dur arrête l'admin système.

Et bien quand je l'ai écrit, ça c'était pas le cas. Car oui, je me suis bien inspiré des autres scripts.

Et je me considère toujours comme un utilisateur et pas un administrateur. Il se trouve que je suis aussi un développeur et j'ai j'ai codé un petit jouet que j'ai envie de démarrer sur ma machine.
Ça n'est pas un service ultra perfectionné de luxe (même si dans le principe, ça reste un service qui attends des requêtes depuis mon réseau interne)
Et je continue à trouver ça trop compliqué.
Un simple "lance cet exécutable avant le prompt de login" est suffisant pour moi, et ça devrait être une des fonctionnalité simple à utiliser d'un système de démarrage.

oui, 3 lignes de commentaires en plus.

C'est vrai que je n'ai jamais pris le temps de voir ce qui lui manquait, donc quelque part, c'est de ma faute, mais j'ai mis ce point pour souligner que ça n'est pas "3 lignes de script" mais plus que ça ! Et aussi que ça n'est pas si trivial que ça, avec des parties non cohérentes (entête non interprété par le shell dans un script shell)

Si tu étais utilisateur, tu n'aurais pas le droit de modifier ces scripts.

Si j'avais pu faire démarrer mon utilitaire sans avoir à ajouter un script, je l'aurais fait avec plaisir. C'est le système qui me force à cela.
Moi j'aurais aimé un outil avec une syntaxe du genre :

"#>execute_ce_binaire_au_démarrage_de_la_machine --c_est_un_demon_alors_inutile_d_attendre_qu_il_termine --si_tu_peux_le_relancer_quand_il_plante_ça_m_arrangerait /chemin/vers/mon/binaire"

Et il se serait chargé de créer la config qui va bien pour ça.

avec des commandes qui me disent ce que est déjà dans la liste de lancement (pas tous les services, mais juste ceux que j'ai ajouté via cette commande), ceux qui tournent, me permettre de les arrêter, les relancer, de les virer.
J'ai l'impression qu'il y a presque tout déjà, mais qu'il faut un enrobage énorme de shell autour et que le binaire en question ait quelques bons goûts dans sa façon de fonctionner pour que ça se passe comme on veut.

Au fait, ma machine (principale) n'est pas pétée au bout de 6 mois ! je ne l'ai réinstallée qu'une seule fois récemment pour passer en arch amd64.

parce qu'un script qui est distribué dans une distrib a certaines règles a respecter pour s'intégrer correctement (par exemple que tous les scripts aient les mêmes jolis "ok" vert, et pas l'un entre crochet à la fin de la ligne, l'autre après un saut de ligne, un autre sans ok vert etc…)

La complexité pour ces choses ne devrait pas être dans les script, mais dans l'init.
En tant que développeur, si je veux que tous les utilisateurs de ma lib se comportent bien, je ne leur laisse pas la possibilité de mal se comporter.
C'est un peu comme les histoires de mutlitâche préemptif et coopératif, on est bien d'accord que le coopératif est une vaste fumisterie…

Tes infos datent un peu, aujourdh'hui on a les en-têtes de méta-infos LSB pour indiquer les dépendances et les niveaux d'exécutions où il doit être démarré et arrêté. Les liens sont créés par update-rc.d

Ha oui, je viens de voir ça.
Mais pourquoi des liens sont toujours crées si les niveaux d'exécution sont spécifiés dans l'entête ?

Non. On ne relance pas tout.

Alors si je ne dis pas de bêtises. Quand je suis en runlevel 2, si je fais init 3, j'appelle tous les scripts qui sont dans rc2.d avec le paramètre "stop" puis ceux de rc3.d avec le paramètre start.

En sachant que si je fais ça, c'est que généralement, j'ai un ou deux services qui changent, donc 95% des services sont identiques.
C'est pas super génial comme idée je trouve. Le mieux aurait été de n'arrêter que ceux qui sont dans 2 et pas dans 3 et de ne démarrer que ceux qui sont dans 3 et pas dans 2.
C'est possible de faire ça ?

ah c'est compliqué un script qui fait un case sur $1 et qui gère "start" et "stop" ?

Figure toi que j'en ai un qui fait "juste" ça.
Et qu'à chaque mise à jour de init-je-sais-plus-quoi sur ma debian, j'ai des warnings m'indiquant que le script de démarrage n'est pas LSB compliant, que c'est mal (tm) et qu'à cause de ça, il ne peut pas passer à un système d'init basé sur des dépendances qui est trop bien.

Donc même si c'est pas compliqué, ça reste pas suffisant pour avoir un truc propre dans ton démarrage.

Ensuite, change l'administrateur… Ça aurait pu être là solution, s'il y en avait un. Moi, je suis utilisateur de ma machine.

Dernier point, si c'est si simple et si facile, pourquoi les scripts de démarrage sur ma machine font-ils tous en moyenne 100 lignes (ça va de 33 à 408 !!) Et en plus avec des paramètres dans des fichiers extérieurs (ce que je comprends très bien, mais ça fait des lignes en plus et c'est pas toujours évident à trouver)

On te répondra certainement que c'est parce que le système actuel est parfait

Perso, je l'ai toujours trouvé ultra pourri le système d'init actuel…

Il a quoi de si génial ?
Pourquoi, si je veux juste démarrer un truc avec ma machine, il faut que je fasse un scripte qui gère 5 (ou 6 ?) paramètres différents (start, stop, restart, …) et en faire des liens complètement abscons dans d'autres dossiers avec comme seul ordre pour déterminer à quel moment il sera exécuté….. l'ordre alphabétique du système de fichier ??????

Ensuite, c'est quoi ces histoires de runlevel à la con ??? géré par des chiffres qui n'ont aucun sens ? (différents entre les distrib au passage) et limité à 9 en plus (d'ailleurs c'est vraiment limité à 9 ou c'est juste mon impression ?) ???
Et pour le passage de l'un a l'autre, on coupe tout et on relance tout ?? ça serait pas possible de juste gérer le delta ??

Et un point marquant que je lui trouve, c'est qu'il y a des différence notables entre chaque distributions sur comment il fonctionne. C'est bien qu'il y avait des problèmes à la base, et que chaqun ait ses propres solutions, c'est bien que la solution n'est pas simple.

Et j'effleure juste la surface en tant qu'utilisateur de ma machine là.

Je sais pas si systemd est bien ou pas, mais l'init actuel, pour moi, il est juste vraiment moisi…

Merci :)

oui, x86-32 serait plus correcte.

Et dans l'exitation du message, j'ai même oublié de parler de la référence à windows 9, et j'ai laissé une coquille…
à un fils -> a un fils caché (a sans accent)

Puisqu'on parle de téléphone, moi sur mon téléphone précédent j'ai aussi une "fonctionnalité" d'ingénieur qui n'a sûrement jamais utilisé son téléphone.
Le système permet d'enlever le jingle d'allumage, mais pas celui d'arrêt.

Super pratique quand t'es en meeting, que t'as oublié de la sortir de ta poche et que tu veux le couper discrètement… Alors que généralement, quand tu l'allumes, c'est que tu acceptes d'être dérangé, donc ça devrait être moins gênant de ne pas pouvoir enlever celui là.

sarge en testing pour moi, c'était en 2003 si ma mémoire est bonne.

Depuis, je ne l'ai réinstallé qu'une seule fois (sur ma machine fixe perso), pour mon passage de x86 à amd64

Au passage, c'est à cause de la fin de la version d'essais d'un logiciel propriétaire sous windows que j'ai complètement basculé :)
Le parefeu que j'utilisais ne faisait plus partage de connexion internet au bout de trois mois, et la freebox v1 que j'avais, ne le faisait pas non plus.
Qui a dit que c'était pourri les shareware :D