pif17 a écrit 24 commentaires

Sur spyPhone robotisé, personalDNSFfilter peut-il aider ?
Je l'utilise personnellement, depuis son installation, j'ai moins (voire plus du tout) de pub dans mes apps, mais est-ce qu'il bloque seulement le retour des pubs et pas le départ des données ?
(Pour info, ça fait un mini VPN en local et insère un DNS menteur.)

Exactement, un vrai DOS, pure, 16-bits, en mode réel, mais avec un processeur capable de passer en 32-bits

En gros, à partir de DOS
- ça charge le noyaux Linux en mémoire haute après avoir vérifié qu'il n'y ait pas de driver chargé pour cette mémoire (HIMEM.SYS).
- ça installe un TSR pour appeler un userland basé sur Busybox.
à vu de nez, ça doit merdouiller quand on passe en mode protégé sous DOS.
De loin, ça me fait penser à ce que devait être grub4DOS, les anciens confirmeront peut-être.

C'est même surprenant ce qu'on obtient.
Mes collègues ont demandé "realtime multithreaded application in C with DJGPP without pthread".
Ben, l'IA a répondu, avec la bonne API…
Elle a juste confondu "Realtime" et "Realmode", mais le code paraissait correct à première vu,
avec manipulation du vecteur d’interruption etc…
On s'attendait plutôt à des bricoles du type setjmp() / longjmp().

Quand on lit qu'ils veulent imposer la libération des spéc matériel et des protocoles de communication des fabricants à la fin du support du téléphone ou du gadget IoT…
J'ai l'impression que c'est trop gros et que ça passera pas.
Il y a un financement participatif pour loger Richard Stallman et Theo de Raadt à Bruxelle le temps du lobbying ?

Merci pour cette réponse,
Cette solution est en cours de test, car elle semble correspondre au besoin.
Cordialement

La solution suggérer par xenom (tmux et les plugins continnum/resurect) semble plus simple à mètre en place.
Merci pour les réponses.

C'est un choix historique,
mon outil de travail principal, un cross-compilo pour freeDOS, a été fait dans un environnement cygwin 32Bits à l'époque de la migration vers des OS 64bits ne supportant plus l’exécution de programme DOS natif.
Une migration est à envisager aujourd'hui, cygwin 3.3 est la dernière version à supporter le 32 bits. WSL sera peut-être testé à ce moment-là.

à voir,
la nuance, c'est que c'est pour du travail en local, pas de ssh et autre.

c'est tentant, mais je fais de la cross compil pour FreeDos avec DJGPP au quotidien et la chaine en usage est sous cygwin…

C'est effectivement quelque chose comme cela, un rechargement automagique de toute les sessions précédente, un peu comme les sessions de Firefox après un reboot du navigateur.

On me suggère de proposer :
Windows 10 Mobile, je garde très longtemps mes téléphones

Il y a un warning pour ça maintenant dans gcc.
La première fois avec ce bug est vraiment douloureuse.

Paradox is not dead !
Un client nous a demandé de faire une intervention il y a moins d'un an sur serveur NT4 pour retaper le système qui c'était mis de travers…
Bizarrement, ils nous ont concédé que le système vieillissait un peu et qu'une virtualisation serait du plus belle effets.

On est au moins 2 en France, j'ai un chef :)

Quand tu parles de connecteur Paradox, tu parles de la base de donnée de borland qui date de longtemps?

Pour de l'embarqué,
Le projet a commencé avant émergence de noyaux temps réel dur libre.
Maintenant, on gère la dette techno, l'avantage, c'est que c'est beaucoup plus calme que le monde JavaScript…

Et c'est mon quotidien.
Bon, en compilation croisé et du bricolage pour GDB, c'est supportable.

Mais ça prête à confusion, je m'attendait à ce DDD

Malheureusement,
Le support de certains langages est soit retiré (Ruby) soit ajourné (C/C++/Fortran).
J'aime toujours cet IDE, mais sans mon langage du quotidien, C, c'est pas pareil…
Je crois que le retour du C est prévu pour la version de septembre 2019.

