Le Mon, 17 Oct 2016 08:50:51 +0000, JKB a écrit :accès 999
C'est un peu comme AAA en base dix ?
Faut de tout urgence t'acheter une calculette hexadécimale...
hexadécimal _en base 10_
Le Mon, 17 Oct 2016 08:50:51 +0000, JKB a écrit :
accès 999
C'est un peu comme AAA en base dix ?
Faut de tout urgence t'acheter une calculette hexadécimale...
hexadécimal _en base 10_
Le Mon, 17 Oct 2016 08:50:51 +0000, JKB a écrit :accès 999
C'est un peu comme AAA en base dix ?
Faut de tout urgence t'acheter une calculette hexadécimale...
hexadécimal _en base 10_
Mais _pourquoi_ intégrer un truc clairement pas sec ?
Pourquoi faire la sourde oreille quand on ose poser la question ?
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Mais _pourquoi_ intégrer un truc clairement pas sec ?
Pourquoi faire la sourde oreille quand on ose poser la question ?
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Mais _pourquoi_ intégrer un truc clairement pas sec ?
Pourquoi faire la sourde oreille quand on ose poser la question ?
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Doug713705 , dans le message <nu2873$uvd$, a
écrit :Mais _pourquoi_ intégrer un truc clairement pas sec ?
Parce que même pas sec, c'en est déjà arrivé au point où ça colle moins aux
doigts que l'ancien système. Tu vois les inconvénients, mais tu refuses de
voir les avantages. Il y a des bugs, oui, et bien entendu quand quelqu'un
tombe sur un bug il va hurler comme un cochon qu'on égorge, mais il n'y a
pas que des bugs, il y a une immense majorité de cas où ça juste marche, et
quand c'est le cas, ça rend les choses plus simples, plus fiables, plus
rapides.
Je vais invoquer un argument d'autorité : tu peux dire ce que tu veux sur
les développeurs RedHat et assimilés, ils sont peut-être vendus à... je ne
sais quoi, au juste, mais peu importe, vas-y avec tes théories du complot.
Mais les développeurs Debian, en revanche, tu ne peux pas vraiment les
accuser de quoi que ce soit de tel. Ils sont, au contraire, parmi les plus
perfectionnistes de la communauté. Et ils se sont prononcés en majorité pour
utiliser systemd.
Et si Debian ne te suffit pas, Gentoo aussi semble utiliser systemd par
défaut.
Pourquoi faire la sourde oreille quand on ose poser la question ?
Qui fait la sourde oreille ?
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Eh bien reste sur ta chère Slackware, personne ne t'en empêche.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Certainement, tout comme il y a des fanatiques qui s'acharnent à prétendre
que laisser les bugs d'upstream est une feature.
Doug713705 , dans le message <nu2873$uvd$1@golgoth99.redatomik.org>, a
écrit :
Mais _pourquoi_ intégrer un truc clairement pas sec ?
Parce que même pas sec, c'en est déjà arrivé au point où ça colle moins aux
doigts que l'ancien système. Tu vois les inconvénients, mais tu refuses de
voir les avantages. Il y a des bugs, oui, et bien entendu quand quelqu'un
tombe sur un bug il va hurler comme un cochon qu'on égorge, mais il n'y a
pas que des bugs, il y a une immense majorité de cas où ça juste marche, et
quand c'est le cas, ça rend les choses plus simples, plus fiables, plus
rapides.
Je vais invoquer un argument d'autorité : tu peux dire ce que tu veux sur
les développeurs RedHat et assimilés, ils sont peut-être vendus à... je ne
sais quoi, au juste, mais peu importe, vas-y avec tes théories du complot.
Mais les développeurs Debian, en revanche, tu ne peux pas vraiment les
accuser de quoi que ce soit de tel. Ils sont, au contraire, parmi les plus
perfectionnistes de la communauté. Et ils se sont prononcés en majorité pour
utiliser systemd.
Et si Debian ne te suffit pas, Gentoo aussi semble utiliser systemd par
défaut.
Pourquoi faire la sourde oreille quand on ose poser la question ?
Qui fait la sourde oreille ?
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Eh bien reste sur ta chère Slackware, personne ne t'en empêche.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Certainement, tout comme il y a des fanatiques qui s'acharnent à prétendre
que laisser les bugs d'upstream est une feature.
Doug713705 , dans le message <nu2873$uvd$, a
écrit :Mais _pourquoi_ intégrer un truc clairement pas sec ?
Parce que même pas sec, c'en est déjà arrivé au point où ça colle moins aux
doigts que l'ancien système. Tu vois les inconvénients, mais tu refuses de
voir les avantages. Il y a des bugs, oui, et bien entendu quand quelqu'un
tombe sur un bug il va hurler comme un cochon qu'on égorge, mais il n'y a
pas que des bugs, il y a une immense majorité de cas où ça juste marche, et
quand c'est le cas, ça rend les choses plus simples, plus fiables, plus
rapides.
Je vais invoquer un argument d'autorité : tu peux dire ce que tu veux sur
les développeurs RedHat et assimilés, ils sont peut-être vendus à... je ne
sais quoi, au juste, mais peu importe, vas-y avec tes théories du complot.
Mais les développeurs Debian, en revanche, tu ne peux pas vraiment les
accuser de quoi que ce soit de tel. Ils sont, au contraire, parmi les plus
perfectionnistes de la communauté. Et ils se sont prononcés en majorité pour
utiliser systemd.
Et si Debian ne te suffit pas, Gentoo aussi semble utiliser systemd par
défaut.
Pourquoi faire la sourde oreille quand on ose poser la question ?
Qui fait la sourde oreille ?
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Eh bien reste sur ta chère Slackware, personne ne t'en empêche.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Certainement, tout comme il y a des fanatiques qui s'acharnent à prétendre
que laisser les bugs d'upstream est une feature.
Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.
Debian est spécialiste à ce petit jeu et ce n'est pas Openssl qui dira
le contraire ! Ah c'est vrai, ça aussi il ne faut pas en parler, c'est
du passé, toussa.
Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.
Debian est spécialiste à ce petit jeu et ce n'est pas Openssl qui dira
le contraire ! Ah c'est vrai, ça aussi il ne faut pas en parler, c'est
du passé, toussa.
Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.
Debian est spécialiste à ce petit jeu et ce n'est pas Openssl qui dira
le contraire ! Ah c'est vrai, ça aussi il ne faut pas en parler, c'est
du passé, toussa.
Le 17-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5804e136$0$24781$) :Doug713705 , dans le message <nu2873$uvd$, a
écrit :Mais _pourquoi_ intégrer un truc clairement pas sec ?
Parce que même pas sec, c'en est déjà arrivé au point où ça colle moins aux
doigts que l'ancien système. Tu vois les inconvénients, mais tu refuses de
voir les avantages. Il y a des bugs, oui, et bien entendu quand quelqu'un
tombe sur un bug il va hurler comme un cochon qu'on égorge, mais il n'y a
pas que des bugs, il y a une immense majorité de cas où ça juste marche, et
quand c'est le cas, ça rend les choses plus simples, plus fiables, plus
rapides.
C'est évidement totalement faux dans le raisonnement même.
Un vieux truc qui fonctionne même peu efficace sera nettement plus utile
qu'un truc plus performant au comportement mal documenté et peu fiable.
Init est peut être peu souple mais il a l'avantage d'être parfaitement
connu, on sait en contourner certaines limites , les bugs en sont
identifiés, documentés, etc.
Systemd a un comportement bien trop souvent ératique, peu conforme aux
attentes et à la doc. C'est déjà une raison suffisante pour ne pas le
mettre en prod, et donc de ne pas le proposer par défaut.
Qu'il soit proposé ne pose pas de problème, il faut bien des early
adopters pour débugger mais le proposer par défaut c'est volontairement
envoyer le bateau dans les récifs en espérant qu'il s'en sorte sans trop
de dégats !Je vais invoquer un argument d'autorité : tu peux dire ce que tu veux sur
les développeurs RedHat et assimilés, ils sont peut-être vendus à... je ne
sais quoi, au juste, mais peu importe, vas-y avec tes théories du complot.
Mais les développeurs Debian, en revanche, tu ne peux pas vraiment les
accuser de quoi que ce soit de tel. Ils sont, au contraire, parmi les plus
perfectionnistes de la communauté. Et ils se sont prononcés en majorité pour
utiliser systemd.
De ce que j'en ai lu cette majorité ne s'est pas obtenu aussi facilement
que ça. Je n'ose pas imaginer les lobbying internes... Il y a toujours
de lobbying, quelle que soit l'organisation.
Et si Debian ne te suffit pas, Gentoo aussi semble utiliser systemd par
défaut.
Il me semblait qu'ils en étaient restés à openrc avec systemd en
option.
Mais de toutes façons se n'est pas étonnant puisque la grande force de
systemd est d'agir comme une pieuvre et de forcer la main des
distributions en s'incrustant en tant que dépendance obligatoire (merci
gnome). Heureusement Gnome n'est pas inclus dans Slackware, c'est
peut-être pour cette raison que Pat Volkerding arrive encore à
resister.
C'est le même schéma que celui de PulseAudio, et pareil Slackware a
resisté jusqu'à la sortie de 14.2 qui intègre une version de BlueZ qui
réclame PulseAudio.
Pulse audio qui provoque des $*@# d'underruns et me renvoie par défaut
le son sur le HDMI dès que je débranche mon casque ! On sent le boulot
bien fait ! Holy shit, c'est le même bonhomme qui est à l'initiative de
PulseAudio et de systemd. Mais *abatez-le* !
Pourquoi faire la sourde oreille quand on ose poser la question ?
Qui fait la sourde oreille ?
Les systemd fanboys. Ceux qui prétendent comme toi qu'essuyer les
plâtres avec une brique est plus efficace que de ne pas avoir de plâtre
!
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Eh bien reste sur ta chère Slackware, personne ne t'en empêche.
Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Certainement, tout comme il y a des fanatiques qui s'acharnent à prétendre
que laisser les bugs d'upstream est une feature.
Ce n'est paut-être pas une feature mais chacun son boulot. Tu balances
ton patch à l'upstream qui l'intègre (ou non) et tu refais le paquet à
partir des nouvelles sources d'upstream. Ça semble un schéma bien plus
cohérent que d'appliquer son patch dans son coin (en gros forker) et
dire ensuite à l'upstream d'appliquer le patch.
Avec cette dernière méthode on est _certain_ de finir par avoir des bugs
spécifiques à notre version et dans certains cas d'avoir une version du
paquet qui nous est propre (un fork qui ne dit pas son nom) à maintenir.
Debian est spécialiste à ce petit jeu et ce n'est pas Openssl qui dira
le contraire ! Ah c'est vrai, ça aussi il ne faut pas en parler, c'est
du passé, toussa.
Le 17-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5804e136$0$24781$426a74cc@news.free.fr>) :
Doug713705 , dans le message <nu2873$uvd$1@golgoth99.redatomik.org>, a
écrit :
Mais _pourquoi_ intégrer un truc clairement pas sec ?
Parce que même pas sec, c'en est déjà arrivé au point où ça colle moins aux
doigts que l'ancien système. Tu vois les inconvénients, mais tu refuses de
voir les avantages. Il y a des bugs, oui, et bien entendu quand quelqu'un
tombe sur un bug il va hurler comme un cochon qu'on égorge, mais il n'y a
pas que des bugs, il y a une immense majorité de cas où ça juste marche, et
quand c'est le cas, ça rend les choses plus simples, plus fiables, plus
rapides.
C'est évidement totalement faux dans le raisonnement même.
Un vieux truc qui fonctionne même peu efficace sera nettement plus utile
qu'un truc plus performant au comportement mal documenté et peu fiable.
Init est peut être peu souple mais il a l'avantage d'être parfaitement
connu, on sait en contourner certaines limites , les bugs en sont
identifiés, documentés, etc.
Systemd a un comportement bien trop souvent ératique, peu conforme aux
attentes et à la doc. C'est déjà une raison suffisante pour ne pas le
mettre en prod, et donc de ne pas le proposer par défaut.
Qu'il soit proposé ne pose pas de problème, il faut bien des early
adopters pour débugger mais le proposer par défaut c'est volontairement
envoyer le bateau dans les récifs en espérant qu'il s'en sorte sans trop
de dégats !
Je vais invoquer un argument d'autorité : tu peux dire ce que tu veux sur
les développeurs RedHat et assimilés, ils sont peut-être vendus à... je ne
sais quoi, au juste, mais peu importe, vas-y avec tes théories du complot.
Mais les développeurs Debian, en revanche, tu ne peux pas vraiment les
accuser de quoi que ce soit de tel. Ils sont, au contraire, parmi les plus
perfectionnistes de la communauté. Et ils se sont prononcés en majorité pour
utiliser systemd.
De ce que j'en ai lu cette majorité ne s'est pas obtenu aussi facilement
que ça. Je n'ose pas imaginer les lobbying internes... Il y a toujours
de lobbying, quelle que soit l'organisation.
Et si Debian ne te suffit pas, Gentoo aussi semble utiliser systemd par
défaut.
Il me semblait qu'ils en étaient restés à openrc avec systemd en
option.
Mais de toutes façons se n'est pas étonnant puisque la grande force de
systemd est d'agir comme une pieuvre et de forcer la main des
distributions en s'incrustant en tant que dépendance obligatoire (merci
gnome). Heureusement Gnome n'est pas inclus dans Slackware, c'est
peut-être pour cette raison que Pat Volkerding arrive encore à
resister.
C'est le même schéma que celui de PulseAudio, et pareil Slackware a
resisté jusqu'à la sortie de 14.2 qui intègre une version de BlueZ qui
réclame PulseAudio.
Pulse audio qui provoque des $*@# d'underruns et me renvoie par défaut
le son sur le HDMI dès que je débranche mon casque ! On sent le boulot
bien fait ! Holy shit, c'est le même bonhomme qui est à l'initiative de
PulseAudio et de systemd. Mais *abatez-le* !
Pourquoi faire la sourde oreille quand on ose poser la question ?
Qui fait la sourde oreille ?
Les systemd fanboys. Ceux qui prétendent comme toi qu'essuyer les
plâtres avec une brique est plus efficace que de ne pas avoir de plâtre
!
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Eh bien reste sur ta chère Slackware, personne ne t'en empêche.
Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Certainement, tout comme il y a des fanatiques qui s'acharnent à prétendre
que laisser les bugs d'upstream est une feature.
Ce n'est paut-être pas une feature mais chacun son boulot. Tu balances
ton patch à l'upstream qui l'intègre (ou non) et tu refais le paquet à
partir des nouvelles sources d'upstream. Ça semble un schéma bien plus
cohérent que d'appliquer son patch dans son coin (en gros forker) et
dire ensuite à l'upstream d'appliquer le patch.
Avec cette dernière méthode on est _certain_ de finir par avoir des bugs
spécifiques à notre version et dans certains cas d'avoir une version du
paquet qui nous est propre (un fork qui ne dit pas son nom) à maintenir.
Debian est spécialiste à ce petit jeu et ce n'est pas Openssl qui dira
le contraire ! Ah c'est vrai, ça aussi il ne faut pas en parler, c'est
du passé, toussa.
Le 17-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5804e136$0$24781$) :Doug713705 , dans le message <nu2873$uvd$, a
écrit :Mais _pourquoi_ intégrer un truc clairement pas sec ?
Parce que même pas sec, c'en est déjà arrivé au point où ça colle moins aux
doigts que l'ancien système. Tu vois les inconvénients, mais tu refuses de
voir les avantages. Il y a des bugs, oui, et bien entendu quand quelqu'un
tombe sur un bug il va hurler comme un cochon qu'on égorge, mais il n'y a
pas que des bugs, il y a une immense majorité de cas où ça juste marche, et
quand c'est le cas, ça rend les choses plus simples, plus fiables, plus
rapides.
C'est évidement totalement faux dans le raisonnement même.
Un vieux truc qui fonctionne même peu efficace sera nettement plus utile
qu'un truc plus performant au comportement mal documenté et peu fiable.
Init est peut être peu souple mais il a l'avantage d'être parfaitement
connu, on sait en contourner certaines limites , les bugs en sont
identifiés, documentés, etc.
Systemd a un comportement bien trop souvent ératique, peu conforme aux
attentes et à la doc. C'est déjà une raison suffisante pour ne pas le
mettre en prod, et donc de ne pas le proposer par défaut.
Qu'il soit proposé ne pose pas de problème, il faut bien des early
adopters pour débugger mais le proposer par défaut c'est volontairement
envoyer le bateau dans les récifs en espérant qu'il s'en sorte sans trop
de dégats !Je vais invoquer un argument d'autorité : tu peux dire ce que tu veux sur
les développeurs RedHat et assimilés, ils sont peut-être vendus à... je ne
sais quoi, au juste, mais peu importe, vas-y avec tes théories du complot.
Mais les développeurs Debian, en revanche, tu ne peux pas vraiment les
accuser de quoi que ce soit de tel. Ils sont, au contraire, parmi les plus
perfectionnistes de la communauté. Et ils se sont prononcés en majorité pour
utiliser systemd.
De ce que j'en ai lu cette majorité ne s'est pas obtenu aussi facilement
que ça. Je n'ose pas imaginer les lobbying internes... Il y a toujours
de lobbying, quelle que soit l'organisation.
Et si Debian ne te suffit pas, Gentoo aussi semble utiliser systemd par
défaut.
Il me semblait qu'ils en étaient restés à openrc avec systemd en
option.
Mais de toutes façons se n'est pas étonnant puisque la grande force de
systemd est d'agir comme une pieuvre et de forcer la main des
distributions en s'incrustant en tant que dépendance obligatoire (merci
gnome). Heureusement Gnome n'est pas inclus dans Slackware, c'est
peut-être pour cette raison que Pat Volkerding arrive encore à
resister.
C'est le même schéma que celui de PulseAudio, et pareil Slackware a
resisté jusqu'à la sortie de 14.2 qui intègre une version de BlueZ qui
réclame PulseAudio.
Pulse audio qui provoque des $*@# d'underruns et me renvoie par défaut
le son sur le HDMI dès que je débranche mon casque ! On sent le boulot
bien fait ! Holy shit, c'est le même bonhomme qui est à l'initiative de
PulseAudio et de systemd. Mais *abatez-le* !
Pourquoi faire la sourde oreille quand on ose poser la question ?
Qui fait la sourde oreille ?
Les systemd fanboys. Ceux qui prétendent comme toi qu'essuyer les
plâtres avec une brique est plus efficace que de ne pas avoir de plâtre
!
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Eh bien reste sur ta chère Slackware, personne ne t'en empêche.
Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Certainement, tout comme il y a des fanatiques qui s'acharnent à prétendre
que laisser les bugs d'upstream est une feature.
Ce n'est paut-être pas une feature mais chacun son boulot. Tu balances
ton patch à l'upstream qui l'intègre (ou non) et tu refais le paquet à
partir des nouvelles sources d'upstream. Ça semble un schéma bien plus
cohérent que d'appliquer son patch dans son coin (en gros forker) et
dire ensuite à l'upstream d'appliquer le patch.
Avec cette dernière méthode on est _certain_ de finir par avoir des bugs
spécifiques à notre version et dans certains cas d'avoir une version du
paquet qui nous est propre (un fork qui ne dit pas son nom) à maintenir.
Debian est spécialiste à ce petit jeu et ce n'est pas Openssl qui dira
le contraire ! Ah c'est vrai, ça aussi il ne faut pas en parler, c'est
du passé, toussa.
On 2016-10-17, Doug713705 wrote:Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.
FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On 2016-10-17, Doug713705 <doug.letough@free.fr> wrote:
Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.
FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On 2016-10-17, Doug713705 wrote:Encore heureux ! Mais je sens que je vais finir par passer à OpenBSD.
FreeBSD, la version 11 vient de sortir. La limite de la perfection.
FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On parle de la mémoire POSIX et du support d'un certain chipset
Realtek gigabit ?
FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On parle de la mémoire POSIX et du support d'un certain chipset
Realtek gigabit ?
FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On parle de la mémoire POSIX et du support d'un certain chipset
Realtek gigabit ?
On 2016-10-17, JKB wrote:FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On parle de la mémoire POSIX et du support d'un certain chipset
Realtek gigabit ?
Oui, pourquoi pas. Développe, développe, ça m'intéresse.
On 2016-10-17, JKB <jkb@koenigsberg.invalid> wrote:
FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On parle de la mémoire POSIX et du support d'un certain chipset
Realtek gigabit ?
Oui, pourquoi pas. Développe, développe, ça m'intéresse.
On 2016-10-17, JKB wrote:FreeBSD, la version 11 vient de sortir. La limite de la perfection.
On parle de la mémoire POSIX et du support d'un certain chipset
Realtek gigabit ?
Oui, pourquoi pas. Développe, développe, ça m'intéresse.
Chercher pour cela le fichier 0004-rtl_bsd_drv_v191.tgz sur le site
de realtek. Je n'ai pas vu de modification dans le pilote intégré au
noyau d'origine entre le 10.3 et le 11, le problème devrait toujours
être là. Ce que je ne comprends pas, c'est que l'équipe de dev de
FreeBSD ne fournit pas d'une manière ou d'une autre ce pilote, la
licence associée semblant le permettre.
Quant à la mémoire partagée POSIX et aux sémaphores associés,
ça existe officiellement sous FreeBSD depuis quelque temps, mais
c'est un peu étrange à utiliser. Il faut bidouiller le noyau et le
sysctl pour réussir à en faire quelque chose. Brut de fonderie,
c'est inutilisable (même gimp issu des ports se vautre sur un 10.2
ou 10.3 avec les paramètres par défaut, il faut le lancer avec
--no-shm).
Chercher pour cela le fichier 0004-rtl_bsd_drv_v191.tgz sur le site
de realtek. Je n'ai pas vu de modification dans le pilote intégré au
noyau d'origine entre le 10.3 et le 11, le problème devrait toujours
être là. Ce que je ne comprends pas, c'est que l'équipe de dev de
FreeBSD ne fournit pas d'une manière ou d'une autre ce pilote, la
licence associée semblant le permettre.
Quant à la mémoire partagée POSIX et aux sémaphores associés,
ça existe officiellement sous FreeBSD depuis quelque temps, mais
c'est un peu étrange à utiliser. Il faut bidouiller le noyau et le
sysctl pour réussir à en faire quelque chose. Brut de fonderie,
c'est inutilisable (même gimp issu des ports se vautre sur un 10.2
ou 10.3 avec les paramètres par défaut, il faut le lancer avec
--no-shm).
Chercher pour cela le fichier 0004-rtl_bsd_drv_v191.tgz sur le site
de realtek. Je n'ai pas vu de modification dans le pilote intégré au
noyau d'origine entre le 10.3 et le 11, le problème devrait toujours
être là. Ce que je ne comprends pas, c'est que l'équipe de dev de
FreeBSD ne fournit pas d'une manière ou d'une autre ce pilote, la
licence associée semblant le permettre.
Quant à la mémoire partagée POSIX et aux sémaphores associés,
ça existe officiellement sous FreeBSD depuis quelque temps, mais
c'est un peu étrange à utiliser. Il faut bidouiller le noyau et le
sysctl pour réussir à en faire quelque chose. Brut de fonderie,
c'est inutilisable (même gimp issu des ports se vautre sur un 10.2
ou 10.3 avec les paramètres par défaut, il faut le lancer avec
--no-shm).
On 2016-10-17, JKB wrote:Chercher pour cela le fichier 0004-rtl_bsd_drv_v191.tgz sur le site
de realtek. Je n'ai pas vu de modification dans le pilote intégré au
noyau d'origine entre le 10.3 et le 11, le problème devrait toujours
être là. Ce que je ne comprends pas, c'est que l'équipe de dev de
FreeBSD ne fournit pas d'une manière ou d'une autre ce pilote, la
licence associée semblant le permettre.
Bon alors FreeBSD supporte mal une carte réseau moisie, mais un pilote
existe que l'on peut compiler et qui semble fonctionner.
Ça me parait pas particulièrement invalidant, d'abord parce qu'il existe
de bonnes cartes réseaux qui fonctionnent très bien avec FreeBSD et
ensuite parce que même pour celle-ci, il y a une solution.
Maintenant, pourquoi ils n'intègrent pas le driver ? je sais
pas, peut-être que personne dans l'équipe n'utilise cette carte ou ne
l'a testé, peut-être que tu pourrais leur poser la question ou leur
envoyer le patch directement.Quant à la mémoire partagée POSIX et aux sémaphores associés,
ça existe officiellement sous FreeBSD depuis quelque temps, mais
c'est un peu étrange à utiliser. Il faut bidouiller le noyau et le
sysctl pour réussir à en faire quelque chose. Brut de fonderie,
c'est inutilisable (même gimp issu des ports se vautre sur un 10.2
ou 10.3 avec les paramètres par défaut, il faut le lancer avec
--no-shm).
Tu veux dire qu'il faut rajouter un paramètre du genre
kern.ipc.shm_allow_removed=1
dans /etc/sysctl.conf pour faire fonctionner Gimp ou Chrome ou certains
logiciels de ce genre ?
C'est pas pire que les limitations arbitraires de quantité de mémoire
disponible sur OpenBSD qui plantent n'importe quel browser à la
troisième page ouverte. C'est que de la conf.
En tous cas, sur mon FreeBSD 11, Gimp fonctionne parfaitement. Chrome
bagotte un peu sur certaines pages, mais Firefox fonctionnant
parfaitement, je pense que c'est du au port et non au système. Mais si
tu une procédure reproductible pour planter Gimp, je regarderai.
Il y a 15 ans, il fallait recompiler le kernel Linux pour faire
fonctionner n'importe quelle carte son et ça ne choquait personne.
Aujourd'hui il faut trifouiller sysctl pour faire marcher Gimp et tu
critiques l'ensemble du système pour un détail mineur.
On 2016-10-17, JKB <jkb@koenigsberg.invalid> wrote:
Chercher pour cela le fichier 0004-rtl_bsd_drv_v191.tgz sur le site
de realtek. Je n'ai pas vu de modification dans le pilote intégré au
noyau d'origine entre le 10.3 et le 11, le problème devrait toujours
être là. Ce que je ne comprends pas, c'est que l'équipe de dev de
FreeBSD ne fournit pas d'une manière ou d'une autre ce pilote, la
licence associée semblant le permettre.
Bon alors FreeBSD supporte mal une carte réseau moisie, mais un pilote
existe que l'on peut compiler et qui semble fonctionner.
Ça me parait pas particulièrement invalidant, d'abord parce qu'il existe
de bonnes cartes réseaux qui fonctionnent très bien avec FreeBSD et
ensuite parce que même pour celle-ci, il y a une solution.
Maintenant, pourquoi ils n'intègrent pas le driver ? je sais
pas, peut-être que personne dans l'équipe n'utilise cette carte ou ne
l'a testé, peut-être que tu pourrais leur poser la question ou leur
envoyer le patch directement.
Quant à la mémoire partagée POSIX et aux sémaphores associés,
ça existe officiellement sous FreeBSD depuis quelque temps, mais
c'est un peu étrange à utiliser. Il faut bidouiller le noyau et le
sysctl pour réussir à en faire quelque chose. Brut de fonderie,
c'est inutilisable (même gimp issu des ports se vautre sur un 10.2
ou 10.3 avec les paramètres par défaut, il faut le lancer avec
--no-shm).
Tu veux dire qu'il faut rajouter un paramètre du genre
kern.ipc.shm_allow_removed=1
dans /etc/sysctl.conf pour faire fonctionner Gimp ou Chrome ou certains
logiciels de ce genre ?
C'est pas pire que les limitations arbitraires de quantité de mémoire
disponible sur OpenBSD qui plantent n'importe quel browser à la
troisième page ouverte. C'est que de la conf.
En tous cas, sur mon FreeBSD 11, Gimp fonctionne parfaitement. Chrome
bagotte un peu sur certaines pages, mais Firefox fonctionnant
parfaitement, je pense que c'est du au port et non au système. Mais si
tu une procédure reproductible pour planter Gimp, je regarderai.
Il y a 15 ans, il fallait recompiler le kernel Linux pour faire
fonctionner n'importe quelle carte son et ça ne choquait personne.
Aujourd'hui il faut trifouiller sysctl pour faire marcher Gimp et tu
critiques l'ensemble du système pour un détail mineur.
On 2016-10-17, JKB wrote:Chercher pour cela le fichier 0004-rtl_bsd_drv_v191.tgz sur le site
de realtek. Je n'ai pas vu de modification dans le pilote intégré au
noyau d'origine entre le 10.3 et le 11, le problème devrait toujours
être là. Ce que je ne comprends pas, c'est que l'équipe de dev de
FreeBSD ne fournit pas d'une manière ou d'une autre ce pilote, la
licence associée semblant le permettre.
Bon alors FreeBSD supporte mal une carte réseau moisie, mais un pilote
existe que l'on peut compiler et qui semble fonctionner.
Ça me parait pas particulièrement invalidant, d'abord parce qu'il existe
de bonnes cartes réseaux qui fonctionnent très bien avec FreeBSD et
ensuite parce que même pour celle-ci, il y a une solution.
Maintenant, pourquoi ils n'intègrent pas le driver ? je sais
pas, peut-être que personne dans l'équipe n'utilise cette carte ou ne
l'a testé, peut-être que tu pourrais leur poser la question ou leur
envoyer le patch directement.Quant à la mémoire partagée POSIX et aux sémaphores associés,
ça existe officiellement sous FreeBSD depuis quelque temps, mais
c'est un peu étrange à utiliser. Il faut bidouiller le noyau et le
sysctl pour réussir à en faire quelque chose. Brut de fonderie,
c'est inutilisable (même gimp issu des ports se vautre sur un 10.2
ou 10.3 avec les paramètres par défaut, il faut le lancer avec
--no-shm).
Tu veux dire qu'il faut rajouter un paramètre du genre
kern.ipc.shm_allow_removed=1
dans /etc/sysctl.conf pour faire fonctionner Gimp ou Chrome ou certains
logiciels de ce genre ?
C'est pas pire que les limitations arbitraires de quantité de mémoire
disponible sur OpenBSD qui plantent n'importe quel browser à la
troisième page ouverte. C'est que de la conf.
En tous cas, sur mon FreeBSD 11, Gimp fonctionne parfaitement. Chrome
bagotte un peu sur certaines pages, mais Firefox fonctionnant
parfaitement, je pense que c'est du au port et non au système. Mais si
tu une procédure reproductible pour planter Gimp, je regarderai.
Il y a 15 ans, il fallait recompiler le kernel Linux pour faire
fonctionner n'importe quelle carte son et ça ne choquait personne.
Aujourd'hui il faut trifouiller sysctl pour faire marcher Gimp et tu
critiques l'ensemble du système pour un détail mineur.
