Et ils sont parfaitement routables, c'est juste qu'ils n'ont pas le droit d'aller dans le grand Ternet sauvage.
C'est pour ça que je parle de convention. Et une implémentation réseau bien faite se doit de respecter ces conventions ( que ce soit un réseau local qui se connecte vers l'extérieur ou un intermédiaire relayant des données publiques sur le Grand Ternet Sauvage).
Même si en pratique tu peux les router, il s'agit d'une convention : tu définis tes tables de routage pour ne pas relayer les adresses locales vers l'extérieur:
L'IANA (Internet Assigned Numbers Authority) a attribué plusieurs plages d'adresses devant être utilisées par les réseaux privés.
Les plages d'adresses devant être utilisées par les réseaux privés sont les suivantes :
Class A: 10.0.0.0 to 10.255.255.255
Class B: 172.16.0.0 to 172.31.255.255
Class C: 192.168.0.0 to 192.168.255.255 Je continue la citation : Une adresse IP se trouvant dans ces plages est par conséquent considérée comme étant non routable car elle n'est pas unique . Tout réseau privé devant utiliser des adresses IP en interne peut utiliser toute adresse se trouvant dans ces plages sans nécessiter de coordination avec l'IANA ou un répertoire Internet. Les adresses se trouvant dans cet espace d'adresse privé sont seulement uniques dans un réseau privé donné.
Toutes les adresses extérieures à ces plages sont considérées comme publiques.
?? Tu peux configurer un routeur pour drop des paquets selon des règles (genre des réseaux privés), tu peux renvoyer des icmp unreachable, mais le DNS n'a pas grand chose à voir là dedans? quand je tape les serveur web www.google.fr depuis une IP en 10.x.x.x, que je traverse le réseau 192.168.x.x puis un autre, puis je me fait NAT sur internet, qu'est ce que vient faire le DNS?
Ce que je comprends du commentaire auquel tu réponds, c'est que les serveurs racines qui viennent à recevoir une résolution de nom par des IP considérées comme privées ne répondent pas à ces requêtes (probablement en dropant les paquets avant même qu'ils n'atteignent le serveur DNS en lui-même - c'est d'ailleurs une bonne pratique que de droper les paquets issus d'ip locale arrivant sur une interface externe).
Si ça te chante de router tes paquets considérés comme privés vers le réseau public, tu peux le faire, mais je ne pense pas qu'ils iront plus loin que le routeur de ton FAI qui ne saura pas quoi en faire (car comme le dit le lien que je cite, ces IP ne sont pas considérées comme unique).
le NAT à outrance a forcé les gens à imaginer que les réseaux privés étaient très différents et étanches à un grand Internet (aux contours mal définis),
Les "contours" d'internet sont très bien définis. La convention veut que des IP sont considérées comme locales. Les autres IP sont publiques et uniques sur Internet. De ce fait aucun routeur ne devrait router des adresses privées ailleurs que sur des réseaux privés.
le posteur original voulait un protocole de communication autre que TCP/IP pour les "brancher en réseau" (c'est vague). Kermit permet de faire de l'échange de fichier sur un port série avec autre chose que TCP/IP.
Effectivement … Et il y en a d'autres (a une époque il y avait pléthore de freewares sir disquettes qui permettaient de faire ça).
Le port parallèle est un média. Maintenant, utiliser un port parallèle pour "brancher en réseau", je connais plip, et plip c'est du TCP/IP.
Il y avait aussi des protocoles propriétaires permettant de faire de l'échange style kermit.
Hein? TCP/IP c'est du réseau. Internet c'est un grand réseau c'est tout.
TCP/IP inclut des plages réseau non routables (127.x.X.X ou 10.X.X.X par exemple). Les équipement conçus pour relayer le trafic externe ne relaient pas ce trafic. De plus Internet ce n'est pas "un grand réseau" mais une interconnection de réseaux.
C'est un peu overkill, non? Tu mets un switch tout bête, tu prends 3 adresses IP dans le même sous-réseau et ça marche
Oui c'est vrai.
ah bah c'est pas unidirectionnel alors. La machine demande un truc à un serveur de mise à jour, et le serveur lui envoie une réponse, c'est bidirectionnel. Et si le serveur de mise à jour décide de t'envoyer un virus, bimbamboum.
Dans l'absolu tu as raison (et c'est aussi ce qui se passe avec un terminal série que tu as cité dans un commentaire précédent) : mais la communication n'est pas à l'initiative d'un système externe Ca limite déjà pas mal les attaques. Et en général les serveurs permettant de mettre à jour ses distributions sont assez surs (ilk faut juste bien choisir ses serveurs).
avec le port série tu peux faire une console série (connexion unidirectionnelle)
Une console série est bidirectionnelle. La console envoie des signaux a ton terminal et ton terminal répond. Et "port série c'est vague. Il y a plusieurs normes de liaisons série (rs232, rs422, rs485 …). De plus tu peux faire passer du TCP/IP sur une liaison série ( voir https://docstore.mik.ua/orelly/networking_2ndEd/tcp/ch06_02.htm). Les premières liaisons internet via modem RTC utilisaient un port rs232.
ou des échanges de fichiers via kermit je crois.
La liaison série, c'est la liaison physique. Kermit c'est le protocole. Il y en a d'autres. Tu peux faire ce que tu veux à partir du moment ou les extrémités de tes liaisons savent se parler. Soit un protocole existant, soit tu l'inventes.Durant mes études j'avais fait un TP qui permettait de lancer un invité de commande DOS (msdos 6.22) depuis une console série Wise.
Pour le port parallèle, tu passes par TCP/IP si je ne dis pas de bêtises
J'ai l'impression que tu dis beaucoup de bêtisee … :). La encore le port parallèle c'est le média. Ensuite tu as divers types de ports paralleles ( il faut d'ailleurs préciser la norme utilisée) : certains sont unidirectionnels de base, d'autres bidirectionnels (dans le sens ou tu peux lire et écrire des données depuis les registres de données de ton port) - bien qu'une astuce, avec le logiciel adéquat permettait d'utiliser un port parallele unidirectionnel en bidirectionnel (je n'arrive plus à trouver le schéma).
merci pour ces noms d'antibiotiques, hors médecine c'est peu connu. J'ai l'impression que les "vieux" médicament ont une liste longue comme un bras d'effet secondaire grave, avec une forte efficacité.
Je dirais que c'est normal : les "nouveaux ont probablement autant d'effets secondaires qui ne sont pas encore connus (mais qui seront différent - ou pas - des effets secondaires des vieux). D'ou l'intéret d'avoir le choix, et de ne pas non plus "jeter" les vieux sous prétextes qu'ils ont trop d'effets secondaires (par contre s'en débarrasser lorsque le risque est plus important que l'effet bénéfique apporté est une bonne idée).
Je crois que je me suis mal exprimé : la directive semble ne pas avoir fait la même confusion que le journaliste et c'est ça qui me rassure. Maintenant en pratique je suis d'accord que la mise en pratique ne sera pas simple.
Oui mais TCP/IP, c'est de la communication entre systèmes différents: il faut bien des standards pour que l'on puisse interconnecter les divers systèmes entre eux (un peu comme il y a des normes pour connecter des matériels audio entre eux).
Les logiciels libres ne sont pas dans le champ de la directive, parce que « ce ne sont pas des produits lancés sur le marché parce qu'ils sont développés et fournis gratuitement ».
Je pensais que cette phrase venait du texte original mais il semble d'après une réponse à mon commentaire que cette tournure est une approximation journalistique grossière. L'auteur de l'article ne connaît pas son sujet et mélange tout. Bel exemple de désinformation.
Certes, il y a sans doute moyen d'être plus précis,
With the aim of not hampering innovation: (i) free and open-source software developed or supplied outside the course of commercial activity, as well as (ii) the source code of software, should be excluded from the definition of products covered under the proposal (Recital 13).
Ce point montre un méconaissance de ce qu'est un logiciel libre. Je pensais qu'en 2023 on ne ferait plus ce genre d'erreur (au moins au nuiveau européen).
Oups .. j'ai ecrit le contraire de ce que je pensais :
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je pense que c'est du à autre chose.
L'auteur semble dire que le fait que Rust ne soit pas un langage objet l'empêche d'implémenter correctement un GUI. Mais je trouve que ce n'est pas justifié.
Tk n'est pas implémenté en POO il me semble. X11 et les premières bibliothèques graphiques ne l'étaient pas non plus. Il y a quelques années, la programmation graphique sous Windows se faisait en C et pas en C++ et il me semble que pendant longtemps, GTK était écrite en C (je ne sais pas si c'est toujours le cas). EFL, qui sert de base à Enlightenment, est majoritairement écrit en C. Donc on peut facilement se passer de langages objet pour écrire une IHM graphique.
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je ne pense pas que c'est du à autre chose.
J'ai aussi un modèle rechargeable … mais le mettre ailleurs que dans la salle de bains pour le recharger n'est pas très ergonomique. Et pour ceux qui ont peur de faire tomber le rasoir en charge dans l'eau, il faut éviter de mettre le chargeur a proxuimité de la baignoire ou du lavabo. Sinon j'ai remarqué que certains rasoirs ne fonctionnent pas lorsqu'ils sont en charge (le chargeur branché) - probablement pour éviter de le faire tomber à l'eau lorsqu'on l'utilise en le chargeant.
Je n'ai jamais eu de lave-linge ou seche-linge dans ma salle de bain, à vrai dire je n'y aurais pas pensé.
J'ai déjà eu, car il n'y avait pas de place ailleurs.
Le rasoir électrique, je n'en ai toujours pas compris l'intérêt quand un truc mécanique fait tout aussi bien, voire mieux le job, et à la même vitesse voire même plus vite.
Le rasoir électrique a un intéret économique, et peut-être écologique par rapport à beaucoup de rasoirs à lame jetable.
D'ailleurs, on peut vraiment décrire un triangle avec juste une hauteur et une largeur? Bien sûr que non! C'est encore un truc débile.
Bien sur que si : un triangle rectangle. Et on peut décrire un triangle equilateral avec une seule dimansion. Un triangle rectangle isocèle se décrit avec juste la mesure de l'un des deux côtés constituant l'angle droit.
Mais comme tu le soulignes, ce sont des triangles particuliers, comme les carrés sont des rectangles particuliers. Maintenant fau-il une classe par type de forme ? Ca doit dépendre du besoin.
Perso, je vois l'héritage comme le goto: c'est utile, mais si on peut s'en passer, autant s'en passer. L'utiliser partout ou le bannir absolument, c'est du dogmatisme, et ça ne mène à rien de bon.
En pratique, j'en utilise souvent, mais je n'ai pas souvenir d'avoir un seul programme qui soit de l'objet pur…
Ta remarque me fait penser à quelque chose : Comment modéliser ce type de choses en UML ?
J'étend la question à un sujet qui me trottine dans la tête depuis un moment : UML est un modèle qui est assez "orienté" objet (il ne devrait d'ailleurs pas s'appeler "Uml" mais OML". Je le trouve inadapté pour modéliser des concepts issus des langages fonctionnels ou il n'y a pas forcément d'objet (je pense notamment à Erlang qui a la notion de process que l'on voit un peu partout - avec OTP et le concept de worker/superviseur ou de behavior). N'étant ni un spécialiste UML, ni un spécialiste Erlang, je me demande encore si UML est adapté à la modélisation Erlang (je pense que certaines choses peuvent se représenter en UML, mais qu'il manque quelque chose à UML pour pouvoir modéliser correctement ces concepts - mais c'est peut-être de la méconnaissance).
il y aquand même les rasoirs eletriques, lave-linge, seche-linge,aspirateur. Il y a aussi la charge de la brosse à dent électrique. mais pour les cheveux je te rejoins: pas besoin d'etre dans la salle de bains.
il y a les téléphones DECT qui fonctionnent plutôt bien. Et des FAI comme Free permettent d'associer directement un DECT avec une freebox, du coup pas besoin de base (moins de fil côté box).
L'addiction au téléphone se gère plus par une limitation de son usage (plage horaire, durée, connexion) que par une interdiction d'usage dans la salle de bain qui pourrait avoir un effet déplorable sur l'hygiène.
Je suis assez d'accord avec la conclusion. Si l'utilisation du telephone dans la salle de bain est issu d'un problème de dépendance, se contenter de l'interdire dans la salle de bain ne règlera pas le problème (mais je n'irai pas jusque dire que ça posera des problèmes d'hygiène par contre). Si l'utilisation du smartphone dans la salle de bains est lié à un problème de dépendance, régler le problème de dépendance règlera le problème de téléphone dans la salle de bains. Mais d'un autre côté, l'interdictiuon de telephone dans la salle de bain peut être un moyen de "désintoxiquer" une personne dépendante.
Les 2 scripts peuvent être exécutés en même temps par des applications différentes.(les utilisateurs peuvent différents aussi)
Veux-tu dire que script 1 peut être exécuté par plusieurs
utilisateurs en même temps, et script 2 aussi ?
Pour utilisation simultanée de une ou plusieurs instances de script1 et une instance de script2 il n'y a pas de problème.
Pour utilisation simultanée de plusieurs instances de script2 …. supposons :
- un utilisateur execute script 1
- deux utilisateurs executent script2, en déplaçant le fichier commun vers le fichier 2.
- entre temps un utilisateur exécute script1. L'enchainement donne, mais dans un temps très court :
* exécution de script2 (déplacement du fichier commun vers fichier2)
* exécution de script1 (regénération du fichier commun
* exécution de script2 (déplacement de fichier commun vers fichier 2)
Tu risques d'écraser fichier2. Il faut donc faire attention au nommage de fichier2 dans ton script. C'est surtout cette partie qui pourrait poser problème.
Maintenant tout dépend de ta façon de nommer script2.
Ca peut être un bon exercice pour développer la capacité de lecture rapide … enfin, pas pour ceux qui souffrent de problème de conduit intestinal bouché.
Quand j'ai envie d'écouter de la musique sous la douche, je prends juste le téléphone. Pas besoin d'une qualité hi-fi de toutes façons: le bruit de la douche m'êmpêche de l'apprécier. Ca m'arrive assez rarement, et quand ça m'arrive c'est juste pour l'ambiance (et parfois pour écouter un livre audio).
Maintenant effectivement il y a des gens qui aiment se détendre en prenant un bain et en écoutant la musique tout en prenant un verre de vin, et peut-être que pour eux, il est plus appréciable d'avoir une enceinte BT de qualité. Mais bon. Un bain de toute façons c'est pas écolo … :)
Quand j'ai commencé à me mettre à Python, j'ai été assez vite séduit, cependant, je me suis vite rendu compte que python "forçait" à faire les choses à sa façon, et je me suis retrouvé à devoir me faire des noeuds au cerveau et à faire des trucs dégueulasses, ou beaucoup trop verbeux, parce que la façon de faire de python était trop rigide. Faire les mêmes choses en Ruby me posait moins de problème : je n'avais pas l'impression d'être dans le carcan Python.
Tout celà pour dire que bien souvent un langage donné va permettre de faire des choses dans un certain contexte (celui pour lequel il a été pensé), mais va poser problème dans un autre contexte. Rust a été écrit pour écrire du code safe, et rend difficile l'écriture de code non safe. Ca ne me choque pas plus que ça. Est-ce volontaire ? Je ne pense pas : c'est juste une conséquence de sa conception initiale. Peut-être qu'à l'avenir les concepteurs du langage faciliteront la vie des développeurs qui doivent écrire du code non ssfe … ou pas. Et dans ce cas, en attendant vaut-il mieux peut-être utiliser un autre langage pour écrire plus facilement les parties de code non safe avec les batteries de test adéquates ? Car je partage l'avis de l'auteur : il est peut-être plus dangereux d'écrire du code non safe en Rust qu'en C … tout comme il peut être dangereux d'utiliser un couteau de cuisine pour ouvrir une boite de conserve. Ce n'est pas fait pour.
Effectivement, je suis resté un peu trop concis, désolé. C'est le problème de faire trop de choses en même temps. Je commentais la possibilité d'éditer un commentaire suite à l'édition du lien. Je trouve pas très ergonomique pour la personne qui poste le lien d'éditer le lien, puis ouvrir l'interface de commentaires pour mettre sa phrase de description … Et côté lecteur ce n'est pas pratique non plus car pour voir les commentaires, il faut ouvrir une interface spécifique.
Une zone de texte courte, optionnelle, qui indiquerait en une phrase de quoi parle le lien (notamment quand c'est de l'anglais), affichée sans qu'on ait à cliquer pour l'ouvrir me paraît plus adéquate.
[^] # Re: Un simple routeur avec interface d'administration suffit... pour commencer
Posté par totof2000 . En réponse au message Remplaçant Ipx, NetBEUI appletalk en 2023. Évalué à 3.
C'est pour ça que je parle de convention. Et une implémentation réseau bien faite se doit de respecter ces conventions ( que ce soit un réseau local qui se connecte vers l'extérieur ou un intermédiaire relayant des données publiques sur le Grand Ternet Sauvage).
[^] # Re: Un simple routeur avec interface d'administration suffit... pour commencer
Posté par totof2000 . En réponse au message Remplaçant Ipx, NetBEUI appletalk en 2023. Évalué à 5.
Même si en pratique tu peux les router, il s'agit d'une convention : tu définis tes tables de routage pour ne pas relayer les adresses locales vers l'extérieur:
https://www.ibm.com/docs/fr/networkmanager/4.2.0?topic=translation-private-address-ranges
Je cite :
L'IANA (Internet Assigned Numbers Authority) a attribué plusieurs plages d'adresses devant être utilisées par les réseaux privés.
Les plages d'adresses devant être utilisées par les réseaux privés sont les suivantes :
Class A: 10.0.0.0 to 10.255.255.255
Class B: 172.16.0.0 to 172.31.255.255
Class C: 192.168.0.0 to 192.168.255.255
Une adresse IP se trouvant dans ces plages est par conséquent considérée comme étant non routable car elle n'est pas unique . Tout réseau privé devant utiliser des adresses IP en interne peut utiliser toute adresse se trouvant dans ces plages sans nécessiter de coordination avec l'IANA ou un répertoire Internet. Les adresses se trouvant dans cet espace d'adresse privé sont seulement uniques dans un réseau privé donné.
Toutes les adresses extérieures à ces plages sont considérées comme publiques.
Ce que je comprends du commentaire auquel tu réponds, c'est que les serveurs racines qui viennent à recevoir une résolution de nom par des IP considérées comme privées ne répondent pas à ces requêtes (probablement en dropant les paquets avant même qu'ils n'atteignent le serveur DNS en lui-même - c'est d'ailleurs une bonne pratique que de droper les paquets issus d'ip locale arrivant sur une interface externe).
Si ça te chante de router tes paquets considérés comme privés vers le réseau public, tu peux le faire, mais je ne pense pas qu'ils iront plus loin que le routeur de ton FAI qui ne saura pas quoi en faire (car comme le dit le lien que je cite, ces IP ne sont pas considérées comme unique).
Les "contours" d'internet sont très bien définis. La convention veut que des IP sont considérées comme locales. Les autres IP sont publiques et uniques sur Internet. De ce fait aucun routeur ne devrait router des adresses privées ailleurs que sur des réseaux privés.
[^] # Re: Quel matériel, pour quoi faire ?
Posté par totof2000 . En réponse au message Remplaçant Ipx, NetBEUI appletalk en 2023. Évalué à 3.
Effectivement … Et il y en a d'autres (a une époque il y avait pléthore de freewares sir disquettes qui permettaient de faire ça).
Il y avait aussi des protocoles propriétaires permettant de faire de l'échange style kermit.
[^] # Re: Un simple routeur avec interface d'administration suffit... pour commencer
Posté par totof2000 . En réponse au message Remplaçant Ipx, NetBEUI appletalk en 2023. Évalué à 3.
TCP/IP inclut des plages réseau non routables (127.x.X.X ou 10.X.X.X par exemple). Les équipement conçus pour relayer le trafic externe ne relaient pas ce trafic. De plus Internet ce n'est pas "un grand réseau" mais une interconnection de réseaux.
Oui c'est vrai.
Dans l'absolu tu as raison (et c'est aussi ce qui se passe avec un terminal série que tu as cité dans un commentaire précédent) : mais la communication n'est pas à l'initiative d'un système externe Ca limite déjà pas mal les attaques. Et en général les serveurs permettant de mettre à jour ses distributions sont assez surs (ilk faut juste bien choisir ses serveurs).
[^] # Re: Quel matériel, pour quoi faire ?
Posté par totof2000 . En réponse au message Remplaçant Ipx, NetBEUI appletalk en 2023. Évalué à 3.
Une console série est bidirectionnelle. La console envoie des signaux a ton terminal et ton terminal répond. Et "port série c'est vague. Il y a plusieurs normes de liaisons série (rs232, rs422, rs485 …). De plus tu peux faire passer du TCP/IP sur une liaison série ( voir https://docstore.mik.ua/orelly/networking_2ndEd/tcp/ch06_02.htm). Les premières liaisons internet via modem RTC utilisaient un port rs232.
La liaison série, c'est la liaison physique. Kermit c'est le protocole. Il y en a d'autres. Tu peux faire ce que tu veux à partir du moment ou les extrémités de tes liaisons savent se parler. Soit un protocole existant, soit tu l'inventes.Durant mes études j'avais fait un TP qui permettait de lancer un invité de commande DOS (msdos 6.22) depuis une console série Wise.
J'ai l'impression que tu dis beaucoup de bêtisee … :). La encore le port parallèle c'est le média. Ensuite tu as divers types de ports paralleles ( il faut d'ailleurs préciser la norme utilisée) : certains sont unidirectionnels de base, d'autres bidirectionnels (dans le sens ou tu peux lire et écrire des données depuis les registres de données de ton port) - bien qu'une astuce, avec le logiciel adéquat permettait d'utiliser un port parallele unidirectionnel en bidirectionnel (je n'arrive plus à trouver le schéma).
[^] # Re: très intéressant
Posté par totof2000 . En réponse au journal Et encore un scandale sanitaire.... Évalué à 4.
Je dirais que c'est normal : les "nouveaux ont probablement autant d'effets secondaires qui ne sont pas encore connus (mais qui seront différent - ou pas - des effets secondaires des vieux). D'ou l'intéret d'avoir le choix, et de ne pas non plus "jeter" les vieux sous prétextes qu'ils ont trop d'effets secondaires (par contre s'en débarrasser lorsque le risque est plus important que l'effet bénéfique apporté est une bonne idée).
[^] # Re: Pas d'accord avec le point 2
Posté par totof2000 . En réponse au journal L'UE révise sa directive sur la responsabilité du fait des produits. Évalué à 4.
Je crois que je me suis mal exprimé : la directive semble ne pas avoir fait la même confusion que le journaliste et c'est ça qui me rassure. Maintenant en pratique je suis d'accord que la mise en pratique ne sera pas simple.
[^] # Re: remplaçant IPX ou NetBEUI
Posté par totof2000 . En réponse au message Remplaçant Ipx, NetBEUI appletalk en 2023. Évalué à 4. Dernière modification le 13 mars 2023 à 16:35.
Pourquoi ?
Oui mais TCP/IP, c'est de la communication entre systèmes différents: il faut bien des standards pour que l'on puisse interconnecter les divers systèmes entre eux (un peu comme il y a des normes pour connecter des matériels audio entre eux).
Maintenant si tu es nostalgique d'IPX/SPX :
https://tldp.org/HOWTO/IPX-HOWTO-10.html
Autre lien intéressant :
https://www.halolinux.us/networking/alternativenetworkstackoptions.html
Pour netbeui, je n'ai pas pris le temps de chercher mais il semble que ça ne soit pas supporté (peut-être devrais-tu demander à ChatGT ?).
[^] # Re: Pas d'accord avec le point 2
Posté par totof2000 . En réponse au journal L'UE révise sa directive sur la responsabilité du fait des produits. Évalué à 3.
Je réagissais à la phrase ci-dessous :
Je pensais que cette phrase venait du texte original mais il semble d'après une réponse à mon commentaire que cette tournure est une approximation journalistique grossière. L'auteur de l'article ne connaît pas son sujet et mélange tout. Bel exemple de désinformation.
Oui, d'après ce commentaire :
Ca me rassure.
# remplaçant IPX ou NetBEUI
Posté par totof2000 . En réponse au message Remplaçant Ipx, NetBEUI appletalk en 2023. Évalué à 4. Dernière modification le 13 mars 2023 à 15:22.
Oui, il s'appelle TCP/IP.
http://www.materiel-informatique.be/netbeui.php
https://fr.wikipedia.org/wiki/NetBEUI
https://fr.wikipedia.org/wiki/Internetwork_packet_exchange
http://www.poradykomputerowe.eu/fr/protokoly-sieciowe-ipx-spx-netbeui-appletalk/
# Pas d'accord avec le point 2
Posté par totof2000 . En réponse au journal L'UE révise sa directive sur la responsabilité du fait des produits. Évalué à 4.
Ce point montre un méconaissance de ce qu'est un logiciel libre. Je pensais qu'en 2023 on ne ferait plus ce genre d'erreur (au moins au nuiveau européen).
[^] # Re: J'ai l'impression que l'article mélange un peu tout ....
Posté par totof2000 . En réponse au lien Building a proper UI framework in Rust is hard and often unintuitive.. Évalué à 3.
Oups .. j'ai ecrit le contraire de ce que je pensais :
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je pense que c'est du à autre chose.
# J'ai l'impression que l'article mélange un peu tout ....
Posté par totof2000 . En réponse au lien Building a proper UI framework in Rust is hard and often unintuitive.. Évalué à 4. Dernière modification le 11 mars 2023 à 16:24.
L'auteur semble dire que le fait que Rust ne soit pas un langage objet l'empêche d'implémenter correctement un GUI. Mais je trouve que ce n'est pas justifié.
Tk n'est pas implémenté en POO il me semble. X11 et les premières bibliothèques graphiques ne l'étaient pas non plus. Il y a quelques années, la programmation graphique sous Windows se faisait en C et pas en C++ et il me semble que pendant longtemps, GTK était écrite en C (je ne sais pas si c'est toujours le cas). EFL, qui sert de base à Enlightenment, est majoritairement écrit en C. Donc on peut facilement se passer de langages objet pour écrire une IHM graphique.
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je ne pense pas que c'est du à autre chose.
[^] # Re: linuxfr aussi
Posté par totof2000 . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 2.
J'ai aussi un modèle rechargeable … mais le mettre ailleurs que dans la salle de bains pour le recharger n'est pas très ergonomique. Et pour ceux qui ont peur de faire tomber le rasoir en charge dans l'eau, il faut éviter de mettre le chargeur a proxuimité de la baignoire ou du lavabo. Sinon j'ai remarqué que certains rasoirs ne fonctionnent pas lorsqu'ils sont en charge (le chargeur branché) - probablement pour éviter de le faire tomber à l'eau lorsqu'on l'utilise en le chargeant.
[^] # Re: linuxfr aussi
Posté par totof2000 . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 2.
J'ai déjà eu, car il n'y avait pas de place ailleurs.
Le rasoir électrique a un intéret économique, et peut-être écologique par rapport à beaucoup de rasoirs à lame jetable.
[^] # Re: l'héritage et les exemples pourris
Posté par totof2000 . En réponse au lien « Clean code » : performances lamentables. Évalué à 4.
Bien sur que si : un triangle rectangle. Et on peut décrire un triangle equilateral avec une seule dimansion. Un triangle rectangle isocèle se décrit avec juste la mesure de l'un des deux côtés constituant l'angle droit.
Mais comme tu le soulignes, ce sont des triangles particuliers, comme les carrés sont des rectangles particuliers. Maintenant fau-il une classe par type de forme ? Ca doit dépendre du besoin.
Ta remarque me fait penser à quelque chose : Comment modéliser ce type de choses en UML ?
J'étend la question à un sujet qui me trottine dans la tête depuis un moment : UML est un modèle qui est assez "orienté" objet (il ne devrait d'ailleurs pas s'appeler "Uml" mais OML". Je le trouve inadapté pour modéliser des concepts issus des langages fonctionnels ou il n'y a pas forcément d'objet (je pense notamment à Erlang qui a la notion de process que l'on voit un peu partout - avec OTP et le concept de worker/superviseur ou de behavior). N'étant ni un spécialiste UML, ni un spécialiste Erlang, je me demande encore si UML est adapté à la modélisation Erlang (je pense que certaines choses peuvent se représenter en UML, mais qu'il manque quelque chose à UML pour pouvoir modéliser correctement ces concepts - mais c'est peut-être de la méconnaissance).
[^] # Re: linuxfr aussi
Posté par totof2000 . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 2.
il y aquand même les rasoirs eletriques, lave-linge, seche-linge,aspirateur. Il y a aussi la charge de la brosse à dent électrique. mais pour les cheveux je te rejoins: pas besoin d'etre dans la salle de bains.
[^] # Re: linuxfr aussi
Posté par totof2000 . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 3.
Je suis assez d'accord avec la conclusion. Si l'utilisation du telephone dans la salle de bain est issu d'un problème de dépendance, se contenter de l'interdire dans la salle de bain ne règlera pas le problème (mais je n'irai pas jusque dire que ça posera des problèmes d'hygiène par contre). Si l'utilisation du smartphone dans la salle de bains est lié à un problème de dépendance, régler le problème de dépendance règlera le problème de téléphone dans la salle de bains. Mais d'un autre côté, l'interdictiuon de telephone dans la salle de bain peut être un moyen de "désintoxiquer" une personne dépendante.
[^] # Re: Il peut y avoir un problème ...
Posté par totof2000 . En réponse au message accès concurrentiel aux fichiers. Évalué à 3.
Toutes les applis ne gèrent pas ce lock. Mais effectivement si c'est fait, c'est une idée.
# Il peut y avoir un problème ...
Posté par totof2000 . En réponse au message accès concurrentiel aux fichiers. Évalué à 4. Dernière modification le 09 mars 2023 à 21:21.
Veux-tu dire que script 1 peut être exécuté par plusieurs
utilisateurs en même temps, et script 2 aussi ?
Pour utilisation simultanée de une ou plusieurs instances de script1 et une instance de script2 il n'y a pas de problème.
Pour utilisation simultanée de plusieurs instances de script2 …. supposons :
- un utilisateur execute script 1
- deux utilisateurs executent script2, en déplaçant le fichier commun vers le fichier 2.
- entre temps un utilisateur exécute script1. L'enchainement donne, mais dans un temps très court :
* exécution de script2 (déplacement du fichier commun vers fichier2)
* exécution de script1 (regénération du fichier commun
* exécution de script2 (déplacement de fichier commun vers fichier 2)
Tu risques d'écraser fichier2. Il faut donc faire attention au nommage de fichier2 dans ton script. C'est surtout cette partie qui pourrait poser problème.
Maintenant tout dépend de ta façon de nommer script2.
[^] # Re: conditions d'utilisation
Posté par totof2000 . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 2.
Marant, ton commentaire me fait penser au fameux "1200 euros minimum pour les retraités" …
[^] # Re: linuxfr aussi
Posté par totof2000 . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 2.
Ca peut être un bon exercice pour développer la capacité de lecture rapide … enfin, pas pour ceux qui souffrent de problème de conduit intestinal bouché.
[^] # Re: linuxfr aussi
Posté par totof2000 . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 2.
Quand j'ai envie d'écouter de la musique sous la douche, je prends juste le téléphone. Pas besoin d'une qualité hi-fi de toutes façons: le bruit de la douche m'êmpêche de l'apprécier. Ca m'arrive assez rarement, et quand ça m'arrive c'est juste pour l'ambiance (et parfois pour écouter un livre audio).
Maintenant effectivement il y a des gens qui aiment se détendre en prenant un bain et en écoutant la musique tout en prenant un verre de vin, et peut-être que pour eux, il est plus appréciable d'avoir une enceinte BT de qualité. Mais bon. Un bain de toute façons c'est pas écolo … :)
# Ca me fait penser un peu à ce que j'ai vécu à un moment avec Python .....
Posté par totof2000 . En réponse au lien When Zig is safer and faster than Rust. Évalué à 8. Dernière modification le 09 mars 2023 à 18:18.
Quand j'ai commencé à me mettre à Python, j'ai été assez vite séduit, cependant, je me suis vite rendu compte que python "forçait" à faire les choses à sa façon, et je me suis retrouvé à devoir me faire des noeuds au cerveau et à faire des trucs dégueulasses, ou beaucoup trop verbeux, parce que la façon de faire de python était trop rigide. Faire les mêmes choses en Ruby me posait moins de problème : je n'avais pas l'impression d'être dans le carcan Python.
Tout celà pour dire que bien souvent un langage donné va permettre de faire des choses dans un certain contexte (celui pour lequel il a été pensé), mais va poser problème dans un autre contexte. Rust a été écrit pour écrire du code safe, et rend difficile l'écriture de code non safe. Ca ne me choque pas plus que ça. Est-ce volontaire ? Je ne pense pas : c'est juste une conséquence de sa conception initiale. Peut-être qu'à l'avenir les concepteurs du langage faciliteront la vie des développeurs qui doivent écrire du code non ssfe … ou pas. Et dans ce cas, en attendant vaut-il mieux peut-être utiliser un autre langage pour écrire plus facilement les parties de code non safe avec les batteries de test adéquates ? Car je partage l'avis de l'auteur : il est peut-être plus dangereux d'écrire du code non safe en Rust qu'en C … tout comme il peut être dangereux d'utiliser un couteau de cuisine pour ouvrir une boite de conserve. Ce n'est pas fait pour.
[^] # Re: un lien qui mériterait une explication.
Posté par totof2000 . En réponse au lien bootkit UEFI pas cher (5000$). Évalué à 2.
Effectivement, je suis resté un peu trop concis, désolé. C'est le problème de faire trop de choses en même temps. Je commentais la possibilité d'éditer un commentaire suite à l'édition du lien. Je trouve pas très ergonomique pour la personne qui poste le lien d'éditer le lien, puis ouvrir l'interface de commentaires pour mettre sa phrase de description … Et côté lecteur ce n'est pas pratique non plus car pour voir les commentaires, il faut ouvrir une interface spécifique.
Une zone de texte courte, optionnelle, qui indiquerait en une phrase de quoi parle le lien (notamment quand c'est de l'anglais), affichée sans qu'on ait à cliquer pour l'ouvrir me paraît plus adéquate.