Bonsoir Stéphane.

Mon commentaire a peut être paru un peu sec. Je souhaite corriger un peu le tire et peut être éclairer un peu plus nos lecteur peu habitué à l'IEC 61131-3.

En gros, l'IEC 61131-3 définie 5 langages. Il y a les types textuel:
- Le ST (Structured Text) qui ressemble fortement au Pascal.
- Le IL (Instruction List), lui, c'est plutôt de l'assembleur.
Et les graphique:
- le Ladder, des schéma éléctrique.
- le Sequential function chart (SFC), Grafcet (enchaînement d'action et de condition).
- le Function block diagram (FBD), diagramme électronique en gros.
Il y a aussi une bibliothèque standard.
Pour les plus curieux il y a ce lien.
Et les plus acharné, il existe un runtime de codesys pour raspberry PI. (codesys c'est un peu tout, un IDE et un runtime. Le runtime tourne au dessus d'un OS et prend des binaires, peut importe le(s) langage(s) d'origine du programme)

Les automaticiens ont donc plusieurs langage à leur disposition pour exprimer au mieux leurs besoins. Pour moi, le problème, c'est qu'ils ne savent pas choisir le bon langage pour un besoin donné, pour des raisons culturel, d'enseignement et d’habitude, plus rarement par des impératifs client.

Il y a un autre souci, c'est l'abstraction. Je n'ai pas encore vu d'automaticien capable cloisonné son code efficacement. Si il y a 15 vérins à piloter avec 30 capteurs, (2 capteurs pour piloter 1 vérin), un automaticien aura la fâcheuse tendance à faire 15 copier-coller en changeant les nom de variable au lieu de faire une fonction ou un bloc fonctionnel (sorte d'objet).
Peut importe le langage, quand c'est une technique de réflexion qui manque.

Ada a sûrement d’excellentes qualités, mais j'ai du mal a voire ce qu'il peut apporter, pour un automaticien. Des bibliothèques plus nombreuse peut-être.

Je reconnais A4A est causant. Il manipule de nombreux protocoles de communication, dont ceux que je pense indispensable. D’ailleurs, pour PowerLink et EtherCat, un contrôleur Ethernet quelconque suffit pour avoir un maître ou il faut impérativement du matos Hilscher? A4A permet-il aussi de programmer des esclaves sur ces protocoles?

Cordialement.
Sébastien

Les automaticiens ont beaucoup de mal avec la nouveauté et sont embourbés avec omniprésence de Codesys.
Il propose tout les langages de l'IEC 61131-3 avec en particulier le Texte Structuré et le Ladder et il est souvent refourgué avec les automates de façon plus ou moins maquillé.

Le Texte Structuré est proche de la syntaxe Pascale et permet de faire des boucles et des tests de façon trivial. Les automaticiens ne l'utilisent pas, et à la limite, le fuit.

Le Ladder est quand à lui un langage graphique prévu pour faire des programme à la manière d'un schéma électrique. Pour les boucles et les tests, bah, il y a le goto. C'est ce langage que les automaticiens veulent, parce que texto "c'est ça que j'ai appris à l'école." (ça fait 15 ans qu'il est sorti de l'école et ça marche aussi avec les stagiaires)

Donc un outil de développement pour automate sans ladder semble éviter la cible automaticien.

Un automaticien utilise un automate. Il ne lui viendra pas à l'esprit d'utiliser une autre plateforme pour voire autre chose, surtout si il n'y a pas de ladder.

IBM et son PC a fait le coup il y a 30 ans.

Comme beaucoup d'utilisateurs, j'aime la distribution que j'utilise.
Elle reflète ce que j’apprécie sous gnu/linux et j’aime qu'on en parle dans ces conditions.
Cela met en avant les travaux des contributeurs de celle ci et incite à chercher le "pourquoi elle?".
Je cherche encore la news ou le journal qui parlera de migration vers gentoo.
Je perd pas espoir avec systemd et openrc.

Dommage,
Tu n'as pas précisé que la distribution retenue est SLES.