Annonce très prématurée, l'infrastructure du site n'est pas prête et énormément de travail reste à mener.
Pour ceux qui veulent une iso pour tester : ftp://ftp.archbsd.net/iso/untested/
Cette image est très basique et dédiée aux tests. Une autre sera mise à disposition prochainement quand le site sera entièrement fonctionnel.
L'installation se fait grosso-modo de la même façon que ArchLinux.
D'après mes souvenirs, c'est quand même très rare que des élèves aillent dans le fond uniquement pour s'opposer au professeur, ces spécimens là ont plus tendance à ne plus venir du tout en cours. ET quand bien même ils viendraient, les ignorer et ne pas parler suffisamment fort pour qu'ils entendent ravira tous le monde.
Et puis entasser (ou contraindre à se rapprocher) tous les élèves dans un coin de la classe, je n'en ai jamais tiré une expérience très agréable personnellement, je préférais largement être où je voulais et me rapprocher au cours suivant (ou pendant le cours même) si besoin.
Le placement des élèves dans une salle ou un amphi est clairement aléatoire, et avant tout une question de confort.
Dans une salle classique, certains préféreront être devant pour mieux voir/entendre le cours, certains voudront être au milieu, sans préférences particulières, certains préfèrent être à l'arrière ou près des murs pour avoir une vision globale de la classe, certains du coté des fenêtres pour limiter les reflets sur le tableau etc.
Dans un amphi, les différences sont encore plus marquées, dans les vieux bâtiments de fac mal chauffé et mal isolés, le seul endroit chaud est souvent en haut, le premier rang est bien souvent une punition car il faut se tordre le cou pour pouvoir lire le diaporama, le milieu est pas du tout pratique car il est au milieu et qu'il est parfois dur d'y circuler en début ou fin de cours etc.
Pour moi, un prof qui juge un élève sur son placement dans une salle part déjà du mauvais pied dans la gestion de son cours …
Mouai ok, vous l'avez compris comme ca… Moi j'ai compris "le dernier rang de chaise", pas "le dernier rang occupé". Faudrait lui demander, je vois pas comment trancher l'ambiguïté juste avec ce slide…
Et ça se passe comment dans les amphis où il y a moins de sièges que d'étudiants à faire entrer ? C'est un cas typique de première année de fac …
On demande à ceux assis dans les escaliers de faire le ménage ? À ceux du dernier rang (bien difficile à définir dans ces cas là) ?
Donc en gros les transhumanistes seront limités à faire des bidouilles qui se limiterons à des choses proches du « physique naturel » de l'homme actuelle sous peine de ne pas pouvoir les utiliser de manière simple. Enfin tout du moins tant qu'il ne s'amuseront pas à « recoder » des cerveaux en manipulant l'ADN :#
Posté par RbN .
En réponse au journal Un monde sans humain ?.
Évalué à 3.
Dernière modification le 25 octobre 2012 à 10:22.
Mes connaissances dans tout ça arrivent à leurs limites, ce qui suit ne sont que suppositions de ma part.
Le besoin de plasticité dépend aussi du besoin à mon avis, si il s'agit de commander un bras robotique mimant un vrai bras, la logique reste similaire et le cerveau doit sans doutes réutiliser ce qu'il sait déjà faire pour son propre corps.
Mais dans le cas d'un aveugle de naissance (qui n'a donc jamais vu), il me semble que si on lui rend la vue, son cerveau à besoin d'un certain temps d'adaptation pour pouvoir traiter toutes ces nouvelles informations, non ?
Ça me plaît aussi d'être imparfait, pour tout dire ma vue n'est pas très bonne et ça me convient bien. Rien ne me déplaît dans ma perception de l'environnement actuellement, c'est juste que le percevoir autrement pour tester ne me déplairait pas.
Et puis, qu'est ce que la « perfection » ? Si il s'agit d'être capable de ressentir tout les paramètres environnementaux, ça n'arrivera jamais, le panel est beaucoup trop vaste…
Il s'agit juste de voir quels sont les choses qui peuvent apporter à l'homme du confort ou des qualités au quotidien.
Posté par RbN .
En réponse au journal Un monde sans humain ?.
Évalué à -2.
Dernière modification le 25 octobre 2012 à 01:04.
Ce travail a déjà été fait, il y a des dispositifs accessible au grand public (notamment EPOC de Emotiv pour environ 300€) et ils marchent relativement bien, malheureusement, comme tu le dit, c'est à sens unique, mais c'est plus du au fonctionnement du cerveau adulte qui est déjà «formé». Si un tel dispositif était mis en œuvre sur un enfant en bas âge - durant la période de plasticité critique de son cerveau - il y a plus de chance qu'une communication bi-directionnelle puisse se créer.
J'ai pu voir un tel dispositif en fonctionnement permettant de contrôler un jeu de course basique, le cerveau s'adapte en moins d'une minute (grâce à la faible plasticité qu'il conserve même à l'âge adulte) sans que l'ordinateur n'effectue une quelconque phase d'apprentissage.
Je trouve tout cela très excitant, qui ne serait pas intéressé par un sens supplémentaire ou une augmentation quelconque lui permettant de percevoir son environnement d'une nouvelle façon ?
Il me semble avoir vu que la synchronisation entre serveurs ownCloud est à venir, ce qui parait maintenant indispensable vu que le montage de cloud étrangers comme Google Drive est présente.
Le cas que tu cites se prête bien à ce genre de réappropriation de la paternité, mais pas tous :
Imaginons le cas où la personne qui a initiée la dépêche fait le mort et où les contributeurs se partagent les changements comme suit : A à écrit 42% de la dépêche, B a écrit 43%, l'initiateur en a écrit 3%, et dix autres contributeurs se partagent le reste. Qui mettre ?
J'imagine assez bien dans cette même barre de titre un classement des contributeurs en ordre décroissant d'influence, ça permettrait de savoir quelles ont été les personnes les plus productives sur la dépêche, et ça permettrait d'éviter partiellement ce type de cas, où un contributeur corrige un détail mais ne souhaite pas pour autant être cité comme auteur.
Je suis lecteur depuis quelques années, contributeur depuis moins d'années (moins de 3 dépêches au compteur), mais l'espace de rédaction est clairement une bonne chose :
ma première dépêche, j'ai bien trouvé le temps de la commencer, mais pas celui de la finir, un copier-coller un peu sauvage sur l'espace de rédaction aura suffit à la laisser entre les mains de braves gens qui l'ont finie ;
* ma troisième (le gros pâté sur la domotique), je l'ai commencé dans mon coin, quand j'ai vu l'étendue de ce qu'il fallait que j'écrive, ça m'a fait peur, j'ai posé le squelette sur l'espace de rédaction, et en parallèle, j'ai cherché les personnes compétentes sur le sujet et qui sont inscrites sur le site pour les pinger par mail, afin quelles m'aident. L'appel n'a pas été totalement entendu, mais j'ai eu de l'aide quand même, et c'est le principal.
Je déplore d'ailleurs un peu ce point, il y a beaucoup de personnes compétentes sur beaucoup de sujets présentes ici, il serait bon de donner un moyen de faire se rencontrer ces dernières avec les dépêches en rédaction. Au hasard, un système où un inscrit spécifie ses domaines de compétences (via les catégories, les tags …) et se voit proposer de contribuer de façon très explicite quand une dépêche concernant un de ses domaines de compétences est en cours de rédaction.
Quoiqu'il en soit, participer est gratifiant, et peut même devenir rentable avec les livres à gagner. Il est au final assez simple de trouver des sujets encore non abordés ici pour en faire de bonnes dépêches. Je ne suis pas forcément très compétent en informatique, mais il y a d'autres domaines qui méritent d'être abordés ici. Par exemple, ma prochaine dépêche devrait être sur le sujet du «bio-hacking», dans quelques mois.
Amis lecteurs, participez ;)
De mon point de vue, DLFP m'a tellement apporté, y consacré quelques heures par mois n'est pas très dur.
Voilà la documentation sur la sécurité de EnOcean, je ne l'ai pas épluchée en détails, et c'était une version bien plus ancienne à laquelle j’avais eu accès.
Quelques petites question pour Raoul Hecky qui à eu la gentillesse de rédiger la partie sur Calaos vu qu'il travaille pour cette société :
Le code est «en majorité sous GPL v3», ça veut dire que le reste est proprio ? Si oui, qu'est ce qui motive une licence propriétaire pour ces parties ?
Il me semble avoir vu dans un commentaire quelque part que l'automate en question est un automate Wago, pourquoi ce choix ?
HS : domotiki.fr est tombé sous la pression des utilisateurs de linuxfr ? Oo
Tu a plus de chance de faire un beau déni de service à cause de l'énergie limitée des devices que de casser l'algorythme en fait.
Dans les implémentations actuelles, les trames émises sont toujours les mêmes, le rejeu de trames est très simple pour ceux qui veulent allumer la lumière chez leur voisins.
Dans la spécification en draft, la version la plus sécurisée passe par AES, la version «intermédiaire» passe par un chiffrement de flux RC4, le même que pour WEP …
Dans tout les cas, l'énergie est critique, plus on chiffre fortement, plus il en est consommée, l'équilibre est complexe à trouver.
Par contre, les protocoles typiques "électricité", "batiment" (GTB) ou "chauffage" (GTC) sont typiquement utilisés dans leur domaine et pratiquement pas ailleurs. >Personnellement j'ai constaté un cloisonnement vraiment très prononcé à ce niveau.
Juste pour le plaisir du troll, quand on voit les limitations de protocoles tels que KNX, DALI, LON … qui sont pour certains très spécifiques, je pense que c'est normal de voir ce cloisonnement.
Et concernant BACnet, je ne suis pas pour le moment convaincu, j'ai l'impression que quelque chose cloche avec ce protocole. Je laisse donc le temps passer pour voir ce qui va se passer, beaucoup d'acteurs se tournent vers lui (et c'est peut-être cela justement, ça provoque trop l'unanimité …).
publier des mises à jour quand le besoin s'en fait sentir ;
Tout a fait, est-ce que le client va accepter un mise a jour de son installation? un arret pourrait lui couter beaucoup… Le client serait ok pour faire une mise a jour >de securite si celle-ci ne modifie rien, si la mise a jour de securite est incluse dans une mise a jour globale, ca devient bcp plus difficile de convaincre…
Et c'est là que les constructeurs doivent comprendre que modulariser leurs systèmes serait un plus, les mises à jour peuvent être distribuée et appliquée plus facilement et rapidement dans ce cas. Bien que certaines mises à jour impliqueront toujours une interruption de service, ce seront aux exploitants et aux intégrateurs de déterminer si cette mise à jour et interruption est nécessaire (de la même façon que le font de nombreux administrateurs systèmes sur leurs serveurs dans le cas d'une maj noyau).
mettre à la poubelle les automates des années 90 et 2000 pour repartir sur des bases saines
Ok, mais ca ne marche que lors que l'on met a jour son usine ou bien lors de la construction d'une nouvelle usine. En industrie, il y a regulierement le "jusque ici >tout va bien".
Comme je le disais dans un autre commentaire, je parle pour les constructeurs d'automates, pas pour les exploitants. Je suis parfaitement conscient qu'un exploitant ne peux se permettre de mettre en panne une chaine de production parfaitement fonctionnelle juste pour suivre mes lubies.
Je connais certains cas de figure ou le client a fait des stocks de PLC qui ne sont plus produit ni supporte mais qui permette de remplacer le materiel défectueux >tres rapidement…
15ans une duree de vie? pour la partie soft oui, pour la partie materiel, je n'en suis pas sur du tout, je parierais meme sur un peu plus - exemple d'une usine de >production de verre avec une duree de vie de 21ans
Je n'était pas au courant de cas de ce genre, qui sont du coup relativement inquiétant je trouve.
Que penses-tu du protocole REST ? (attention abus de protocole versus REST, mais bon je force un peu pour voir ta reaction).
Que penses-tu de la contrainte venant de l"IT ou seul le port 80 et HTTP sont autorisé a travers le firewall ?
Que penses-tu de la notion de webservice qui semble etre la demande venant de client pour pouvoir recuperer tres facilement des informations pour la partie >IT/business ?
Dans l'ordre :
REST : tout dépend ce qu'on veut en faire, si c'est pour de la configuration, clairement non, trop risqué, si c'est pour de la remontée d'information sur la production, oui cela est sans doute envisageable.
Port 80 et cie. : les pare-feu interdisent généralement cela vers l'extérieur, ce qui est dans notre cas bien vu que l'automate n'a rien à aller voir à l'extérieur dans l'idéal. En interne à l'entreprise, souvent beaucoup de protocoles peuvent être mis en œuvre, et autant en profiter à mon humble avis. (et puis bon, si seul le port 80 est autorisé vers l'extérieur, mauvais IT, changer IT ;)
Webservice : pour les outils de BI et consort, vu que tous ces outils veulent mettre leur nez dans la production, la plupart intègrent un grand nombre de connecteurs pour aller parler à tout le monde, autant en profiter (et vu que tous veulent contrôler le monde, les nouveaux connecteurs arrivent vite).
D'une manière générale, je suis plutôt inquiet quand je voit la complexité et les failles apportées par les choses du port 80 pour le peu de gain par rapport à un protocole qui offrirait les mêmes possibilités sans vouloir être généraliste comme le web.
Le monde industriel avait l'habitude d'etre sur un reseau dedie pour divers raisons et se retrouve maintenant connecte a internet. Cette ouverture se passe mal, >la partie industrie a du mal a suivre la partie IT et inversement: pour deployer un patch dans une usine pour un PLC ou un SCADA, ca prend en general 6 mois, >le temps d'ajoute ca dans leplanning, d'avoir les personnes internes et l'integrateur systeme sur place, d'avoir une solution de replis dans le cas d'avoir Murphy >parmis les invites…
Oui, et c'est bien là le problème, autant faciliter autant que possible le déploiment de ces patch et cela se passe sur le système des automates pour la plupart des cas. Si la mise à jour est si complexe, c'est aussi parce que l'automate n'intègre rien de semblable à un apt-get. Les processus de mise à jour sont beaucoup trop lourds.
Maintenant il semblerait que le point initial soit de connaitre son reseaux. si personne ne sait ce qu'il y a sur son reseaux, sa topologie et les differents serveurs, >le hack n'en sera que plus facile.
Avoir un outil centralise - je supprime un utilisateur (sous traitant ou demission) et cet utilisateur n'a plus aucun access a mon installation est plutot crucial non?
Gérer finnement les permissions des divers utilisateurs est mon avis une meilleure solution, surtout si cela peut éviter une architecture centralisée qui apporte ses faiblesses elle aussi.
Mais est-ce que je vais authorise quelqu'un de l'IT a venir touche mon process industriel et la partie safety qui va avec?
Si la partie safety passe par une bonne gestion de la sécurité au sens informatique du terme (et on sait que les deux sont liés) cela est nécessaire, maintenant, je sais que certaines personnes seront contre le fait qu'on touche à leurs systèmes de production, ce qui est un cas relativement classique au final. Je pense sincèrement que ces personnes ont des choses à apprendre concernant la sécurité informatique.
Ne pas oublier la partie social engineering, et surtout que cherche un pirate a faire sur ce type de reseaux? Generalement, recuperer les informations de >production se passera plus par un soft de plus haut niveau, le but initial serait plus de faire tomber la partie supervision et donc d'interrompre la production ou >"juste" de faire produire des yahourts sans lait…
Les histoires a la stuxnet, je dirais que c'est une exception ?
Stuxnet, oui, mais il s'agit là d'une attaque d'une envergure peu commune.
Maintenant, comme le dit Nicolas Boulay, la plupart des attaques actuelles sont faites pour le fun actuellement (un adolescent polonais à fait dérailler un train sans trop comprendre ce qu'il faisait il y a quelques années), mais qui sait ce que les cyber-mafias et autre vont inventer pour monétiser les interruptions de production ou les vols d'informations ?
(concernant les yaourts, j'opterais pour enlever les conservateurs, plus néfaste et vicieux pour le producteur et plus discret, retirer le lait conduirais à un surplus de stock conséquent en quelques heures)
Pour ce qui est du "vivement mettre à la poubelle les automates existants", je rigole !
Moi aussi, je parle pour les constructeurs d'automates, pas pour les exploitants. Je suis parfaitement conscient qu'un exploitant ne peux se permettre de mettre en panne une chaine de production parfaitement fonctionnelle juste pour suivre mes lubies.
Cette phrase était surtout là pour énoncer mon souhait d'en finir avec les automates n'ayant été conçu avec aucunes notion de sécurité alors que ça deviens vital pour cette industrie.
Concernant les produits Wago, je reconnais ne pas les connaître suffisamment, peut être pourras tu m'éclairer : comment se passe la désactivation d'une fonctionnalité/module ? Je me souviens seulement avoir vu des personnes en configurer avec CoDeSys qui lui est troué maintenant.
[^] # Re: Que du bonheur !
Posté par RbN . En réponse au journal La loi sur la programmation militaire est adoptée !. Évalué à 8.
Des jeunes en chimiothérapie ?
[^] # Re: Que vaut un mot de passe comme ceux de pwgen ?
Posté par RbN . En réponse au journal La proche fin des mots de passe. Évalué à 1.
À priori, pas grand chose, des biais dans la génération ont été découverts :
cf http://openwall.com/lists/oss-security/2013/09/26/1
La bonne nouvelle, avec ta commande, tu ne tombe que dans le dernier problème à première vue.
[^] # Proxy
Posté par RbN . En réponse à la dépêche NetworkManager 0.9.8 propose la création de points d'accès. Évalué à 4.
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/TODO
C'est prévu au programme, il faut juste que des développeurs s'y intéressent !
# Tôt
Posté par RbN . En réponse au journal Nouvelle venue dans le monde des Archers. Évalué à 3.
Annonce très prématurée, l'infrastructure du site n'est pas prête et énormément de travail reste à mener.
Pour ceux qui veulent une iso pour tester : ftp://ftp.archbsd.net/iso/untested/
Cette image est très basique et dédiée aux tests. Une autre sera mise à disposition prochainement quand le site sera entièrement fonctionnel.
L'installation se fait grosso-modo de la même façon que ArchLinux.
# Juste un lien
Posté par RbN . En réponse à la dépêche Fin des « labs » de la Hadopi. Évalué à 10.
Voici un lien d'un article d'une personne ayant travaillé dans ces «Labs» et qui explique son ressenti.
http://www.hackersrepublic.org/cultureduhacking/la-face-cachee-des-Labs
Bonne lecture.
[^] # Re: Pour une fois
Posté par RbN . En réponse au journal Interview de Linus à LinuxCon Europe 2012. Évalué à 3.
D'après mes souvenirs, c'est quand même très rare que des élèves aillent dans le fond uniquement pour s'opposer au professeur, ces spécimens là ont plus tendance à ne plus venir du tout en cours. ET quand bien même ils viendraient, les ignorer et ne pas parler suffisamment fort pour qu'ils entendent ravira tous le monde.
Et puis entasser (ou contraindre à se rapprocher) tous les élèves dans un coin de la classe, je n'en ai jamais tiré une expérience très agréable personnellement, je préférais largement être où je voulais et me rapprocher au cours suivant (ou pendant le cours même) si besoin.
[^] # Re: Pour une fois
Posté par RbN . En réponse au journal Interview de Linus à LinuxCon Europe 2012. Évalué à 3.
Le placement des élèves dans une salle ou un amphi est clairement aléatoire, et avant tout une question de confort.
Dans une salle classique, certains préféreront être devant pour mieux voir/entendre le cours, certains voudront être au milieu, sans préférences particulières, certains préfèrent être à l'arrière ou près des murs pour avoir une vision globale de la classe, certains du coté des fenêtres pour limiter les reflets sur le tableau etc.
Dans un amphi, les différences sont encore plus marquées, dans les vieux bâtiments de fac mal chauffé et mal isolés, le seul endroit chaud est souvent en haut, le premier rang est bien souvent une punition car il faut se tordre le cou pour pouvoir lire le diaporama, le milieu est pas du tout pratique car il est au milieu et qu'il est parfois dur d'y circuler en début ou fin de cours etc.
Pour moi, un prof qui juge un élève sur son placement dans une salle part déjà du mauvais pied dans la gestion de son cours …
[^] # Re: Pour une fois
Posté par RbN . En réponse au journal Interview de Linus à LinuxCon Europe 2012. Évalué à 1.
Et ça se passe comment dans les amphis où il y a moins de sièges que d'étudiants à faire entrer ? C'est un cas typique de première année de fac …
On demande à ceux assis dans les escaliers de faire le ménage ? À ceux du dernier rang (bien difficile à définir dans ces cas là) ?
[^] # Re: Ha?
Posté par RbN . En réponse au journal Un monde sans humain ?. Évalué à 3.
Hum, très intéressant tout ça.
Donc en gros les transhumanistes seront limités à faire des bidouilles qui se limiterons à des choses proches du « physique naturel » de l'homme actuelle sous peine de ne pas pouvoir les utiliser de manière simple. Enfin tout du moins tant qu'il ne s'amuseront pas à « recoder » des cerveaux en manipulant l'ADN :#
[^] # Re: Ha?
Posté par RbN . En réponse au journal Un monde sans humain ?. Évalué à 3. Dernière modification le 25 octobre 2012 à 10:22.
Mes connaissances dans tout ça arrivent à leurs limites, ce qui suit ne sont que suppositions de ma part.
Le besoin de plasticité dépend aussi du besoin à mon avis, si il s'agit de commander un bras robotique mimant un vrai bras, la logique reste similaire et le cerveau doit sans doutes réutiliser ce qu'il sait déjà faire pour son propre corps.
Mais dans le cas d'un aveugle de naissance (qui n'a donc jamais vu), il me semble que si on lui rend la vue, son cerveau à besoin d'un certain temps d'adaptation pour pouvoir traiter toutes ces nouvelles informations, non ?
[^] # Re: Excitant
Posté par RbN . En réponse au journal Un monde sans humain ?. Évalué à 2.
On a vite fait le tour !
[^] # Re: Excitant
Posté par RbN . En réponse au journal Un monde sans humain ?. Évalué à 2.
Ça me plaît aussi d'être imparfait, pour tout dire ma vue n'est pas très bonne et ça me convient bien. Rien ne me déplaît dans ma perception de l'environnement actuellement, c'est juste que le percevoir autrement pour tester ne me déplairait pas.
Et puis, qu'est ce que la « perfection » ? Si il s'agit d'être capable de ressentir tout les paramètres environnementaux, ça n'arrivera jamais, le panel est beaucoup trop vaste…
Il s'agit juste de voir quels sont les choses qui peuvent apporter à l'homme du confort ou des qualités au quotidien.
[^] # Re: Ha?
Posté par RbN . En réponse au journal Un monde sans humain ?. Évalué à -2. Dernière modification le 25 octobre 2012 à 01:04.
Ce travail a déjà été fait, il y a des dispositifs accessible au grand public (notamment EPOC de Emotiv pour environ 300€) et ils marchent relativement bien, malheureusement, comme tu le dit, c'est à sens unique, mais c'est plus du au fonctionnement du cerveau adulte qui est déjà «formé». Si un tel dispositif était mis en œuvre sur un enfant en bas âge - durant la période de plasticité critique de son cerveau - il y a plus de chance qu'une communication bi-directionnelle puisse se créer.
J'ai pu voir un tel dispositif en fonctionnement permettant de contrôler un jeu de course basique, le cerveau s'adapte en moins d'une minute (grâce à la faible plasticité qu'il conserve même à l'âge adulte) sans que l'ordinateur n'effectue une quelconque phase d'apprentissage.
# Excitant
Posté par RbN . En réponse au journal Un monde sans humain ?. Évalué à 9.
Je trouve tout cela très excitant, qui ne serait pas intéressé par un sens supplémentaire ou une augmentation quelconque lui permettant de percevoir son environnement d'une nouvelle façon ?
[^] # Re: Clustering ?
Posté par RbN . En réponse à la dépêche Sortie d’ownCloud 4.5.0. Évalué à 2.
Il me semble avoir vu que la synchronisation entre serveurs ownCloud est à venir, ce qui parait maintenant indispensable vu que le montage de cloud étrangers comme Google Drive est présente.
# Et les cas étranges ?
Posté par RbN . En réponse à l’entrée du suivi réattribution de paternité de dépêche. Évalué à 1 (+0/-0).
Le cas que tu cites se prête bien à ce genre de réappropriation de la paternité, mais pas tous :
Imaginons le cas où la personne qui a initiée la dépêche fait le mort et où les contributeurs se partagent les changements comme suit : A à écrit 42% de la dépêche, B a écrit 43%, l'initiateur en a écrit 3%, et dix autres contributeurs se partagent le reste. Qui mettre ?
La piste a explorer est plutôt du coté de cette proposition à mon avis : https://linuxfr.org/suivi/reconnaitre-les-contributeurs
# Peaufinage ++
Posté par RbN . En réponse à l’entrée du suivi Reconnaître les contributeurs. Évalué à 1 (+0/-0).
J'imagine assez bien dans cette même barre de titre un classement des contributeurs en ordre décroissant d'influence, ça permettrait de savoir quelles ont été les personnes les plus productives sur la dépêche, et ça permettrait d'éviter partiellement ce type de cas, où un contributeur corrige un détail mais ne souhaite pas pour autant être cité comme auteur.
# Un avis de plus dans la mare
Posté par RbN . En réponse à la dépêche Retour d’expérience sur l’espace de rédaction de LinuxFr.org. Évalué à 10.
Je suis lecteur depuis quelques années, contributeur depuis moins d'années (moins de 3 dépêches au compteur), mais l'espace de rédaction est clairement une bonne chose :
* ma troisième (le gros pâté sur la domotique), je l'ai commencé dans mon coin, quand j'ai vu l'étendue de ce qu'il fallait que j'écrive, ça m'a fait peur, j'ai posé le squelette sur l'espace de rédaction, et en parallèle, j'ai cherché les personnes compétentes sur le sujet et qui sont inscrites sur le site pour les pinger par mail, afin quelles m'aident. L'appel n'a pas été totalement entendu, mais j'ai eu de l'aide quand même, et c'est le principal.
Je déplore d'ailleurs un peu ce point, il y a beaucoup de personnes compétentes sur beaucoup de sujets présentes ici, il serait bon de donner un moyen de faire se rencontrer ces dernières avec les dépêches en rédaction. Au hasard, un système où un inscrit spécifie ses domaines de compétences (via les catégories, les tags …) et se voit proposer de contribuer de façon très explicite quand une dépêche concernant un de ses domaines de compétences est en cours de rédaction.
Quoiqu'il en soit, participer est gratifiant, et peut même devenir rentable avec les livres à gagner. Il est au final assez simple de trouver des sujets encore non abordés ici pour en faire de bonnes dépêches. Je ne suis pas forcément très compétent en informatique, mais il y a d'autres domaines qui méritent d'être abordés ici. Par exemple, ma prochaine dépêche devrait être sur le sujet du «bio-hacking», dans quelques mois.
Amis lecteurs, participez ;)
De mon point de vue, DLFP m'a tellement apporté, y consacré quelques heures par mois n'est pas très dur.
[^] # Re: prix ?
Posté par RbN . En réponse à la dépêche Domotique libre, où en sommes‐nous ?. Évalué à 2.
www.enocean.com/en/security-specification/
Voilà la documentation sur la sécurité de EnOcean, je ne l'ai pas épluchée en détails, et c'était une version bien plus ancienne à laquelle j’avais eu accès.
# Calaos
Posté par RbN . En réponse à la dépêche Domotique libre, où en sommes‐nous ?. Évalué à 3.
Quelques petites question pour Raoul Hecky qui à eu la gentillesse de rédiger la partie sur Calaos vu qu'il travaille pour cette société :
Le code est «en majorité sous GPL v3», ça veut dire que le reste est proprio ? Si oui, qu'est ce qui motive une licence propriétaire pour ces parties ?
Il me semble avoir vu dans un commentaire quelque part que l'automate en question est un automate Wago, pourquoi ce choix ?
HS : domotiki.fr est tombé sous la pression des utilisateurs de linuxfr ? Oo
[^] # Re: prix ?
Posté par RbN . En réponse à la dépêche Domotique libre, où en sommes‐nous ?. Évalué à 2.
Tu a plus de chance de faire un beau déni de service à cause de l'énergie limitée des devices que de casser l'algorythme en fait.
Dans les implémentations actuelles, les trames émises sont toujours les mêmes, le rejeu de trames est très simple pour ceux qui veulent allumer la lumière chez leur voisins.
Dans la spécification en draft, la version la plus sécurisée passe par AES, la version «intermédiaire» passe par un chiffrement de flux RC4, le même que pour WEP …
Dans tout les cas, l'énergie est critique, plus on chiffre fortement, plus il en est consommée, l'équilibre est complexe à trouver.
[^] # Re: Petite correction
Posté par RbN . En réponse à la dépêche État des lieux de la sécurité industrielle. Évalué à 1.
Juste pour le plaisir du troll, quand on voit les limitations de protocoles tels que KNX, DALI, LON … qui sont pour certains très spécifiques, je pense que c'est normal de voir ce cloisonnement.
Et concernant BACnet, je ne suis pas pour le moment convaincu, j'ai l'impression que quelque chose cloche avec ce protocole. Je laisse donc le temps passer pour voir ce qui va se passer, beaucoup d'acteurs se tournent vers lui (et c'est peut-être cela justement, ça provoque trop l'unanimité …).
[^] # Re: Petite correction
Posté par RbN . En réponse à la dépêche État des lieux de la sécurité industrielle. Évalué à 3.
Aie !
Sans compter que cela implique que tout soit en mémoire quelque part, ce qui permet le rop : http://en.wikipedia.org/wiki/Return-oriented_programming
[^] # Re: un petit point vue...
Posté par RbN . En réponse à la dépêche État des lieux de la sécurité industrielle. Évalué à 2.
Et c'est là que les constructeurs doivent comprendre que modulariser leurs systèmes serait un plus, les mises à jour peuvent être distribuée et appliquée plus facilement et rapidement dans ce cas. Bien que certaines mises à jour impliqueront toujours une interruption de service, ce seront aux exploitants et aux intégrateurs de déterminer si cette mise à jour et interruption est nécessaire (de la même façon que le font de nombreux administrateurs systèmes sur leurs serveurs dans le cas d'une maj noyau).
Comme je le disais dans un autre commentaire, je parle pour les constructeurs d'automates, pas pour les exploitants. Je suis parfaitement conscient qu'un exploitant ne peux se permettre de mettre en panne une chaine de production parfaitement fonctionnelle juste pour suivre mes lubies.
Je n'était pas au courant de cas de ce genre, qui sont du coup relativement inquiétant je trouve.
Dans l'ordre :
REST : tout dépend ce qu'on veut en faire, si c'est pour de la configuration, clairement non, trop risqué, si c'est pour de la remontée d'information sur la production, oui cela est sans doute envisageable.
Port 80 et cie. : les pare-feu interdisent généralement cela vers l'extérieur, ce qui est dans notre cas bien vu que l'automate n'a rien à aller voir à l'extérieur dans l'idéal. En interne à l'entreprise, souvent beaucoup de protocoles peuvent être mis en œuvre, et autant en profiter à mon humble avis. (et puis bon, si seul le port 80 est autorisé vers l'extérieur, mauvais IT, changer IT ;)
Webservice : pour les outils de BI et consort, vu que tous ces outils veulent mettre leur nez dans la production, la plupart intègrent un grand nombre de connecteurs pour aller parler à tout le monde, autant en profiter (et vu que tous veulent contrôler le monde, les nouveaux connecteurs arrivent vite).
D'une manière générale, je suis plutôt inquiet quand je voit la complexité et les failles apportées par les choses du port 80 pour le peu de gain par rapport à un protocole qui offrirait les mêmes possibilités sans vouloir être généraliste comme le web.
Oui, et c'est bien là le problème, autant faciliter autant que possible le déploiment de ces patch et cela se passe sur le système des automates pour la plupart des cas. Si la mise à jour est si complexe, c'est aussi parce que l'automate n'intègre rien de semblable à un apt-get. Les processus de mise à jour sont beaucoup trop lourds.
Gérer finnement les permissions des divers utilisateurs est mon avis une meilleure solution, surtout si cela peut éviter une architecture centralisée qui apporte ses faiblesses elle aussi.
Si la partie safety passe par une bonne gestion de la sécurité au sens informatique du terme (et on sait que les deux sont liés) cela est nécessaire, maintenant, je sais que certaines personnes seront contre le fait qu'on touche à leurs systèmes de production, ce qui est un cas relativement classique au final. Je pense sincèrement que ces personnes ont des choses à apprendre concernant la sécurité informatique.
Stuxnet, oui, mais il s'agit là d'une attaque d'une envergure peu commune.
Maintenant, comme le dit Nicolas Boulay, la plupart des attaques actuelles sont faites pour le fun actuellement (un adolescent polonais à fait dérailler un train sans trop comprendre ce qu'il faisait il y a quelques années), mais qui sait ce que les cyber-mafias et autre vont inventer pour monétiser les interruptions de production ou les vols d'informations ?
(concernant les yaourts, j'opterais pour enlever les conservateurs, plus néfaste et vicieux pour le producteur et plus discret, retirer le lait conduirais à un surplus de stock conséquent en quelques heures)
[^] # Re: Petite correction
Posté par RbN . En réponse à la dépêche État des lieux de la sécurité industrielle. Évalué à 2.
Merci à vous deux pour ces précisions utiles.
Moi aussi, je parle pour les constructeurs d'automates, pas pour les exploitants. Je suis parfaitement conscient qu'un exploitant ne peux se permettre de mettre en panne une chaine de production parfaitement fonctionnelle juste pour suivre mes lubies.
Cette phrase était surtout là pour énoncer mon souhait d'en finir avec les automates n'ayant été conçu avec aucunes notion de sécurité alors que ça deviens vital pour cette industrie.
Concernant les produits Wago, je reconnais ne pas les connaître suffisamment, peut être pourras tu m'éclairer : comment se passe la désactivation d'une fonctionnalité/module ? Je me souviens seulement avoir vu des personnes en configurer avec CoDeSys qui lui est troué maintenant.