let antibarbie = xp <- xp - 1 a écrit 507 commentaires

Pour la durée de vie :

en télégestion

on reçoit encore de temps en temps des appels de clients avec des systèmes de plus de 20 ans qui fonctionnent sans trop de problème (avec des cartes exotiques de communications sur bus ISA !). Bien évidemment, plus aucun support technique n'est possible dans ces situations, et aucune sécurité n'a été mise en place à l'époque.
Cela n'a pas l'air d'inquiéter les exploitants qui jouent la carte du moindre coût. (nb: on l'observe au niveau informatique : la redondance a parfois déjà joué son rôle à plusieurs niveaux, les disques RAID à moitié bousillés et les machines redondantes déjà grillées depuis longtemps). Bref, c'est plutôt folklorique dans les usines en France (heureusement ce n'est pas non plus une généralité).

Le risque au niveau sécurité, principalement un vol de données d'exploitation, accessibles à distance et consultées en clair et sans mot de passe.

dans les usines et dans le contrôle anti-pollution

tu as également des systèmes qui perdurent depuis plus de 15 ans, et qui sont régulièrement patchés pour coller aux normes, mais on ne voit aucune évolution des automatismes ni des systèmes informatiques, et certainement pas au niveau de la sécurité.

Le risque reste cependant limité, piratage par un concurrent pour que la DREAL ferme l'usine ou pénalise financièrement l'exploitant (?).

en production

Il y a aussi un certain nombre de groupes qui suivent les préconisation des constructeurs, et profitent d'une amélioration de l'usine pour effectuer les mises à jour des automates.. mais dans ce que j'ai pu constater ces dix dernières années, ça reste tout de même une minorité.

Pour l'anecdote, on a environ une fois par mois des responsables de maintenance, qui appellent paniqués pour savoir si on peut dépanner leur unique automate grillé (souvent obsolète) et nécessaire à la production de l'usine..

Je n'ai pas une vision exhaustive de toute leur gamme de produits, mais tu achètes un contrôleur suivant le besoin principal et tu as une bécane qui utilise les protocoles (en client ou en serveur) : HTTP, BOOTP, DHCP, SNMP, NTP, MODBUS/TCP, MODBUS/RTU, KNX.

(nb: pas certain que cette combinaison exacte existe, mais c'est à peu près l'idée).

