Ils parlent de "free software", mais j'ai plus l'impression que c'est du logiciel gratuit que du libre.
Il y a la possibilité d'utiliser un outil d'aide pour définir une config qui correspond aux besoins.
Sinon côté logiciels libres, je ne pense pas qu'il y ait de sociétés qui fabriquent des modules qui permettent de gérer autant de points que demandé. Il faudra peut-être utiliser plusieurs modules qui communiqueront ensemble (mais je ne suis pas non plus un spécialiste du sujet).
Je pense que la question est trop vague pour pouvoir y répondre. Quelques centaines de points c'est beaucoup pour un système centralisé … il faudra peut-être des éléments distribués pour pouvoir répondre au besoin …
Quelles sont les caractéristiques électriques des ES ? Est-ce que vous voulez les piloter en 3.3V, 5V, 12v ? Quel courant ? Et pour les entrées/sorties analogiques, quelles seraient les plages de tensions et limites de courant ? Et au niveau des contraintes temporelles ?
installer des cartes pcie dans une tour ce serait un peu court
Pourquoi ?
Il existe peut-être des produits industriels propriétaires qui font ce que vous demandez, peut-être nous indiquer un exemple pourrait aider à vous orienter :) Personnellement je serais curieux de connaître un peu plus votre besion ainsi que les solutions qui pourraient y répondre.
De ce ue j'ai lu, il semble que HP pousse de plus en plus ses clients à se connecter chez eux pour utiliser leurs imprimantes. En pratique, je ne sais pas quelles sont les imprimantes concernées : les imprimantes HP que j'ai achetées jusqu'à maintenant ne m'ont jamais forcé à avoir un compte : fortement encouragé à l'installation - oui, mais jamais obligé. Jusque maintenant, HPLip sous Linux m'a toujours suffi. J'ai cru comprendre qu'à l'origine, cette problématique concernait surtout les imprimantes pas chères, vendues à perte, et pour lesquelles HP a plutôt intéret à forcer les gens à se fournir en cartouches chez eux, mais il semblerait (à confirmer) que cette pratique fasse tache d'huile et s'étende à 'ensemble des imprimantes de la marque.
Comme le disais quelqu'un un peu plus tôt dans la direction si la voiture ne cesse de te rappeler à l'ordre c'est peut être la conduite qui doit être remise en cause.
Si c'était le cas, le fait d'avoir désactiver la correction de trajectoire sans avoir désactivé l'alarme qui indique que l'on dévie aurait du faire sonner sans cesse ladite alarme, ce qui n'était pas le cas en pratique (sauf au bout de deux heures de route, ou elle a commencé à sonner - ce qui a été pour moi un signe qu'il fallait que je fasse une pause).
Tu considères le système en mode normal, et de ce point de vue, mis à part que le fait que je trouve que la correction de trajectoire est un peu trop rigide (au moins sur les modèles de véhicule que j'ai utilisés), je suis plutôt d'accord avec toi. Cependant un système n'est pas fiable à 100%. Dans le cas par exemple d'un blocage de l'accélérateur, il est évident que le freinage sera plus fort que l'accélération, mais de fait il rallongera les distances de freinage. Et ça peut faire la différence entre le fait de percuter un véhicule ou non, et sur la responsabilité du conducteur. La même question se pose pour la correction de trajectoire. Peut-être que c'est impossible (il y a peut-être des protections mécaniques), mais qu'est-ce qui me dit que le calculateur de la direction n'exercera pas une force de résistance bien plus importante que la force normalement appliquée pour la correction de trajectoire ? Rappel : je ne parle pas de fonctionnement normal, mais de bug du système d'assistance. Après tu pourras me dire que le conducteur n'a pas adapté sa conduite à la situation, ça peut être vrai, mais pas forcément. Pour le prouver il faut une enquête, et pour mener cette enquête, il faut des données, et ces données il faut les logger. Peut-être qu'en pratique, la boite noire indiquera systématiquement que le système a bien fonctionné, et que c'est effectivement le conducteur qui est en tort, mais permets-moi d'en douter.
st-ce qu'il est impossible que le calculateur bug, et qu'il applique une résistance bien plus importante que celle qu'il devrait appliquer ?
J'ai toujours aimé ce langage et je le suis toujours un peu. Et aussi surprenant que celà puisse paraître, apprendre Forth a changé ma manière de développer dans tous les langages que j'utilisais : ça m'a appris à avoir un certain nombre bonnes pratiques générales telles que faire des choses simples, ne pas avoir de code trop long pour un mot (une fonction dans les autres langages), ne pas passer trop de paramètres ni avoir trop de valeurs de retour à un mot ou fonction (s'il y a besoin de beaucoup de paramètres, c'est bien souvent qu'une structure serait mieux adaptée). Avec Forth (peut-être plus qu'avec d'autres langages), si on ne respecte pas ces pratiques, on se perd bien plus vite qu'avec d'autres langages.
C'est ce qui me fait hésiter à installer Debian, et c'est pour ça que je veux garder l'ancien système en parallèle : je crains d'avoir ce genre d'ennuis à l'installation.
Bricoler sa distribution m'a ramené quelques décennies en arrière et c'était cool (au début) car la documentation est bien fournie (wiki Debian, forums Debian francophones, Reddit, et.) mais à la fin c'est frustrant de perdre du temps pour un résultat en demi-teinte. Je crois que je vieillis car ça ne m'amuse plus que fut un temps.
Si j'ai un peu de temps pour corriger les problèmes, ourquoi pas, mais il ne faut pas que les correctifs soient trop compliqués non plus … En ayant l'ancien système qui tourne toujours en secours si besoin, ça ne devrait pas être trop bloquant. Et au pire je pourrai abandonner si je n'y arrive pas (ce qui n'est pas le cas si j'écrase tout).
Et niveau alternative c'est pas évident : Linux Mint ? Faut aimer Cinnamon et le vert…
A priori je m'en fous : j'installerai probablement un Enlightenment et un XFCE à la place (mais je suis pas fan du style graphique de mint). Mais si je vois que Debian c'est compliqué, je m'y intéresserai probablement. Sinon, je ne connais pas PopOS. Je vais regarder.
Il manque une distribution telle que l'a été Ubuntu à ses débuts : proche de Debian mais moins "root", qui met d'accent sur la facilité d'utilisation et la bonne détection du matériel.
C'est exactement ce que je pensais en rédigeant mon entrée dans le forum :)
En fait, au final, vu que j'envisage de passer sur du freebsd à terme, je me demande si la meilleure solution ne serait pas mint plutôt que debian, mais c'est difficile à estimer : soit je passe par mint et je passe beaucoup de temps à défaire ce qui est activé par défaut pour refaire comme j'en ai envie, soit je passe par une debian, j'ajoute les briques au fur et à mesure et je customise direct … Pas simple d'évaluer la meilleure solution en terme de temps passé.
Autrement tes freins seront toujours plus puissant que ton moteur.
Même si les frains sont plus puissant que le moteur, ce dernier en cas de conflit dans la commande aura tendnce à allonger la distance de freinage (et ça peut faire la différence en cas de risque de choc). Et si c'est du à une défaillance du système de contrôle …
En général c'est une vibration (pas agréable) et un durcissement de la direction qui peut surprendre, mais ce n'est pas des gros coup de volant non plus !
De plus (sur les voitures que j'ai eu avec ces systèmes) ce n'est pas actif à base vitesse (ville, village, … ), mais uniquement dès que l'on prend de la vitesse.
Ben justement : a grande vitesse ce durcissement peut faire la différence et t'empêcher d'éviter un obstacle (surtout s'il a une défaillance).
Je n'apprécie pas particulièrement de me faire remettre à ma place par une voiture. Il arrive que cela fasse des faux positifs (ligne jaune de travaux, écarts sur la gauche de la voie de gauche car une moto te double en interfile), mais la grande majorité des cas c'est parce que je fait des écarts (se rabattre ou doubler sans clignotants) ou de l’inattention et là je suis bine heureux que cela existe.
Je préfère largement les bips qui m'indiquent que ma trajectoire dévie que le truc qui force la direction : sur de longues distances ça fatigue je trouve. Mais ca dépend peut-être aussi des modèles de véhicules et des constructeurs …
pour avoir vu une propulsion BMW série 7 avec ABS (mais sans le mode conduite sur neige), chasser du cul en faisant du sur place, la technologie a clairement ses limites :D
J'avais à l'esprit ce genre de cas de figure qu'on m'avait rapporté (mais pas vu de mes propres yeux, pour ça que je ne l'ai pas mentionné). Un ancien collegue m'avait parlé de l'ABS de sa golf qui l'avait empêcher de monter une cote en conduite sur neige/verglas - l'ABS l'ayant poussé à descendre la cote en marche arriere.
Bon, le gars a fini par désactiver l'ABS permettant aux roues de mordre sur la neige et avancer au ralenti sur la route enneigée voire verglacée par endroits.
C'est quand même (en tout cas dans notre pays) des circonstances plutôt rares (j'imagine que les personnes vivant dans des endroits ou il neige plus sont mieux formées à ce genre de situation), et dans la majeure partie des cas, l'ABS est bien plus un allié qu'un ennemi. De plus il est désactivable pour gérer ce genre de situation. Enfin, même sans ABS, il y a beaucoup de gens qui ne sont pas capables de redémarrer leur véhicule lorsqu'il y a de la neige (j'ai aidé quelqu'un il y a quelques années à bouger sa voiture du milieu d'une intersection : cette personne était en panique, toute en larme et n'arrivait pas à gérer le fait que les roues patinaient un peu avant de mordre et d'avancer. N'étnt pas non plus un expert de la conduite sur neige, j'ai eu du mal à la déplacer également, mais comme je n'étais pas en panique j'a réussi à m'en sortir).
cela te permettra de rajouter au fur et à mesure ce dont tu as effectivement besoin plutôt que de calquer sur ce que tu as actuellement (cela permettra de faire le ménage, de ne pas réinstaller ce que tu n'utilises en fait pas — qui était là pour un test ponctuel par exemple).
C'est effectivement l'un des buts de cette réinstallation : faire le ménage et ne pas réinstaller tous les trucs que j'ai installés à des fins de test et yen a pas mal). Mais certains réglages que j'ai faits m'ont pris pas mal de temps et devoir tout refaire ne se fera pas en un claquement de doigts (d'ou l'intéret de garder les deux installations durant la transition).
parfois on oublie les Marque-pages, les login/mdp enregistrés (dans Chromium, dans gnome-web (epiphany), dans Firefox…),
J'avais pensé aux navigateurs, mais ton commentaire me fait penser aux IDE et leur conf (VSCodium par exemple, Geany, etc …) qu'il faudra que je puisse reprendre si je ne veux pas tout refaire …
De toute façon je pense migrer l'ensemble des documents d'un disque à l'autre ( à mon avis c'est la partie simple), mais dans tous les cas je ferai une archive de mon ancien home une fois que les documents seront déplacés, et avant de recycler le SSD actuel : normalement ça ne prendra pas beaucoup de place, et ça me permettra d'avoir sous la main les petits trucs que j'aurais pu oublier (classé en catégorie "inutile" par erreur).
C'est une question tout à fait légitime. Personnellement je suis mitigé : comme je le dis dans mes autres commentaires, je ne suis pas à priori contre tout les systèmes d'assistance. L'humain n'est pas infaillible, mais la technologie ne l'est pas non plus. On a des systèmes d'assistances plus efficaces que les humains (par exemple, a moins d'être un pilote expérimenté, il est quasi impossible pour un conducteur lambda de faire mieux que l'ABS). Mais je suis d'accord sur le fait que les technos ont leurs limites et qu'il est illusoire -voire dangereux - de les voir comme une solution magique pour régler tous les problèmes
Utilisateur de Slackware depuis la version 4 (sauf erreur, celle avec les disquettes ;-) ), j'ai dû me résoudre à basculer sur une nouvelle distribution il y a environ 3 ans : la version 15 de Slackware se faisant attendre et il devenait de plus en plus compliquer d'avoir les outils fonctionnels sans recompiler la moitié des librairies.
J'ai du me mettre à slackware à peu près à la même époque : c'était en 1995, mon premier Linux, installé depuis un CD vendu par Micro Application à l'époque (pas d'internet): on étudiait Unix (avec une IBM RS 6000 et des PC x86 sous SCO). Les profs nous avaient parlé de Linux et par hasard j'avais trouvé ce coffret à l'hyper du coin pour pas cher du tout : je me suis empressé de l'acheter, et j'ai pu ainsi refaire les exemples du cours et les TP chez moi (et me mettre à la compilation avec GCC).
Debian est d'avoir des mises à jour assez simple à faire et fréquente en SID (surtout pour les failles de sécurité même si beaucoup ne sont pas exploitables) et une large bibliothèque de logiciel disponible (malheureusement, faute de mainteneur, pas toujours à jour).
Bof … Sid pour moi c'est de la rolling release au même titre que Arch par exemple, ou Fedora. J'ai tenté ces deux dernières il y a un moment, mais je n'ai pas continué car tôt ou tard, je me retrouvais avec un bug gênant corrigé par une mise à jour mais l'application du bundle de mise à jours cassait autre chose (et toujours au moment ou j'avais besoin de mon ordinateur en urgence), qui retombait en marche deux ou trois jours après application d'une autre mise à jour (qui pouvait potentiellement casser autre chose). Je me demande du coup si Unstable ne serait pas mieux indiqué pour moi.
Je ne suis pas sûr que l'utilisation d'un /home partager entre Debian et Ubuntu ne pose pas de problème, les 2 distributions divergent de plus en plus, Ubuntu étant souvent plus prompt à utiliser les dernières version.
Je voyais plutôt ça dans l'autre sens : je suis en Ubuntu LTS (22.04), j'aurais cru qu'une version SID ou unstable de Debian serait plus à jour qu'une Ubuntu LTS. Celà dit d'un sens comme dans l'autre, je suis d'accord sur le fond : avoir un /home partagé peut effectivement poser problème.
Lors de ma migration, j'ai préféré faire une bascule complète et ne pas avoir à gérer les problèmes d'interactions (entre autres la configuration du bureau).
C'est aussi ce vers quoi je pense aller: un /home propre à chaque distribution, déplacer tout ce que j'ai à la racidne de mon homedir dans des sous-dossiers (Documents, Images, etc …) et mettre en place de part et d'autre un point de montage sur le /home/ de l'autre distribution le temps de copier les données (je me demande si je ne devrais pas du coup mettre en place un outil de synchro entre les dossiers, mais lequel ?
En fait, vu les tas d'aides actives à la conduite que les constructeurs placent partout dans les véhicules aujourd'hui, la boite noire (ou plutôt système de centralisation de logs) est devenu nécessaire, et ce pour une raison simple : la techno n'est pas infaillible. Ces systèmes inventés et mis en place par d'autres systèmes faillibles (les humains) peuvent se tromper. Par exemple, Certains se souviennent peut-être il y a quelques années de ces véhicules à boite automatiques qui ne se sont pas arrêtés à des péages. Comment déterminer si c'est le conducteur ou le système qui est responsable sans avoir au moins les traces des ordres fournis par le conducteur (accélération, freinage, direction, etc …, et les ordres transmis aux divers équipements (vitesse, freins, abs, direction, etc …) par le système d'assistance active ? Aujourd'hui le code de la route stipule que tout conducteur doit être maître de son véhicule, mais le peut-il lorsqu'un système d'assistance en vient à potentiellement contredire et rectifier les instructions données par le conducteur ? Serait-il normal de faire payer une contravention à un conducteur qui dépasserait une limitation de vitesse si le système d'assistance n'a pas pris en compte sa demande de ralentir ? Serait-il normal de condamner un conducteur parce qu'il renverse une personne sur la route, alors que le système de contrôle de position au milieu de la voie a résisté et empêché de faire le léger écart qu'il a voulu faire pour éviter la personne ? ( Aurait-il du actionner le clignotant avant de s'écarter ? )
Alors certes, le système de centralisation log n'est pas la panacée (car il est aussi faillible), mais limite dans une certaine mesure les problèmes évoqués ci-dessus mais à plusieurs conditions (non exhaustives) :
- le système de log ne doit pas être un système développé par le constructeur de véhicule mais un système développé par une entité indépendante, pour éviter les fraudes ( éviter le trafic de logs par exemple)
- les logs des commandes utilisateurs doivent être envoyées dans la boite noire, avant d'être traitées par le système d'assistance active.
- les logs de commmande du système d'assistance active vers les actionneurs qu'il contrôle doivent être envoyées également dans la boite noire.
- une fois les logs écrites, elles ne doivent pas être modifiables (mais supprimées lorsqu'elles n'ont plus de raison d'être)
- le contructeur, le conducteur, les meccano ou n'importe qui ne doit pas être en mesure d'accéder, ni trafiquer ces logs.
- en cas de besoin, les logs (la boite noire) doit être récupérée par les forces de l'ordre, et seule une copie de ces logs doivent être envoyées aux constructeurs pour analyse.
Il y a d'autres conditions auxquelles j'ai pensées avant d'écrire mon commentaire. Celà dit, je pene que remplir les conditions que j'ai mentionnées ici risque d'être bien compliqué.
Bien que ta remarque ne soit pas fausse, je ne la trouve pas pertinente par rapport au commentaire auquel tu réponds. La question posée dans le commentaire est de savoir si le fait de freiner brutalement doit être systématiquement considéré comme conduite dangereuse : ça peut l'être, mais pas systématiquement : il y a des cas ou les freinages brusques se justifient ( et on a inventé l'ABS pour justement rendre plus efficace le freinage dans ce genre de cas).
Il y a peut-être un moment ou il faut se demander si les techno qu'on nous balance un peu partout sont pertinentes et prêtes pour être généralisées, et c'est surtout ça le but de mon commentaire. Et de mon point de vue, le système en soi est une bonne idée, mais il n'est juste pas complètement prêt pour être rendu obligatoire sur tous les véhicules.
Je ne parle pas de la résistance lorsque je passe d'une voie à une autre sans mettre de clignotant, mais de la résistance que le truc te met lorsque tu dévies un peu à droite ou à gauche tout en restant dans ta voie. en gros quand tu ne restes pas exactement là ou le système a décidé que tu devais être.
Note que sur le principe je ne suis pas forcément contre ce genre de système, mais de mon point de vue, le généraliser aujourd'hui me parait prématuré (car pas encore completement au point).
Ca ne me choque pas qu'on installe une boite noire sur le véhicule, tant que les données ne sont pas accessibles à distance ni utilisées par d'autres entités que la police ou la justice en cas d'accident. Moi ce qui me gène e plus c'est le système de limitation de vitesse qui peut être dangereux dans certains cas, notamment quand on se met à doubler quelqu'un qui n'avance pas mais qui se met à accélerer quand on le double ( ça m'arrive assez souvent quand je conduis): il faudrait en contrepartie un système qui empêche la personne qui se fait doubler d'accélérer lorsque quelqu'un le double.
Moi il y a un autre système qui me gène sur les voitures, c'est le système qui contrôle la direction et qui tente de repositionner ton véhicule au centre de la voie : j'avais été victime de ce système la dernière fois que j'ai loué un véhicule : ce truc à force m'a causé une fatigue non négligeable dans les bras (je trouvais que la direction étit bien dure parfois, et j'ai mis du temps à comprendre pourquoi), et la procédure de désactivation de ce truc n'est pas forcément simple à trouver.
Je l'avais oubliée celle-la … Je voulais tester son utilisation pour la compilation de gros projets … mais je n'ai pas eu le temps de le faire et ensuite je suis passé à autre chose.
Effectivement, je mélange un peu tout … La page wikipedia sur uboot indique que celui-ci peut remplacer BIOS et UEFI, j'avais aussi par ailleurs lu des articles ou justement uboot joue le rôle de l'UEFI dans certaines cartes ARM (ça doit être ici d'ailleurs ). Enfin, après avoir lu ce document (en diagonale je l'avoue), j'ai confondu uboot et firmware pour le Raspberry pi. Or il semble qu'en fait le firmware de démarrage du RPi n'est pas uboot, mais que rien n'empêche de l'installer sur un raspberry pi (ce que je ne savais pas) ou il prendra le rôle de Grub (voir par exemple https://elinux.org/RPi_U-Boot).
u-boot fait partie du firmware du raspberry pi : je le vois au même niveau que le BIOS ou l'UEFI. Si on veut parler de boot loader pour RPi, je verrais un truc du style Noobs/Pinn, ou Berryboot
Je sais que tu demandes des ressources papier mais j'ai quand même un petit lien vers un doc pdf qui te donnera un apperçu (que tu pourras imprimer si vraiment la version élactronique te rebute).
Tu trouveras les références des normes AFNOR (il me semble que tu peux commander les documents correspondants sur le site de l'AFNOR). J'ai aussi quelques liens dans des docs que j'ai téléchargé il y a quelques temps sur ma liseuse : je verrai si j'y trouve des références vers des recommandations de livres/doc que tu pourrais te procurer.
Le bootloader (tel que grub) n'avait de raison d'être que sur des machines x86, en raison de la limitation du sercteur de boot à 512 octets, et surtout pour pouvoir installer plusieurs OS sur le même disque. ( je me rappelle encore du fameux LILO sur les premier Linux que j'avais intallé ). Si le BIOS avait permis d'aller chercher un programme de plus de 512 octets sur le disque dur des machines x86, nous n'aurions pas eu besoin de gestionnaire de démarrage ( il me semble que les machines sun, IBM/AIX - ou apple PowerPC - qui utilisent l'Open Firmware, n'ont pas besoin de cette étape intermédiaire : ils vont lire directement le noyau sur la partition si ma mémoire est bonne).
Aujourd'hui avec l'UEFI, même pour du multi-boot on peut se passer de Grub (ou tout autre logiciel équivalent). Et il me semble qu'il n'y a pas de grub sur les distributions Linux à base de CPU ARM (ex : Raspberry pi).
Tiens … d'ailleurs cette histoire de bootloader, et de secteur de démarrage de 512 octets me fait penser à une série de journaux que je dois écrire depuis maintenant bien longtemps ( idée que j'ai eue durant le premier confinement COVID, que je n'ai pas pu concrétiser à l'époque par manque de motivation, mais celle-ci m'est revenue ces derniers temps).
LA conception de produit se base avant tout sur l'analyse fonctionnelle et d'analyse de la valeur (un produit/servce n'existe que pour remplir une fonction qui répond à un besoin ).
Il existe un tas de méthodes pour ce genre d'analyse ( Fast, Apte, etc …). Je ne sais pas quelles sont les méthodes les plus utilisées aujourd'hui (j'avais appris FAST et Apte durant mes études il y a maintenant fort longtemps, avec la fameuse bête à cornes et le diagramme pieuvre - que j'utilise encore parfois, sans forcément le montrer en tant que tel en milieu professionnel lorsqu'il faut réorienter les sujets techniques autour des besoins réels ).
Je n'ai plus fait ce genre de choses depuis longtemps, donc je n'aurai pas de lecture récente à te conseiller, mais si tu dois chercher c'est dans cette direction.
Distributions such as CentOS (Community Enterprise OS) are designed to be deployed within large organizations using enterprise hardware. The needs of the enterprise are very different from the needs of the small business, hobbyist or home user. In order to ensure the availability of their services, enterprise users have higher requirements regarding the stability of their hard- and software. Therefore, enterprise Linux distributions tend to include older releases of the kernel and other software, which are known to work reliably. Often the distributions port important updates like security fixes back to these stable versions. In return, enterprise Linux distributions might lack support for the most recent consumer hardware and provide older versions of software packages. However, like consumer Linux distributions, enterprises tend to also choose mature hardware components and build their services on stable software versions.
Consumer Grade Linux
Distributions such as Ubuntu are more targeted for small business or home and hobbyist users. As such, they are also likely to be using the latest hardware found on consumer grade systems. These systems will need the latest drivers to make the most of the new hardware but the maturity of both the hardware and the drivers is unlikely to meet the needs of larger enterprises. For the consumer market, however, the latest kernel is exactly what is needed with the most modern drivers even if they are little under tested. The newer Linux kernels will have the latest drivers to support the very latest hardware that are likely to be in use. Especially with the development we see with Linux in the gaming market it is tremendously important that the latest drivers are available to these users.
Je sens du parti pris dans la sélection de distribution : Ubuntu peut être utilisé (et est utilisé) au même titre que Redhat/centos (et maintenant les alternatives à centos). Il n'y a aucune raison de restreindre ubuntu à des petites structures. Du coup …. je recommence à douter sur la pertinence de ce cours …
[^] # Re: Pouvez-vous être plus précis sur le besoin ? ?
Posté par totof2000 . En réponse au message automate et opensource. Évalué à 4.
En open source : https://www.industrialshields.com/202404-industrial-shields-home
Il est peut-être possible de combiner ce genre de modules pour obtenir de quoi couvrir votre besoin.
[^] # Re: Pouvez-vous être plus précis sur le besoin ? ?
Posté par totof2000 . En réponse au message automate et opensource. Évalué à 2.
En regardant un peu j'ai trouvé ce site : https://www.automationdirect.com/systembuilder
Ils parlent de "free software", mais j'ai plus l'impression que c'est du logiciel gratuit que du libre.
Il y a la possibilité d'utiliser un outil d'aide pour définir une config qui correspond aux besoins.
Sinon côté logiciels libres, je ne pense pas qu'il y ait de sociétés qui fabriquent des modules qui permettent de gérer autant de points que demandé. Il faudra peut-être utiliser plusieurs modules qui communiqueront ensemble (mais je ne suis pas non plus un spécialiste du sujet).
# Pouvez-vous être plus précis sur le besoin ? ?
Posté par totof2000 . En réponse au message automate et opensource. Évalué à 3.
Je pense que la question est trop vague pour pouvoir y répondre. Quelques centaines de points c'est beaucoup pour un système centralisé … il faudra peut-être des éléments distribués pour pouvoir répondre au besoin …
Quelles sont les caractéristiques électriques des ES ? Est-ce que vous voulez les piloter en 3.3V, 5V, 12v ? Quel courant ? Et pour les entrées/sorties analogiques, quelles seraient les plages de tensions et limites de courant ? Et au niveau des contraintes temporelles ?
Pourquoi ?
Il existe peut-être des produits industriels propriétaires qui font ce que vous demandez, peut-être nous indiquer un exemple pourrait aider à vous orienter :) Personnellement je serais curieux de connaître un peu plus votre besion ainsi que les solutions qui pourraient y répondre.
[^] # Re: Fonctionnalité recherchée ?
Posté par totof2000 . En réponse au message HP Smart me met sur les nerfs !. Évalué à 5.
De ce ue j'ai lu, il semble que HP pousse de plus en plus ses clients à se connecter chez eux pour utiliser leurs imprimantes. En pratique, je ne sais pas quelles sont les imprimantes concernées : les imprimantes HP que j'ai achetées jusqu'à maintenant ne m'ont jamais forcé à avoir un compte : fortement encouragé à l'installation - oui, mais jamais obligé. Jusque maintenant, HPLip sous Linux m'a toujours suffi. J'ai cru comprendre qu'à l'origine, cette problématique concernait surtout les imprimantes pas chères, vendues à perte, et pour lesquelles HP a plutôt intéret à forcer les gens à se fournir en cartouches chez eux, mais il semblerait (à confirmer) que cette pratique fasse tache d'huile et s'étende à 'ensemble des imprimantes de la marque.
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 2.
Non, juste méfiant …
Si c'était le cas, le fait d'avoir désactiver la correction de trajectoire sans avoir désactivé l'alarme qui indique que l'on dévie aurait du faire sonner sans cesse ladite alarme, ce qui n'était pas le cas en pratique (sauf au bout de deux heures de route, ou elle a commencé à sonner - ce qui a été pour moi un signe qu'il fallait que je fasse une pause).
Tu considères le système en mode normal, et de ce point de vue, mis à part que le fait que je trouve que la correction de trajectoire est un peu trop rigide (au moins sur les modèles de véhicule que j'ai utilisés), je suis plutôt d'accord avec toi. Cependant un système n'est pas fiable à 100%. Dans le cas par exemple d'un blocage de l'accélérateur, il est évident que le freinage sera plus fort que l'accélération, mais de fait il rallongera les distances de freinage. Et ça peut faire la différence entre le fait de percuter un véhicule ou non, et sur la responsabilité du conducteur. La même question se pose pour la correction de trajectoire. Peut-être que c'est impossible (il y a peut-être des protections mécaniques), mais qu'est-ce qui me dit que le calculateur de la direction n'exercera pas une force de résistance bien plus importante que la force normalement appliquée pour la correction de trajectoire ? Rappel : je ne parle pas de fonctionnement normal, mais de bug du système d'assistance. Après tu pourras me dire que le conducteur n'a pas adapté sa conduite à la situation, ça peut être vrai, mais pas forcément. Pour le prouver il faut une enquête, et pour mener cette enquête, il faut des données, et ces données il faut les logger. Peut-être qu'en pratique, la boite noire indiquera systématiquement que le système a bien fonctionné, et que c'est effectivement le conducteur qui est en tort, mais permets-moi d'en douter.
st-ce qu'il est impossible que le calculateur bug, et qu'il applique une résistance bien plus importante que celle qu'il devrait appliquer ?
# Merci pour la news
Posté par totof2000 . En réponse au journal Nouveautés issues du petit monde du FORTH . Évalué à 7.
J'ai toujours aimé ce langage et je le suis toujours un peu. Et aussi surprenant que celà puisse paraître, apprendre Forth a changé ma manière de développer dans tous les langages que j'utilisais : ça m'a appris à avoir un certain nombre bonnes pratiques générales telles que faire des choses simples, ne pas avoir de code trop long pour un mot (une fonction dans les autres langages), ne pas passer trop de paramètres ni avoir trop de valeurs de retour à un mot ou fonction (s'il y a besoin de beaucoup de paramètres, c'est bien souvent qu'une structure serait mieux adaptée). Avec Forth (peut-être plus qu'avec d'autres langages), si on ne respecte pas ces pratiques, on se perd bien plus vite qu'avec d'autres langages.
[^] # Re: Ubuntu-Debian : retour mitigé
Posté par totof2000 . En réponse au message Remplacer Ubuntu par Debian. Évalué à 2.
C'est ce qui me fait hésiter à installer Debian, et c'est pour ça que je veux garder l'ancien système en parallèle : je crains d'avoir ce genre d'ennuis à l'installation.
Si j'ai un peu de temps pour corriger les problèmes, ourquoi pas, mais il ne faut pas que les correctifs soient trop compliqués non plus … En ayant l'ancien système qui tourne toujours en secours si besoin, ça ne devrait pas être trop bloquant. Et au pire je pourrai abandonner si je n'y arrive pas (ce qui n'est pas le cas si j'écrase tout).
A priori je m'en fous : j'installerai probablement un Enlightenment et un XFCE à la place (mais je suis pas fan du style graphique de mint). Mais si je vois que Debian c'est compliqué, je m'y intéresserai probablement. Sinon, je ne connais pas PopOS. Je vais regarder.
C'est exactement ce que je pensais en rédigeant mon entrée dans le forum :)
En fait, au final, vu que j'envisage de passer sur du freebsd à terme, je me demande si la meilleure solution ne serait pas mint plutôt que debian, mais c'est difficile à estimer : soit je passe par mint et je passe beaucoup de temps à défaire ce qui est activé par défaut pour refaire comme j'en ai envie, soit je passe par une debian, j'ajoute les briques au fur et à mesure et je customise direct … Pas simple d'évaluer la meilleure solution en terme de temps passé.
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 2.
Ben justement : a grande vitesse ce durcissement peut faire la différence et t'empêcher d'éviter un obstacle (surtout s'il a une défaillance).
Je préfère largement les bips qui m'indiquent que ma trajectoire dévie que le truc qui force la direction : sur de longues distances ça fatigue je trouve. Mais ca dépend peut-être aussi des modèles de véhicules et des constructeurs …
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 2.
J'avais à l'esprit ce genre de cas de figure qu'on m'avait rapporté (mais pas vu de mes propres yeux, pour ça que je ne l'ai pas mentionné). Un ancien collegue m'avait parlé de l'ABS de sa golf qui l'avait empêcher de monter une cote en conduite sur neige/verglas - l'ABS l'ayant poussé à descendre la cote en marche arriere.
C'est quand même (en tout cas dans notre pays) des circonstances plutôt rares (j'imagine que les personnes vivant dans des endroits ou il neige plus sont mieux formées à ce genre de situation), et dans la majeure partie des cas, l'ABS est bien plus un allié qu'un ennemi. De plus il est désactivable pour gérer ce genre de situation. Enfin, même sans ABS, il y a beaucoup de gens qui ne sont pas capables de redémarrer leur véhicule lorsqu'il y a de la neige (j'ai aidé quelqu'un il y a quelques années à bouger sa voiture du milieu d'une intersection : cette personne était en panique, toute en larme et n'arrivait pas à gérer le fait que les roues patinaient un peu avant de mordre et d'avancer. N'étnt pas non plus un expert de la conduite sur neige, j'ai eu du mal à la déplacer également, mais comme je n'étais pas en panique j'a réussi à m'en sortir).
[^] # Re: Juste fais-le Bookworm ça juste fonctionne
Posté par totof2000 . En réponse au message Remplacer Ubuntu par Debian. Évalué à 4.
C'est effectivement l'un des buts de cette réinstallation : faire le ménage et ne pas réinstaller tous les trucs que j'ai installés à des fins de test et yen a pas mal). Mais certains réglages que j'ai faits m'ont pris pas mal de temps et devoir tout refaire ne se fera pas en un claquement de doigts (d'ou l'intéret de garder les deux installations durant la transition).
J'avais pensé aux navigateurs, mais ton commentaire me fait penser aux IDE et leur conf (VSCodium par exemple, Geany, etc …) qu'il faudra que je puisse reprendre si je ne veux pas tout refaire …
De toute façon je pense migrer l'ensemble des documents d'un disque à l'autre ( à mon avis c'est la partie simple), mais dans tous les cas je ferai une archive de mon ancien home une fois que les documents seront déplacés, et avant de recycler le SSD actuel : normalement ça ne prendra pas beaucoup de place, et ça me permettra d'avoir sous la main les petits trucs que j'aurais pu oublier (classé en catégorie "inutile" par erreur).
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 3.
C'est ta faute : fallait mettre ton clignotant.
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 2.
C'est une question tout à fait légitime. Personnellement je suis mitigé : comme je le dis dans mes autres commentaires, je ne suis pas à priori contre tout les systèmes d'assistance. L'humain n'est pas infaillible, mais la technologie ne l'est pas non plus. On a des systèmes d'assistances plus efficaces que les humains (par exemple, a moins d'être un pilote expérimenté, il est quasi impossible pour un conducteur lambda de faire mieux que l'ABS). Mais je suis d'accord sur le fait que les technos ont leurs limites et qu'il est illusoire -voire dangereux - de les voir comme une solution magique pour régler tous les problèmes
[^] # Re: Debian
Posté par totof2000 . En réponse au message Remplacer Ubuntu par Debian. Évalué à 3.
J'ai du me mettre à slackware à peu près à la même époque : c'était en 1995, mon premier Linux, installé depuis un CD vendu par Micro Application à l'époque (pas d'internet): on étudiait Unix (avec une IBM RS 6000 et des PC x86 sous SCO). Les profs nous avaient parlé de Linux et par hasard j'avais trouvé ce coffret à l'hyper du coin pour pas cher du tout : je me suis empressé de l'acheter, et j'ai pu ainsi refaire les exemples du cours et les TP chez moi (et me mettre à la compilation avec GCC).
Bof … Sid pour moi c'est de la rolling release au même titre que Arch par exemple, ou Fedora. J'ai tenté ces deux dernières il y a un moment, mais je n'ai pas continué car tôt ou tard, je me retrouvais avec un bug gênant corrigé par une mise à jour mais l'application du bundle de mise à jours cassait autre chose (et toujours au moment ou j'avais besoin de mon ordinateur en urgence), qui retombait en marche deux ou trois jours après application d'une autre mise à jour (qui pouvait potentiellement casser autre chose). Je me demande du coup si Unstable ne serait pas mieux indiqué pour moi.
Je voyais plutôt ça dans l'autre sens : je suis en Ubuntu LTS (22.04), j'aurais cru qu'une version SID ou unstable de Debian serait plus à jour qu'une Ubuntu LTS. Celà dit d'un sens comme dans l'autre, je suis d'accord sur le fond : avoir un /home partagé peut effectivement poser problème.
C'est aussi ce vers quoi je pense aller: un /home propre à chaque distribution, déplacer tout ce que j'ai à la racidne de mon homedir dans des sous-dossiers (Documents, Images, etc …) et mettre en place de part et d'autre un point de montage sur le /home/ de l'autre distribution le temps de copier les données (je me demande si je ne devrais pas du coup mettre en place un outil de synchro entre les dossiers, mais lequel ?
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 6. Dernière modification le 14 juillet 2024 à 13:51.
En fait, vu les tas d'aides actives à la conduite que les constructeurs placent partout dans les véhicules aujourd'hui, la boite noire (ou plutôt système de centralisation de logs) est devenu nécessaire, et ce pour une raison simple : la techno n'est pas infaillible. Ces systèmes inventés et mis en place par d'autres systèmes faillibles (les humains) peuvent se tromper. Par exemple, Certains se souviennent peut-être il y a quelques années de ces véhicules à boite automatiques qui ne se sont pas arrêtés à des péages. Comment déterminer si c'est le conducteur ou le système qui est responsable sans avoir au moins les traces des ordres fournis par le conducteur (accélération, freinage, direction, etc …, et les ordres transmis aux divers équipements (vitesse, freins, abs, direction, etc …) par le système d'assistance active ? Aujourd'hui le code de la route stipule que tout conducteur doit être maître de son véhicule, mais le peut-il lorsqu'un système d'assistance en vient à potentiellement contredire et rectifier les instructions données par le conducteur ? Serait-il normal de faire payer une contravention à un conducteur qui dépasserait une limitation de vitesse si le système d'assistance n'a pas pris en compte sa demande de ralentir ? Serait-il normal de condamner un conducteur parce qu'il renverse une personne sur la route, alors que le système de contrôle de position au milieu de la voie a résisté et empêché de faire le léger écart qu'il a voulu faire pour éviter la personne ? ( Aurait-il du actionner le clignotant avant de s'écarter ? )
Alors certes, le système de centralisation log n'est pas la panacée (car il est aussi faillible), mais limite dans une certaine mesure les problèmes évoqués ci-dessus mais à plusieurs conditions (non exhaustives) :
- le système de log ne doit pas être un système développé par le constructeur de véhicule mais un système développé par une entité indépendante, pour éviter les fraudes ( éviter le trafic de logs par exemple)
- les logs des commandes utilisateurs doivent être envoyées dans la boite noire, avant d'être traitées par le système d'assistance active.
- les logs de commmande du système d'assistance active vers les actionneurs qu'il contrôle doivent être envoyées également dans la boite noire.
- une fois les logs écrites, elles ne doivent pas être modifiables (mais supprimées lorsqu'elles n'ont plus de raison d'être)
- le contructeur, le conducteur, les meccano ou n'importe qui ne doit pas être en mesure d'accéder, ni trafiquer ces logs.
- en cas de besoin, les logs (la boite noire) doit être récupérée par les forces de l'ordre, et seule une copie de ces logs doivent être envoyées aux constructeurs pour analyse.
Il y a d'autres conditions auxquelles j'ai pensées avant d'écrire mon commentaire. Celà dit, je pene que remplir les conditions que j'ai mentionnées ici risque d'être bien compliqué.
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 5.
Bien que ta remarque ne soit pas fausse, je ne la trouve pas pertinente par rapport au commentaire auquel tu réponds. La question posée dans le commentaire est de savoir si le fait de freiner brutalement doit être systématiquement considéré comme conduite dangereuse : ça peut l'être, mais pas systématiquement : il y a des cas ou les freinages brusques se justifient ( et on a inventé l'ABS pour justement rendre plus efficace le freinage dans ce genre de cas).
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 7.
Il y a peut-être un moment ou il faut se demander si les techno qu'on nous balance un peu partout sont pertinentes et prêtes pour être généralisées, et c'est surtout ça le but de mon commentaire. Et de mon point de vue, le système en soi est une bonne idée, mais il n'est juste pas complètement prêt pour être rendu obligatoire sur tous les véhicules.
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 7.
Ca commence à me gaver ces donneurs de leçons …
Je ne parle pas de la résistance lorsque je passe d'une voie à une autre sans mettre de clignotant, mais de la résistance que le truc te met lorsque tu dévies un peu à droite ou à gauche tout en restant dans ta voie. en gros quand tu ne restes pas exactement là ou le système a décidé que tu devais être.
Note que sur le principe je ne suis pas forcément contre ce genre de système, mais de mon point de vue, le généraliser aujourd'hui me parait prématuré (car pas encore completement au point).
[^] # Re: Boîte noire == mouchard --> assurance --> augmentation
Posté par totof2000 . En réponse au lien Une boîte noire et des dispositifs de sécurité obligatoires sur les véhicules neufs vendus dans l'UE. Évalué à 5. Dernière modification le 13 juillet 2024 à 21:14.
Ca ne me choque pas qu'on installe une boite noire sur le véhicule, tant que les données ne sont pas accessibles à distance ni utilisées par d'autres entités que la police ou la justice en cas d'accident. Moi ce qui me gène e plus c'est le système de limitation de vitesse qui peut être dangereux dans certains cas, notamment quand on se met à doubler quelqu'un qui n'avance pas mais qui se met à accélerer quand on le double ( ça m'arrive assez souvent quand je conduis): il faudrait en contrepartie un système qui empêche la personne qui se fait doubler d'accélérer lorsque quelqu'un le double.
Moi il y a un autre système qui me gène sur les voitures, c'est le système qui contrôle la direction et qui tente de repositionner ton véhicule au centre de la voie : j'avais été victime de ce système la dernière fois que j'ai loué un véhicule : ce truc à force m'a causé une fatigue non négligeable dans les bras (je trouvais que la direction étit bien dure parfois, et j'ai mis du temps à comprendre pourquoi), et la procédure de désactivation de ce truc n'est pas forcément simple à trouver.
[^] # Re: Essayer c'est simple...
Posté par totof2000 . En réponse au message MAO: Utilité d'un ramdisk / disque virtuel. Évalué à 2.
Je l'avais oubliée celle-la … Je voulais tester son utilisation pour la compilation de gros projets … mais je n'ai pas eu le temps de le faire et ensuite je suis passé à autre chose.
[^] # Re: Ça ne nous rajeunit pas
Posté par totof2000 . En réponse au lien Démarrer Linux sans boot loader . Évalué à 2.
Effectivement, je mélange un peu tout … La page wikipedia sur uboot indique que celui-ci peut remplacer BIOS et UEFI, j'avais aussi par ailleurs lu des articles ou justement uboot joue le rôle de l'UEFI dans certaines cartes ARM (ça doit être ici d'ailleurs ). Enfin, après avoir lu ce document (en diagonale je l'avoue), j'ai confondu uboot et firmware pour le Raspberry pi. Or il semble qu'en fait le firmware de démarrage du RPi n'est pas uboot, mais que rien n'empêche de l'installer sur un raspberry pi (ce que je ne savais pas) ou il prendra le rôle de Grub (voir par exemple https://elinux.org/RPi_U-Boot).
[^] # Re: Ça ne nous rajeunit pas
Posté par totof2000 . En réponse au lien Démarrer Linux sans boot loader . Évalué à 2.
u-boot fait partie du firmware du raspberry pi : je le vois au même niveau que le BIOS ou l'UEFI. Si on veut parler de boot loader pour RPi, je verrais un truc du style Noobs/Pinn, ou Berryboot
[^] # Re: analyse fonctionnelle et analyse des besoins.
Posté par totof2000 . En réponse au message Lectures sur la conception de produits. Évalué à 3.
Je sais que tu demandes des ressources papier mais j'ai quand même un petit lien vers un doc pdf qui te donnera un apperçu (que tu pourras imprimer si vraiment la version élactronique te rebute).
Tu trouveras les références des normes AFNOR (il me semble que tu peux commander les documents correspondants sur le site de l'AFNOR). J'ai aussi quelques liens dans des docs que j'ai téléchargé il y a quelques temps sur ma liseuse : je verrai si j'y trouve des références vers des recommandations de livres/doc que tu pourrais te procurer.
[^] # Re: Ça ne nous rajeunit pas
Posté par totof2000 . En réponse au lien Démarrer Linux sans boot loader . Évalué à 5. Dernière modification le 09 juillet 2024 à 16:23.
Le bootloader (tel que grub) n'avait de raison d'être que sur des machines x86, en raison de la limitation du sercteur de boot à 512 octets, et surtout pour pouvoir installer plusieurs OS sur le même disque. ( je me rappelle encore du fameux LILO sur les premier Linux que j'avais intallé ). Si le BIOS avait permis d'aller chercher un programme de plus de 512 octets sur le disque dur des machines x86, nous n'aurions pas eu besoin de gestionnaire de démarrage ( il me semble que les machines sun, IBM/AIX - ou apple PowerPC - qui utilisent l'Open Firmware, n'ont pas besoin de cette étape intermédiaire : ils vont lire directement le noyau sur la partition si ma mémoire est bonne).
Aujourd'hui avec l'UEFI, même pour du multi-boot on peut se passer de Grub (ou tout autre logiciel équivalent). Et il me semble qu'il n'y a pas de grub sur les distributions Linux à base de CPU ARM (ex : Raspberry pi).
Tiens … d'ailleurs cette histoire de bootloader, et de secteur de démarrage de 512 octets me fait penser à une série de journaux que je dois écrire depuis maintenant bien longtemps ( idée que j'ai eue durant le premier confinement COVID, que je n'ai pas pu concrétiser à l'époque par manque de motivation, mais celle-ci m'est revenue ces derniers temps).
# analyse fonctionnelle et analyse des besoins.
Posté par totof2000 . En réponse au message Lectures sur la conception de produits. Évalué à 3. Dernière modification le 09 juillet 2024 à 16:10.
LA conception de produit se base avant tout sur l'analyse fonctionnelle et d'analyse de la valeur (un produit/servce n'existe que pour remplir une fonction qui répond à un besoin ).
Il existe un tas de méthodes pour ce genre d'analyse ( Fast, Apte, etc …). Je ne sais pas quelles sont les méthodes les plus utilisées aujourd'hui (j'avais appris FAST et Apte durant mes études il y a maintenant fort longtemps, avec la fameuse bête à cornes et le diagramme pieuvre - que j'utilise encore parfois, sans forcément le montrer en tant que tel en milieu professionnel lorsqu'il faut réorienter les sujets techniques autour des besoins réels ).
Je n'ai plus fait ce genre de choses depuis longtemps, donc je n'aurai pas de lecture récente à te conseiller, mais si tu dois chercher c'est dans cette direction.
[^] # Re: les formations LPIC ....
Posté par totof2000 . En réponse au message Débutant. Évalué à 2. Dernière modification le 09 juillet 2024 à 15:31.
Bon .. je viens de regarder et j'ai vu quand même un truc qui me gène :
Je cite :
Je sens du parti pris dans la sélection de distribution : Ubuntu peut être utilisé (et est utilisé) au même titre que Redhat/centos (et maintenant les alternatives à centos). Il n'y a aucune raison de restreindre ubuntu à des petites structures. Du coup …. je recommence à douter sur la pertinence de ce cours …