Si on suppose que les gens qui vendent des journaux le font en espérant toucher le public le plus large possible, alors je dirais que je n'ai juste jamais rien vu qui parle de slackware, a mettre en parallèle avec le fait que j'ai déjà vu des journaux parler de la famille BSD.
Le sentiment (ben oui, ce ne sont pas des chiffres, tout comme les chiffres de distrowatch ne concernent pas l'utilisation) qui s'en dégage, c'est que slack est ultra minoritaire en normandie et région parisienne (les lieux ou j'ai acheté ce type de magazines ces 4 dernières années).
Comme 10% ne me semble pas du tout ultra minoritaire, l'impression que j'ai est que ce chiffre est totalement faux.
Bon après, ma base de raisonnement est limitée dans le temps et l'espace, et je ne connais moi-même personne qui utilise linux au quotidien. Au niveau taf, les seules distrib que j'ai croisées sont Debian et CentOS, ainsi que Red Hat Linux en recherche d'emploi (pas croisée donc, mais a été mentionnée).
Si je m'en tenais a mon vécu "physique", slack n'existerait tout bonnement pas du tout, ce qui est évidemment faux. Par contre, même sur le net, on en parle quand même très peu, il y a peu de références à elle (comparé aux autres distrib linux et aux *BSD, hein).
mais c'est une question difficile.
Impossible, même. C'est impossible de chiffrer le taux d'utilisation d'une distrib gratuite au niveau mondial.
Oui. Le français actuel est mieux que ce que tu proposes.
Ce n'est pas parce que quelque chose est "novateur" que c'est mieux que l'existant.
Ah, et sinon, es-ce difficile à imaginer que les gens considèrent tes messages inutiles à cause d'arguments de qualité médiocres, d'insultes et de vulgarité?
la seule mention d'OS dans l'annonce, c'est Windows, c'est un peu mal barré.
En fait, c'est juste du dev sous windows, ce n'est pas que le nom de l'OS mais aussi de plusieurs techno citées:
VBA
crystal report
Ah, et je parie que le "C", en fait, c'est du C#: il y a le même syndrome sur pas mal de sites de recrutement… donc oui, ça va se faire défoncer et ce sera mérité, ça n'a juste pas sa place ici.
Si la parole est correctement distribuée, si le processus de prise de décision collective est bien pensé – ce qui suppose qu'il soit lui même régulièrement débattu — je n'y vois pas de problème.
Tu vas devoir définir "bien pensé" et "correctement distribuée". Dans ma phrase, j'ai parlé d'enfants ou de malades mentaux, ça aurait du te faire tilter: c'est quoi, un fou? A partir de quel moment quelqu'un n'est plus capable de décisions cohérentes?
C'est loin d'être simple, surtout que ça varie en fonction des gens.
La loi, comme l'élection, ne sont pas des nécessités selon moi. Simplement des "outils" de prise de décision.
A l'heure actuelle, je ne pense pas, de manière générale, l'être humain capable de prendre des décisions efficaces et non basées sur l'égoïsme. La raison principale selon moi est que je ne crois pas qu'il existe une seule démocratie dans le monde. S'il y en a une, je n'en ai pas entendu parler…
J'entend par démocratie le fait que la majorité du peuple puisse, par voie légale (et sans passer par les armes) changer les règles auxquelles il obéit à n'importe quel moment. Concrètement, sauf erreur de ma part, en France si la majorité du peuple dit non à une loi ou un décret, les élus n'ont pas l'obligation d'écouter: le peuple n'a donc pas le pouvoir, ce n'est pas une démocratie.
Mais pour être honnête, mon ressenti actuel est que l'idéal démocratique n'"existe" que dans l'idéal libertaire :)
L'idéal libertaire est compatible avec l'idéal démocrate, mais pas l'inverse, pour moi. Pour faire un parallèle avec les licences: tu peux inclure du BSD-2c dans du GPL, mais pas l'inverse.
Pour moi, la démocratie implique qu'une partie du peuple se plie aux décisions majoritaires. Après, le terme est très mal défini de base.
De ce que j'ai retiré de mes diverses lectures, ça semble offrir nativement le support du parallélisme et la gestion des dépendances.
Ces points sont 2 des points d'accroche initiaux de systemd selon moi, avec en bonus non négligeable la facilité de configuration (aka: possibilité d'éviter les scripts mais plutôt d'utiliser des fichiers de config plus traditionnels).
Je ne sais pas s'il y a d'autres points intéressants dans OpenRC.
Perso, j'ai plus été séduit par runit qu'OpenRC, la configuration est nettement plus triviale. En revanche, pas de gestion des dépendances, il faut le faire manuellement: soit un programme sait qui dépend de lui et créées leurs liens symbolique (ce qui serait une grosse galère à maintenir) soit un programme sait de quels services il dépend et attend gentiment que ceux-ci soient démarrés, par exemple en scrutant la création d'un fichier PID (a priori, simple à faire et à maintenir).
Ce qui est à la fois une bonne et une mauvaise chose. C'est une bonne chose parce que ça permets une meilleure intégration, et pour la majorité qui se contrefiche (avec raison) de la portabilité c'est juste positif.
il capture les logs beaucoup plus tôt dont certains qui étaient auparavant volatiles
Tu me réponds "tu parles de logs de services ?
Bah en gros j'essaie de comprendre comment il fait, et donc pourquoi ce serait infaisable par les autres. Tout bêtement. A partir de la, je pourrai ensuite vérifier que les autres ne le font effectivement pas.
Par exemple, si je te demande s'il fait en gros le même travail que klogd ( The klogd program will extract messages from the kernel log buffer ) mais dès le début, je me trompe ou pas? Ou est-ce qu'il utilise un truc plus bas niveau, ce qui serai impossible à d'autres qui refuseraient le code spécifique à un OS?
Après mon propos était de dire que, pour moi, les apports techniques sont bien évidement a prendre en compte,
Et sur ce point je suis d'accord. Chacun utilise bien ce qu'il veut.
journalctl, systemctl is-system-running, systemclt status xxx, systemctl --state=failed, systemctl edit xxxx, systemctl set-environment xxxx n'ont pas d'équivalent aussi puissant et simple.
Possible. Mais j'ai bien l'impression que systemctl status xxx à une variante pour les sysVinit. Pas sous Debian la (à mon grand regret) mais ça ressemble à services status xxx?
Pour systemctl --state=failed effectivement, en général je me fade une commande à rallonge, combo de grep et de redirection de stderr vers /dev/null.
Le reste, je ne sais pas, et/ou ne vois pas nécessairement l'utilité (différents usages, différents besoins).
La perte de diversité supposée
Ca, c'est une connerie: le fait de proposer un autre modèle augmente la diversité. Si d'autres projets meurent parce que plus utilisés et remplacés par systemd, c'est juste qu'ils ne sont pas assez efficaces.
SysVinit ne me manquera pas, et grâce à systemd j'ai découvert runit, qui à son tour m'a fait découvrir voidlinux.
Perso, j'y ai gagné, dans cette affaire. Je n'ai pas l'intention d'utiliser systemd, j'ai mes raisons, mais je sais que sans systemd je n'aurai pas fait ces recherches et je n'aurai pas appris tout ce que j'ai pu apprendre sur l'init.
Le coup du "c'est juste que vous ne voulez pas apprendre".
Effectivement, mais je ne fais jamais les mises à jour à la main mais j'utilise des outils comme "unattended-upgrades".
D'ac. Du coup, ça se passe comment si dpkg pose une question à l'utilisateur? Je n'ai jamais utilisé ce type d'outils, j'ai toujours repoussé ça à plus tard, un peu comme le backup de mes données -.-'
Probablement, mais il va falloir nous indiquer ce que le kernel dit avant de passer la main a busybox.
Enfin, de ce que j'ai compris, tu joues avec des partitions chiffrées. Je ne serai pas surpris que le noyau ne parvienne pas a lire le contenu de celles-ci et donc n'arrive pas a trouver /sbin/init (ou /bin/init, voire /usr/sbin/init ou encore /usr/bin/init, ça dépend des distros, et j'ai pas de nux sous la main pour vérifier le cas Debian).
Ca peut aussi être qu'il ne parviens pas à trouver la partition root (le /) en premier lieu.
Enfin, en gros, le problème c'est probablement qu'il n'arrive pas a donner la main à un autre binaire quand il a fini son initialisation. Pour le vérifier, tu peux lui passer le chemin vers un shell, en passant, par exemple, init=/bin/sh sur la ligne de commande du kernel.
Tout ça, ce ne sont bien sûr que des conjectures: sans les logs je ne peux qu'essayer de deviner en me basant sur mon peu d'expérience (je n'ai jamais joué avec des partitions chiffrées: ça me semble trop dangereux pour trop peu d'intérêt, excepté le /home et à la rigueur le /var).
Exact, mais pour le coup, la chaîne de liens ici indique la fin totale du support pour 2020, toutes plates-formes incluses. Pour être précis, ils parlent même de finir le support encore plus tôt dans certaines régions du monde.
Après, j'ai peut-être raté l'information officielle dans un autre journal, c'est pas impossible.
…je dirais que ton kernel est planté, et a booté le busybox a la place de l'init. Si c'est le cas, l'init n'ayant pas été lancé, le /dev n'a pas été peuplé. A confirmer.
Donc j'évite (surtout avec mes faibles compétences en ma possession).
Voila. Donc c'est bien ce que je disais, l'argument que j'ai souvent lu en provenance d'un pro-systemd vers les autres se retourne bien ici.
Et tu le prouves ici:
ben oui si tu modifie un fichier dans /etc sous debian/ubuntu il n'est plus mis à jour
Faux pour pas mal d'entre eux. A minima, les conf de vim et de bash, probablement d'autres, je n'ai pas une mémoire d'éléphant.
Le logiciel te demande ce que tu veux faire, typiquement: prendre la version du mainteneur, regarder le diff ou garder ta version. En tout cas, sous Debian. Conclusion, il est très possible de générer un diff avant (voire pendant) la MàJ et de porter le diff après la MàJ en ayant accepté au préalable la version du mainteneur.
Anti-systemd primaire? Si ça t'amuse de le croire…
Concrètement, les trucs que je reproche à systemd c'est bien de ne pas avoir de limites fonctionnelles définies, ce qui me paraît dangereux pour un projet, et de ne pas être portable, ce qui est un choix totalement défendable. Juste, moi, je préfère utiliser du code portable, au cas ou un jour je décide que finalement linux ne me conviens pas.
Si jamais tu as un de mes messages dans lequel je dis un truc du style que je préférerai que systemd n'ai jamais existé, ou qu'il devrait mourir, je veux bien un lien.
Des anti primaires, il y en a, certains ont même utilisé l'argument qu'ils n'aiment l'auteur comme argument contre. Si je l'ai fait, prouves-le.
J'ai aussi vu des arguments techniques stupides genre que sysVinit est parfait et moderne. Perso, quand j'ai appris la naissance de systemd et l'idée générale, j'étais enthousiaste. Parce que j'avais déjà essayé de lire le tas de spaghettis qu'étais le système d'init de Debian.
Ma question était honnête, y compris celle sur le kernel.
Maintenant, je vois assez mal comment un système d'init, de manière générale, pourrait accéder aux logs du kernel alors que les autres ne le pourraient pas.
Clairement, systemd peut utiliser l'API spécifique du kernel, c'est très possible. Mais il me semble que le kernel expose énormément de choses via un système de pseudo-fichiers, accessible donc par n'importe quel soft POSIX, et j'imagine que les logs en font partie.
Si j'ai bien compris, tu soupçonnes le pare-feu de faire planter le kernel? Mouai. Et t'as pas les logs? Re-mouai. Je sais pas ce que tu utilises pour configurer ton pare-feu, mais je doute fort que la sortie d'erreur ne soit pas redirigeable vers un fichier.
Et dans ce cas, le coupable du manque de logs, c'est pas l'init hein, non non, c'est l'admin qui n'a pas fait son job. Job peut-être plus simple avec systemd, pourquoi pas, mais vu que tu ne nous donne pas de détails sur les logs qu'il te manque, on ne peux même pas le prouver.
En fait, comme tu te contente de supposer, il n'y a même aucune preuve que systemd aurait fait le taf. Au lieu de ça, tu m'attaques personnellement. La classe.
Si on distingue parmi les humains membres de la société ce qui font partie ou non du "peuple" pouvant exercer pouvoir sur les autres, on créé de fait une hierarchie, donc une oligarchie.
Donc, un enfant devrait avoir autant de poids dans le processus de création des lois? Ou quelqu'un ayant perdu la raison? Ou quelqu'un habitant sur Mars (ça n'existe pas encore, certes)? Malgré que ces gens ne soient pas nécessairement concernés, n'aient pas les capacités nécessaires pour comprendre le problème?
D'où l'importance de la définition du citoyen quand on parle de démocratie, et d'où mon point, donc.
Pour moi, le fait d'avoir des lois imposées par une majorité implique de facto une hiérarchie, pas nécessairement oligarchique (ce n'est pas un petit nombre d'individu qui a le pouvoir, mais bien la majorité).
En cela, le logiciel libre n'a rien de démocratique: tu fais ce que tu veux, peu importe ton état mental, tes antécédents ou toute autre caractéristique. Tu n'es pas obligé de faire ce que les autres te demandent (*). C'est bien plus proche de l'anarchie, en ce sens, bien que ce soit fatalement limité par les législations locales et les ressources de ses acteurs.
*: je pars d'une base théorique sur les 4 libertés, hein, ou aucune contrainte n'est ajoutée au code. J'exclue donc de facto les licences de la FSF, entres autres, et d'ailleurs, certaines d'entres elles ne sont pas libres (ce qui est la raison pour laquelle tu n'auras pas la doc de GCC n'est pas installée par défaut par Debian, la section non-free n'étant par défaut pas récupérée).
Non, il y a un vrai apport avec systemd/journald, les logs sont capturés bien plus tôt qu'avec syslog dans la séquence de boot,
Tu veux dire les logs du kernel, ou des services?
Concrètement, qu'est-ce qui empêche les services d'avoir leur stdout/err redirigés par le script d'init (que ce soit sysV ou un autre, on s'en cogne) dans un fichier propre?
Comment distinguer la version 32/64 bit d'un OS du jeu d'instruction utilisé ?
Sous linux, dans une ligne de commande: uname -a te donnera toutes les informations sur ton noyau. Sous debian et ses filles, dpkg --print-architecture te donnera la liste des architectures supportées par ton système de paquet.
Jeu d'instructions processeurs Intel :
i386
i586
i686
Jeu d'instructions processeurs Amd :
amd
amd64
Architecture :
x86
x86_64
En gros, i386, tu n'en verras probablement jamais. i586 sur de très vieilles machines (~20 ans), i686 furent les dernières architectures 32 bits du modèle x86 (dont intel est inventeur, me semble). Les archis 64b compatibles intel sont compatibles entre elles aussi, si je ne dis pas de bêtises, et on utilise soit amd64 parce qu'amd a vraiment lancé le truc (pas inventeur pour autant, ceci dit…) soit x86_64, qui est plus générique.
Si tu veux plus de détails sur ce sujet, je t'encourage a aller lire wikipedia, mais franchement, la seule chose dont tu aie réellement à te préoccuper, c'est si tu es en x86 ou x86_64.
Si tu veux un truc le plus portable possible, prend les binaires x86, vu que les arch x86_64 peuvent les exécuter, le contraire n'étant pas vrai. Ceci dit, les machines en 32 bits vont commencer à se faire rare, et a part sous windows ou une tétrachiée de logiciels sont encore compilés en 32 bits, tu peux globalement oublier que ça a existé. Tant que tu restes sur une archi x86, je veux dire.
La démocratie athénienne était en effet affranchie des déterminismes sociaux. Enfin, uniquement parce que les femmes, les enfants et la plèbe n'étaient pas des citoyens, si je ne m'abuse.
C'est pour ça que je dis qu'avant de parler de pouvoir au peuple, il faut déterminer qui fait partie du peuple.
[^] # Re: Ah le désespoir
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 5.
Si on suppose que les gens qui vendent des journaux le font en espérant toucher le public le plus large possible, alors je dirais que je n'ai juste jamais rien vu qui parle de slackware, a mettre en parallèle avec le fait que j'ai déjà vu des journaux parler de la famille BSD.
Le sentiment (ben oui, ce ne sont pas des chiffres, tout comme les chiffres de distrowatch ne concernent pas l'utilisation) qui s'en dégage, c'est que slack est ultra minoritaire en normandie et région parisienne (les lieux ou j'ai acheté ce type de magazines ces 4 dernières années).
Comme 10% ne me semble pas du tout ultra minoritaire, l'impression que j'ai est que ce chiffre est totalement faux.
Bon après, ma base de raisonnement est limitée dans le temps et l'espace, et je ne connais moi-même personne qui utilise linux au quotidien. Au niveau taf, les seules distrib que j'ai croisées sont Debian et CentOS, ainsi que Red Hat Linux en recherche d'emploi (pas croisée donc, mais a été mentionnée).
Si je m'en tenais a mon vécu "physique", slack n'existerait tout bonnement pas du tout, ce qui est évidemment faux. Par contre, même sur le net, on en parle quand même très peu, il y a peu de références à elle (comparé aux autres distrib linux et aux *BSD, hein).
Impossible, même. C'est impossible de chiffrer le taux d'utilisation d'une distrib gratuite au niveau mondial.
[^] # Re: Faute de français
Posté par freem . En réponse à la dépêche Reportage sur LaTeleLibre.fr : « La Guerre des Civic Tech ». Évalué à 6.
Oui. Le français actuel est mieux que ce que tu proposes.
Ce n'est pas parce que quelque chose est "novateur" que c'est mieux que l'existant.
Ah, et sinon, es-ce difficile à imaginer que les gens considèrent tes messages inutiles à cause d'arguments de qualité médiocres, d'insultes et de vulgarité?
[^] # Re: a vue de nez...
Posté par freem . En réponse au message "Can not mount /dev/loop0" lors de l'installation Ubuntu GNOME 16.04.2. Évalué à 2.
A l'écran après que grub (je suppose que tu utilises grub) ait passé la main à linux.
[^] # Re: questions ?
Posté par freem . En réponse au message Offre d'emploi CDI - Analyste Programmeur Chef de Projet - Narbonne. Évalué à 4.
En fait, c'est juste du dev sous windows, ce n'est pas que le nom de l'OS mais aussi de plusieurs techno citées:
Ah, et je parie que le "C", en fait, c'est du C#: il y a le même syndrome sur pas mal de sites de recrutement… donc oui, ça va se faire défoncer et ce sera mérité, ça n'a juste pas sa place ici.
[^] # Re: Démocratie dans le logiciel libre
Posté par freem . En réponse à la dépêche Reportage sur LaTeleLibre.fr : « La Guerre des Civic Tech ». Évalué à 3.
Tu vas devoir définir "bien pensé" et "correctement distribuée". Dans ma phrase, j'ai parlé d'enfants ou de malades mentaux, ça aurait du te faire tilter: c'est quoi, un fou? A partir de quel moment quelqu'un n'est plus capable de décisions cohérentes?
C'est loin d'être simple, surtout que ça varie en fonction des gens.
A l'heure actuelle, je ne pense pas, de manière générale, l'être humain capable de prendre des décisions efficaces et non basées sur l'égoïsme. La raison principale selon moi est que je ne crois pas qu'il existe une seule démocratie dans le monde. S'il y en a une, je n'en ai pas entendu parler…
J'entend par démocratie le fait que la majorité du peuple puisse, par voie légale (et sans passer par les armes) changer les règles auxquelles il obéit à n'importe quel moment. Concrètement, sauf erreur de ma part, en France si la majorité du peuple dit non à une loi ou un décret, les élus n'ont pas l'obligation d'écouter: le peuple n'a donc pas le pouvoir, ce n'est pas une démocratie.
L'idéal libertaire est compatible avec l'idéal démocrate, mais pas l'inverse, pour moi. Pour faire un parallèle avec les licences: tu peux inclure du BSD-2c dans du GPL, mais pas l'inverse.
Pour moi, la démocratie implique qu'une partie du peuple se plie aux décisions majoritaires. Après, le terme est très mal défini de base.
[^] # Re: Faute de français
Posté par freem . En réponse à la dépêche Reportage sur LaTeleLibre.fr : « La Guerre des Civic Tech ». Évalué à 3.
On devrais donc parler en bash ou en python, pourquoi réinventer la roue?
En plus, c'set magique, y'a pas de genre dans ces langages…
[^] # Re: OpenRC
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 3.
De ce que j'ai retiré de mes diverses lectures, ça semble offrir nativement le support du parallélisme et la gestion des dépendances.
Ces points sont 2 des points d'accroche initiaux de systemd selon moi, avec en bonus non négligeable la facilité de configuration (aka: possibilité d'éviter les scripts mais plutôt d'utiliser des fichiers de config plus traditionnels).
Je ne sais pas s'il y a d'autres points intéressants dans OpenRC.
Perso, j'ai plus été séduit par runit qu'OpenRC, la configuration est nettement plus triviale. En revanche, pas de gestion des dépendances, il faut le faire manuellement: soit un programme sait qui dépend de lui et créées leurs liens symbolique (ce qui serait une grosse galère à maintenir) soit un programme sait de quels services il dépend et attend gentiment que ceux-ci soient démarrés, par exemple en scrutant la création d'un fichier PID (a priori, simple à faire et à maintenir).
[^] # Re: Pas le problème mais la raison !
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 2.
Ce qui est à la fois une bonne et une mauvaise chose. C'est une bonne chose parce que ça permets une meilleure intégration, et pour la majorité qui se contrefiche (avec raison) de la portabilité c'est juste positif.
[^] # Re: Pas le problème mais la raison !
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 0.
Bah en gros j'essaie de comprendre comment il fait, et donc pourquoi ce serait infaisable par les autres. Tout bêtement. A partir de la, je pourrai ensuite vérifier que les autres ne le font effectivement pas.
Par exemple, si je te demande s'il fait en gros le même travail que klogd (
The klogd program will extract messages from the kernel log buffer) mais dès le début, je me trompe ou pas? Ou est-ce qu'il utilise un truc plus bas niveau, ce qui serai impossible à d'autres qui refuseraient le code spécifique à un OS?[^] # Re: Pas le problème mais la raison !
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 4. Dernière modification le 27 juillet 2017 à 10:36.
Et sur ce point je suis d'accord. Chacun utilise bien ce qu'il veut.
Possible. Mais j'ai bien l'impression que
systemctl status xxxà une variante pour les sysVinit. Pas sous Debian la (à mon grand regret) mais ça ressemble àservices status xxx?Pour
systemctl --state=failedeffectivement, en général je me fade une commande à rallonge, combo de grep et de redirection de stderr vers /dev/null.Le reste, je ne sais pas, et/ou ne vois pas nécessairement l'utilité (différents usages, différents besoins).
Ca, c'est une connerie: le fait de proposer un autre modèle augmente la diversité. Si d'autres projets meurent parce que plus utilisés et remplacés par systemd, c'est juste qu'ils ne sont pas assez efficaces.
SysVinit ne me manquera pas, et grâce à systemd j'ai découvert runit, qui à son tour m'a fait découvrir voidlinux.
Perso, j'y ai gagné, dans cette affaire. Je n'ai pas l'intention d'utiliser systemd, j'ai mes raisons, mais je sais que sans systemd je n'aurai pas fait ces recherches et je n'aurai pas appris tout ce que j'ai pu apprendre sur l'init.
[^] # Re: Pas le problème mais la raison !
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 0.
Le coup du "c'est juste que vous ne voulez pas apprendre".
D'ac. Du coup, ça se passe comment si dpkg pose une question à l'utilisateur? Je n'ai jamais utilisé ce type d'outils, j'ai toujours repoussé ça à plus tard, un peu comme le backup de mes données -.-'
[^] # Re: Ah le désespoir
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 7.
source?
[^] # Re: a vue de nez...
Posté par freem . En réponse au message "Can not mount /dev/loop0" lors de l'installation Ubuntu GNOME 16.04.2. Évalué à 2.
Probablement, mais il va falloir nous indiquer ce que le kernel dit avant de passer la main a busybox.
Enfin, de ce que j'ai compris, tu joues avec des partitions chiffrées. Je ne serai pas surpris que le noyau ne parvienne pas a lire le contenu de celles-ci et donc n'arrive pas a trouver /sbin/init (ou /bin/init, voire /usr/sbin/init ou encore /usr/bin/init, ça dépend des distros, et j'ai pas de nux sous la main pour vérifier le cas Debian).
Ca peut aussi être qu'il ne parviens pas à trouver la partition root (le /) en premier lieu.
Enfin, en gros, le problème c'est probablement qu'il n'arrive pas a donner la main à un autre binaire quand il a fini son initialisation. Pour le vérifier, tu peux lui passer le chemin vers un shell, en passant, par exemple, init=/bin/sh sur la ligne de commande du kernel.
Tout ça, ce ne sont bien sûr que des conjectures: sans les logs je ne peux qu'essayer de deviner en me basant sur mon peu d'expérience (je n'ai jamais joué avec des partitions chiffrées: ça me semble trop dangereux pour trop peu d'intérêt, excepté le /home et à la rigueur le /var).
[^] # Re: Une bonne nouvelle pour le réchauffement climatique!
Posté par freem . En réponse au journal Bookmark: mort de flash officiellement planifiée?. Évalué à 2.
Bah au moins avec gnash ils auront une bonne base départ.
[^] # Re: c'est comme l'année de Linux sur le desktop ?
Posté par freem . En réponse au journal Bookmark: mort de flash officiellement planifiée?. Évalué à 4.
Exact, mais pour le coup, la chaîne de liens ici indique la fin totale du support pour 2020, toutes plates-formes incluses. Pour être précis, ils parlent même de finir le support encore plus tôt dans certaines régions du monde.
Après, j'ai peut-être raté l'information officielle dans un autre journal, c'est pas impossible.
# a vue de nez...
Posté par freem . En réponse au message "Can not mount /dev/loop0" lors de l'installation Ubuntu GNOME 16.04.2. Évalué à 2.
…je dirais que ton kernel est planté, et a booté le busybox a la place de l'init. Si c'est le cas, l'init n'ayant pas été lancé, le /dev n'a pas été peuplé. A confirmer.
[^] # Re: Pas le problème mais la raison !
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à -1.
Voila. Donc c'est bien ce que je disais, l'argument que j'ai souvent lu en provenance d'un pro-systemd vers les autres se retourne bien ici.
Et tu le prouves ici:
Faux pour pas mal d'entre eux. A minima, les conf de vim et de bash, probablement d'autres, je n'ai pas une mémoire d'éléphant.
Le logiciel te demande ce que tu veux faire, typiquement: prendre la version du mainteneur, regarder le diff ou garder ta version. En tout cas, sous Debian. Conclusion, il est très possible de générer un diff avant (voire pendant) la MàJ et de porter le diff après la MàJ en ayant accepté au préalable la version du mainteneur.
[^] # Re: Pas le problème mais la raison !
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à -1.
Anti-systemd primaire? Si ça t'amuse de le croire…
Concrètement, les trucs que je reproche à systemd c'est bien de ne pas avoir de limites fonctionnelles définies, ce qui me paraît dangereux pour un projet, et de ne pas être portable, ce qui est un choix totalement défendable. Juste, moi, je préfère utiliser du code portable, au cas ou un jour je décide que finalement linux ne me conviens pas.
Si jamais tu as un de mes messages dans lequel je dis un truc du style que je préférerai que systemd n'ai jamais existé, ou qu'il devrait mourir, je veux bien un lien.
Des anti primaires, il y en a, certains ont même utilisé l'argument qu'ils n'aiment l'auteur comme argument contre. Si je l'ai fait, prouves-le.
J'ai aussi vu des arguments techniques stupides genre que sysVinit est parfait et moderne. Perso, quand j'ai appris la naissance de systemd et l'idée générale, j'étais enthousiaste. Parce que j'avais déjà essayé de lire le tas de spaghettis qu'étais le système d'init de Debian.
Ma question était honnête, y compris celle sur le kernel.
Maintenant, je vois assez mal comment un système d'init, de manière générale, pourrait accéder aux logs du kernel alors que les autres ne le pourraient pas.
Clairement, systemd peut utiliser l'API spécifique du kernel, c'est très possible. Mais il me semble que le kernel expose énormément de choses via un système de pseudo-fichiers, accessible donc par n'importe quel soft POSIX, et j'imagine que les logs en font partie.
Si j'ai bien compris, tu soupçonnes le pare-feu de faire planter le kernel? Mouai. Et t'as pas les logs? Re-mouai. Je sais pas ce que tu utilises pour configurer ton pare-feu, mais je doute fort que la sortie d'erreur ne soit pas redirigeable vers un fichier.
Et dans ce cas, le coupable du manque de logs, c'est pas l'init hein, non non, c'est l'admin qui n'a pas fait son job. Job peut-être plus simple avec systemd, pourquoi pas, mais vu que tu ne nous donne pas de détails sur les logs qu'il te manque, on ne peux même pas le prouver.
En fait, comme tu te contente de supposer, il n'y a même aucune preuve que systemd aurait fait le taf. Au lieu de ça, tu m'attaques personnellement. La classe.
[^] # Re: Démocratie dans le logiciel libre
Posté par freem . En réponse à la dépêche Reportage sur LaTeleLibre.fr : « La Guerre des Civic Tech ». Évalué à 3.
C'est ça.
Donc, un enfant devrait avoir autant de poids dans le processus de création des lois? Ou quelqu'un ayant perdu la raison? Ou quelqu'un habitant sur Mars (ça n'existe pas encore, certes)? Malgré que ces gens ne soient pas nécessairement concernés, n'aient pas les capacités nécessaires pour comprendre le problème?
D'où l'importance de la définition du citoyen quand on parle de démocratie, et d'où mon point, donc.
Pour moi, le fait d'avoir des lois imposées par une majorité implique de facto une hiérarchie, pas nécessairement oligarchique (ce n'est pas un petit nombre d'individu qui a le pouvoir, mais bien la majorité).
En cela, le logiciel libre n'a rien de démocratique: tu fais ce que tu veux, peu importe ton état mental, tes antécédents ou toute autre caractéristique. Tu n'es pas obligé de faire ce que les autres te demandent (*). C'est bien plus proche de l'anarchie, en ce sens, bien que ce soit fatalement limité par les législations locales et les ressources de ses acteurs.
*: je pars d'une base théorique sur les 4 libertés, hein, ou aucune contrainte n'est ajoutée au code. J'exclue donc de facto les licences de la FSF, entres autres, et d'ailleurs, certaines d'entres elles ne sont pas libres (ce qui est la raison pour laquelle tu n'auras pas la doc de GCC n'est pas installée par défaut par Debian, la section non-free n'étant par défaut pas récupérée).
[^] # Re: lag
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 7.
Perso, a voir les connaissances sur l'histo des distro dont il fait étalage, je dirais qu'il utilise Windows.
[^] # Re: Pas le problème mais la raison !
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 2.
Tu veux dire les logs du kernel, ou des services?
Concrètement, qu'est-ce qui empêche les services d'avoir leur stdout/err redirigés par le script d'init (que ce soit sysV ou un autre, on s'en cogne) dans un fichier propre?
[^] # Re: Ah le désespoir
Posté par freem . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à -4. Dernière modification le 26 juillet 2017 à 15:08.
Yep. C'est un peu ce que les détracteurs se sont tués à expliquer. Moi, j'ai envie de dire: "Et SPOF dans vos faces les pro-sysd!".
(pas pu m'empêcher pour la vanne merdique)
[^] # Re: Faute de français
Posté par freem . En réponse à la dépêche Reportage sur LaTeleLibre.fr : « La Guerre des Civic Tech ». Évalué à 8.
Toi, peut-être. Ne prends pas ton cas pour une généralité par contre.
[^] # Re: Sauvegarde disque
Posté par freem . En réponse au message Recherche logiciel de restauration/clonage de configuration d'OS. Évalué à 3.
Sous linux, dans une ligne de commande:
uname -ate donnera toutes les informations sur ton noyau. Sous debian et ses filles,dpkg --print-architecturete donnera la liste des architectures supportées par ton système de paquet.En gros, i386, tu n'en verras probablement jamais. i586 sur de très vieilles machines (~20 ans), i686 furent les dernières architectures 32 bits du modèle x86 (dont intel est inventeur, me semble). Les archis 64b compatibles intel sont compatibles entre elles aussi, si je ne dis pas de bêtises, et on utilise soit amd64 parce qu'amd a vraiment lancé le truc (pas inventeur pour autant, ceci dit…) soit x86_64, qui est plus générique.
Si tu veux plus de détails sur ce sujet, je t'encourage a aller lire wikipedia, mais franchement, la seule chose dont tu aie réellement à te préoccuper, c'est si tu es en x86 ou x86_64.
Si tu veux un truc le plus portable possible, prend les binaires x86, vu que les arch x86_64 peuvent les exécuter, le contraire n'étant pas vrai. Ceci dit, les machines en 32 bits vont commencer à se faire rare, et a part sous windows ou une tétrachiée de logiciels sont encore compilés en 32 bits, tu peux globalement oublier que ça a existé. Tant que tu restes sur une archi x86, je veux dire.
[^] # Re: Démocratie dans le logiciel libre
Posté par freem . En réponse à la dépêche Reportage sur LaTeleLibre.fr : « La Guerre des Civic Tech ». Évalué à 3.
La démocratie athénienne était en effet affranchie des déterminismes sociaux. Enfin, uniquement parce que les femmes, les enfants et la plèbe n'étaient pas des citoyens, si je ne m'abuse.
C'est pour ça que je dis qu'avant de parler de pouvoir au peuple, il faut déterminer qui fait partie du peuple.