Après tu peux tout activer ou désactiver comme bon te semble (e.g. via l'interface web). Probablement c'est également disponible dans CodeSys mais je t'avoue que je bosse plus du coté SCADA que du coté automate—faudrait que je cuisine mes collègues ou le commercial Wago.

Si je peux compléter les différentes les familles de protocoles, on peut trouver, avec différents degrés de sécurité :

• les protocoles haut niveau comme OPC-DA, OPC-UA, BACnet, KNX, SNMP (nb: excepté SNMPv3, on les retrouve souvent utilisés sans aucune sécurité en pratique : la priorité étant que ça fonctionne, les exploitants et les intégrateurs n'en ont rien à cirer du méchant h4xor qui se connecte au réseau, et en général ça fonctionne sur un réseau coupé du reste du monde en se disant que ça ne risque rien)

• Des protocoles d'échange fichier, où typiquement un fichier type CSV est échangé par FTP, HTTP, NFS, CIFS, ou autre protocole de transfert de fichier.

• Les protocoles traditionnels (sans sécurité) comme LON, modbus/TCP, modbus/RTU

• des échanges par web services (ça vient de plus en plus à la mode)

• des échanges par base de données SQL interposées

• Les protocoles constructeur, alors là on se lâche, c'est tout et n'importe quoi, quelques dérivés anecdotiques non standard du modbus/jbus façon "personnalisée", et niveau sécurité.. rien du tout.

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.

Pour ce qui est du "vivement mettre à la poubelle les automates existants", je rigole ! Un industriel, même s'il doit acheter un module de remplacement hors de prix (i.e. Siemens majore les factures à l'ancienneté), paiera le remplacement de la pièce plutôt que la mise à jour du site. La mise à la poubelle coûte très cher en ingénierie, en temps de mise à l'arrêt, tests et corrections de problèmes.

La règle semble être on le peut plus claire : on ne touche pas à un système qui fonctionne.

Aujourd'hui on a encore des clients qui ont 4 ou 5 générations d'automates complètement différents sur un même site, qui ont entre 20 et 1 ans d'âge, tout constructeurs, protocoles et liaisons physiques mélangées!

Concernant Wago, je ne suis pas fondamentalement d'accord avec les commentaires : d'expérience, la surface d'exposition est complètement paramétrable, et leurs produits sont simples et efficaces à utilise (après l'atelier de configuration est basé sur Cimetrics : c'est de la m…. ce driver, ils auraient dû faire ça en natif). (nb: je travaille pas pour Wago)

troll: Vivement que BACnet mette tout le monde d'accord.. et qu'on dégage une bonne fois pour toutes ces abominations d'OPC !

C'est marrant ça :

Contrairement à Internet, les transferts de fichiers utilisent la pleine vitesse du modem ; la reprise d'un transfert interrompu est possible avec le protocole Z-Modem. 

Personnellement, j'avais un très mauvais souvenir des transferts de fichiers qui, sur erreur, recommencent encore et encore ; et les transferts interrompus qui reprennent à un endroit précédent largement l'endroit où ils ont été interrompus ; bref le coup de la barre de progression qui marche à l'envers, bien avant que Mickeysoft ne la démocratise.

Si le code de copier/coller n'était pas assez résistant/performant, je vais imaginer que c'était en partie la motivation d'un tel brico projet, pourquoi ne pas avoir patché Konqueror (ou autre composant qui fait de la copie), pour atteindre cet objectif de performance améliorée et résilience aux défauts survenant pendant la copie ?

ps: réponse non acceptée, sous windows on peut pas faire un patch

Ou plutôt de répondre "oui mais.. il te faut écrire ça autrement"

j'avais à l'époque fait quelques comparatifs, sur une application qui travaille basiquement sur des tables clef/valeur. Oracle (sans tuning) et PostgreSQL (réglage en suivant le manuel) tenaient la charge jusqu'à 7000 trans/s. SQL Server 2005 (sans tuning) autour de 3000 et MySQL 5.0 (sans tuning) 2300 en InnoDb : sur un vieux Dell Poweredge 2900 (1x Xeon 5160, linux 64 bits) en RAID10 SAS.

Pour les question de "bloat" sur des tables de 200.000.000 de lignes, en faisant confiance uniquement à l'auto-vacuum, on perdait jusqu'à 5Go dans la table et 2Go dans les index, les "Bitmap Index Scan" de PostgreSQL passaient de quelques ms à plusieurs secondes.

Après, selon la doc et le forums, ça dépend du type d'utilisation, on peut tomber dans des cas qui accentuent le "bloat".

(aujourd'hui je vois plutôt des setup "low cost", certes pour des applications non critiques, avec une volumétrie raisonnable de 500Go sur du bête HP DL360 G6)

Pour avoir utilisé un SQL Server, Oracle, MySQL et PostgreSQL en entreprise (principalement pour de l'archivage—qui pourrait maintenant être fait avec du NoSQL), PostgreSQL domine largement dans les fonctionnalités pour le développeur, l'installation, la facilité de paramétrage, et l'absence de trop mauvaises surprises. Oracle domine pour la complexité, et l'impression de "savoir tout faire".

il y a cependant quelque (gros) couacs dès que la volumétrie de la base augmente :

• les backups complets sont bien mais on arrive vite à des problèmes de taille de la sauvegarde
• difficulté de mettre en place des backups incrémentaux -> pas le même principe que le backup avec pgdump
• pas de possibilité facile de sharding (le partitionnement des tables est faisable mais c'est purement manuel et ça fait un peu bricolage)
• même avec auto-vacuum, on a des problèmes de bloat :
  • le niveau de "bloat" des tables nécessite (dans notre cas) une commande CLUSTER de temps en temps
  • le niveau de "bloat" des index nécessite (dans notre cas) une commande REINDEX de temps en temps
• avec beaucoup de transactions par seconde (quelques milliers d'insertions par seconde dans mon cas) on tombe vite sur le problème du "transaction wraparound"
• Il n'y a pas de CLUSTERED INDEX comme Oracle ou SQL Server (si on sauve principalement des données de type CLEF/CLEF/VALEUR, l'index prend presque autant d'espace que la table)

Bref c'est bien mais il manque des trucs… mais grosso modo ça va dans la bonne direction.

Un petit doc intéressant (nb: même si je ne sais pas comment elle fait pour avoir 400000 tables !)
http://www.pgcon.org/2011/schedule/events/366.en.html

ET la logithèque associée ?

S'il n'y a pas de Ubuntu-Market associé, ou de compatibilité avec des applications existantes, pourquoi diable passer sur un Linux/Ubuntu/unity alors que Linux/Android fait déjà le travail ?

Et tester les brevets de microsoft, les constructeurs n'essaient même pas, vu qu'ils paient pour sortir leur mobile même sous Android.. donc j'imagine qu'à part quelques timides apparitions comme Dell.. ce sera donc à Canonical d'amorcer la machine.

c'est rassurant, pour le niveau technique !

après pour le niveau pratique, le truc c'est aussi d'avoir un système ''mongol-proof'' pour reprendre l'expression ci-dessus.. et suffisamment de documentation claire pour que l'utilisateur de base ne fasse pas n'importe quoi / comprenne ce qui se passe (Sachant que se payer une formation pour 10 personnes.. oulala non, c'est pas possible).

En tout cas je vais mater les docs évoquées plus haut, ça a l'air intéressant, tout ça.

j'ai fait l'expérience de migration de notre petit groupe de travail d'une abomination absolue (Microsoft SourceSafe -- SourceUnsafe pour les intimes) vers SVN en 2004.. et avec un petit travail de rééducation de mes collègues et patrons, tout s'est relativement bien passé.

Aujourd'hui je pousserai bien mes collègues à considérer un basculement progressif vers Mercurial, pour résoudre les "merge" de plus en plus fréquents et les branches à maintenir, et le fait qu'on bosse sur plusieurs sites....

quelqu'un a des retours d'expérience sur ce type de migration ? voire un bon bouquin pour les pro qui ne sont pas forcément spécialistes ?

enfin, bon le dernier kernel fraîchement récupéré.. il est plutôt "Down for maintenance" en ce moment...

---> [] je sors

Samsung, c'est joli, ça a l'air fonctionnel, c'est pas cher ... mais aussitôt la garantie expirée, crac ça marche plus, et le SAV est inexistant.

Perso je te conseillerai d'essayer les multifonction brother en laser couleur. J'ai pu essayer les version 4070 (recto verso wifi laser couleur) et la mini 3040, en ethernet laser couleur, et elles marchent très bien sous linux (reconnu direct sous ubuntu). Après faut voir pour la version multifonction.. mais cette gamme là est sympa.

bref mes 2 cents...

Ben le plus simple c'est de voir avec une boite qui s'occupe d'intégration et qui vend une adaptation de OpenErp à ton métier.

Pour la facilité, vu que c'est un truc à tout faire, ça à l'air super complet, voire un peu trop complexe pour la v5... je ne m'occupe que de l'hébergement d'un serveur qui fait tourner OpenErp, mais du peu que j'ai pu voir tourner, c'est pas encore assez limpide comme interface AMHA.

Après le coût, notre boite voisine vient de mettre en place OpenErp après un an (!) de moultes adaptations et personnalisations suivant le métier.. ça doit chiffrer.

Oui mais si mes souvenirs sont bons, les bébés victimes de ces expériences en sont morts.. alors c'est bien si les utilisateurs choisissent naturellement Ubuntu, mais autant éviter de les tuer dans l'opération :-p ...

Si on compare avec certaines pratiques commerciales aux 'states', pour le même prix que le papier, tu as un PDF encrypté avec un DRM que tu ne peux lire qu'avec acrobat reader et un logiciel propriétaire supplémentaire qui fait plugin de décryption, et bien entendu seulement sous windows et avec une connexion réseau et une demande de mot de passe à l'ouverture (!!) ... et les gens trouvent ça normal ?

Je sera plutôt content d'avoir un PDF (sans DRM!), c'est portable et universel.


[ Après s'ils fournissent les sources en TeX.. bien sûr c'est mieux. ]

je fais ça avec l'interface utilisateur dans Ubuntu, aucun problème, je ne vois l'intérêt de ce type de logiciel que s'il gère correctement les erreurs de coupure réseau, mais dans ce cas il pourrait tout aussi bien supporter les transferts FTP, par exemple.

Pour les copies en parallèle, je ne pense pas que tout sérialiser les uns à la suite des autres soit la solution la plus efficace possible, je fais confiance au noyau linux pour ordonnancer tout cela correctement.

Je suis pragmatique, je ne verrai l'intérêt en terme de performances de ce type de logiciel que s'il y a des bancs d'essais correctement réalisés et révélateurs d'amélioration substantielles.

ben tout de même, à la base c'est aussi pour le chanteur amateur, et un micro jack suffit..

Oui mais ce ne sont que des arguments, car si on gratte sous le blabla commercial, on s'aperçoit qu'il faut développer spécifiquement et compiler spécifiquement pour silverlight ou pour l'applic de bureau, mais que les deux sont fondamentalement incompatible : noyau, mots clefs, noms des classes et fonctions sont différentes (c'est incroyablement naze !).

AMHA la technologie n'est pas mure, et ne présente d'intérêt que pour le live streaming.

Quidquid latine dictum sit altum sonatur

Même combat, ce sont les mises à jour qui m'ont fait chavirer de Mandriva à Ubuntu, avec un dkms qui marche à peu près et un joli update-manager mieux que chez MS. De plus les repository miroirs de paquets sont diablement plus véloces chez Ubuntu que chez Mandriva.

J'avais des camarades d'école qui bossaient chez mandrake/mandriva, donc j'ai vraiment commencé à linuxer sérieusement avec cette distrib en 2000 et j'étais assez content, sauf pour les updates catastrophiques avec le root perdu quasiment à chaque fois (notamment car beaucoup de disques et contrôleurs), j'étais à fond partisan du urpmi et j'avais même acheté un powerpack dans le temps.

Maintenant je pleure depuis deux ans avec apt-get/dpkg et les super commandes intuitives qui vont avec ; mais au moins depuis Hardy Heron, ça marche, et c'est l'essentiel pour l'adoption de linux.

[mavie]
Récemment j'ai eu à installer un serveur linux pour le boulot, (pourquoi un linux dans une boite qui a une tradition krosoft ? c'est simple la compta, l'ERP, le CMS... on migre en fonction des logiciels phares pour la boite. Là bingo, c'est grâce à OpenERP que linux a été adopté chez nous) le choix de la distribution était facile : Ubuntu server x64... et ça marche, c'est facile à administrer, et c'est même assez bien documenté.

C'est juste moins drôle quand Dell ou Oracle refilent des vieux binaires moisis en 32bits, liés avec de vieilles libs... là faut bidouiller.
[/mavie]

Si le concept du livre libre est très intéressant, il restait néanmoins à éditer du contenu captivant pour l'acheteur potentiel. Un agenda, c'est plus plaisant à regarder que la bataille d'hadopi, et au moins ça plombe pas le moral en pensant à la politique actuelle.

C'est certain, à l'échelle des super-calculateurs d'aujourd'hui, pas de problème, mais si dans un avenir proche on a, non pas 250k cores, mais un ou plusieurs ordres de grandeurs au dessus, on peut à juste titre se poser la question : est-ce que des améliorations sont prévues, envisageables, ou nécessaires ?

Mais faire une révolution et casser le coté monolithique du noyau, ça me semble peu probable, vous en pensez quoi ?

Ben si visiblement, kmemcheck se sert d'un pagefault en écriture pour initialiser la page, sinon la lecture dans cette page "non initialisée" provoque un crash.

Pour les fichiers de configuration, il n y a pas plus rapide, je dis pas !

mais.. cela dit en passant, pour éditer du C, vi ou vim ... il lui manque un truc tout de même, il manque Intellisense(tm) !!

(ok, ok je sors)


--
F# Power !