C'est pas joli setjmp/longjmp. Comme disent certains “Exceptions are, in essence, sophisticated GOTO statements”.
Loin de moi l'idée de penser que les exceptions sont mauvaises, mais ça n'a pas sa place dans ce langage aussi bas niveau qu'est le C. En C++ par exemple, un simple std::cout << "hello\n" peut lever une exception ce qui signifie que dans les programmes très critiques il faut absolument lire la documentation de chaque fonction qu'on utilise. Mais aussi, si j'utilise une bibliothèque qui ne documente pas bien les exceptions qu'elle peut lever (car elle en oublie d'une couche plus bas niveau) je risque tout simplement de planter mon programme car j'arriverai dans la gestion de l'exception peut-être là où je ne le souhaite pas. Alors devons nous protéger tous les appels de chaque fonction ?
On dit aussi que les exceptions sont performantes. Ce n'est pas le cas. Une fois on a réduit drastiquement les performances d'une boucle de notre application qui était écrite de cette manière :
for(...){try{something();}catch(...){blabla();}}
En
try{for(...){something();}catch(...){blabla();}
Certes une erreur d'étourderie. Mais si la fonction something() fait aussi des try-catch à tout va, les performances sont encore une fois impactées.
Pour ma part j'ai utilisé une seule fois setjmp/longjmp dans mon application (un jeu vidéo). L'idée est de faire un mécanisme de « panic » : s'il arrive quelque chose d'irrécupérable (carte corrompu, image manquante, …) au lieu de crasher l'application à la sauvage, j'affiche quelque chose à l'écran avant de quitter (un peu comme un BSOD). Mais c'est la seule utilisation viable que j'en ai.
git is great because linus did it, mercurial is better because he didn't
C'est exactement a cause de ce genre de commentaire que j’apprends pas le Rust.
Exactement. De toute façon c'est assez simple, il y a la règle de Rust : à chaque fois qu'une discussion commence sur le C ou le C++ elle finira toujours par aboutir sur Rust.
Ce dont les gens ont tendance à oublier avec le C :
C'est normé par l'ISO et par POSIX. Quand tu vas sur un système compatible POSIX tu sais que tu peux déjà compiler un projet entier : make, c99, lex, yacc, etc sont disponibles de base.
Contrairement à Rust ce n'est pas bloat. Faire un hello world minimal ne nécessite pas 35 dépendances et de liaison statiques à foison.
Contrairement à Rust un projet en C ou C++ ne télécharge pas 12000 dépendances à la npm (c.f. exa).
Contrairement à Rust, je sais que mon programme sera compatible pendant des années, Mozilla peut du jour au lendemain tout péter s'ils le souhaitent.
Contrairement à Rust, je peux tourner sur une panoplie de micro contrôleurs embarqués et m'implémenter sur une nouvelle architecture avec aise.
Longue vie au C.
git is great because linus did it, mercurial is better because he didn't
Après 30 ans, Java/C++/.Net/python/ruby/JavaScript/swift/objc/kotlin ont finis par le repousser dans les 2 seuls domaines où il perdure, à savoir la programmation très bas niveau (kernel/drivers) et l’embarqué où le hardware est digne des années 80, et nécessite de grosses optimisations pour pouvoir exister.
Et même dans l’embarqué, il reste beaucoup de scénarios ou d’autres langages sont plus adaptés.
Elles sont tirés de ton chapeau personnel ces statistiques ?
Il y a des projets récents en C, y compris dans le jeu vidéo et dans le reverse engineering. Faut juste se renseigner.
git is great because linus did it, mercurial is better because he didn't
Quand je parle de difficultés à gérer la mémoire c'est très simple à vérifier tout outillage qui existe il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.
Et à l'inverse le système d'exploitation le plus utilisé sur les serveurs au monde et dans la téléphonie mobile est écrit en C. Pour autant, pas de pannes majeures à ce que je sache.
Les boites à outils modernes comme LLVM fournissent une panoplie de “sanitizers” qui rendent le développement bien plus simple. La plupart des erreurs peuvent être déterminés pendant le cycle de développement. Pour ma part, j'ai déjà été sauvé à plusieurs reprises grâce à -fsanitize=address. (Et pas qu'en C).
git is great because linus did it, mercurial is better because he didn't
Ça ne répond pas tout à fait à ta question mais j'ai moi même régulièrement mal à mon petit doigt droit à force de massacrer la touche shift. Je suis développeur et je fais essentiellement du snake_case, en qwerty. Le seul inconvénient cet agencement par rapport à l'azerty c'est que _ est accessible en shift. Du coup je l'abuse beaucoup et j'ai parfois mal à mon petit doigt droit.
On m'a conseillé de me forcer à aussi utiliser le shift gauche (idem pour altgr/option/ctrl/cmd), qui lui, le pauvre est aussi propre qu'une salade fraichement coupée alors que l'autre paye son usure. J'essaie tant bien que mal mais c'est pas évident. En fait l'idée est de ne jamais appuyer sur le shift du même côté que la touche désirée. En gros les 3/4 des gens qui font un bon vieux ctrl+s dans Word, le font mal.
Exemples :
super_cool (je dois utiliser shift gauche car _ est proche de la main droite)
ssh pi@192.168.1.10 (je dois utiliser shift droit car @ est à gauche)
C'est très difficile de perdre des habitudes, surtout quand on écrit à une vitesse phénoménale comme moi.
git is great because linus did it, mercurial is better because he didn't
Quand j'ai aidé ma maman à acheter une nouvelle télé, on a pris une samsung car on était assez satisfait de la dernière (datant de 2011) sauf que ça a bien changé.
Au premier démarrage, un tas de questions stupides à choisir. J'ai fait refuser partout. Résultat maintenant dans le menu il y a un grand bandeau en permanence qui t'invite à te connecter un compte pour avoir du contenu personnalisé. Plus jamais de samsung.
Pour ma part, j'ai acheté une Philips Ambilight car j'adore le concept lumineux. L'autre jour j'ai eu une mise à jour … de ma télécommande. Va vraiment falloir qu'on m'explique comment on a pu en arriver là.
git is great because linus did it, mercurial is better because he didn't
Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.
Ça change rien, je viens d'essayer en local et ça a téléchargé 92 dépendances. C'est plus que le nombre de paquet total de mon image minimale de alpine.
Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.
Toujours pas d'accord. Boost c'est un framework bloat, il y a certes beaucoup de modules mais la plupart sont indépendants. Mais tu prends un mauvais exemple.
Personnellement quand je développe en C ou en C++, j'ai jamais eu à utiliser une lib externe pour faire des trucs aussi basique que générer un nombre positif dans une plage précise.
Dans mon application actuelle voilà mes dépendances :
curl
jansson
mosquitto
sqlite
Je comprends pas l'intérêt de faire une bibliothèque (comprendre paquet cargo) pour une ou deux fonctions.
A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.
Ça n'a absolument rien à voir avec le langage. Tu peux faire du full statique en C si ça te chante. Les 3/4 des bibliothèques sont fournies en statique et comme le linker est intelligent il inclue aussi que le nécessaire (à condition que la bibliothèque soit pas amalgamée).
git is great because linus did it, mercurial is better because he didn't
On fait du ELF depuis des lustres mais on continue d'appeler l'exécutable par défaut a.out. J'aimerais bien que ça sorte le nom du fichier sans son extension.
c99 bar.c
./bar
git is great because linus did it, mercurial is better because he didn't
Non alpine est utilisable en desktop aussi, il y a même GNOME et KDE !
Évidemment il reste toujours des paquets pas forcément compatible ou manquant mais comme c'est super simple d'en rajouter ça va vite. D'ailleurs je suis la raison pour laquelle il y a beaucoup de jeux et d'émulateurs ;o)
git is great because linus did it, mercurial is better because he didn't
L’intérêt principal que j’y vois est que c’est décentralisé en très grande partie et résilient. Une forge peut disparaitre
Ça permet aussi de partager le coût de l’infrastructure
C'est mignon tout plein mais; c'est pas parce qu'une personne n'utilise pas GitHub ou tout autre forge qu'il va y avoir un impact écologique. Pour que le torrent marche, il faut que les gens laissent leur PC allumés et laissent le partage actif, est-ce réellement mieux ?
Mis à part le côté partage, je souligne surtout le fait que développer quelque chose d'opensource sans la possibilité de contribuer facilement c'est légèrement contradictoire.
Les projets mednafen et lua sont opensource mais avec un développement fermés et c'est bien dommage. Pour envoyer un patch, tu sais pas si tu es sur la dernière version ou non (en ayant téléchargé une version snapshot) donc si ça se trouve ton patch est plus obsolète.
Il n'y pas que la convivialité de voir le code en ligne et de ne pas attendre un temps variable de torrent, il y a la faculté de pouvoir cloner, mettre à jour, voir l'historique, créer des patch Mercurial ou git, etc. Surtout pour un projet qui est encore en travaux.
git is great because linus did it, mercurial is better because he didn't
Une raison particulière de pas héberger le code sous un SCM public comme Mercurial ou git ?
Je n'arrive pas à le compiler sous mac car il y a des erreurs dans le CMake, j'aurais bien voulu envoyer un patch mais du coup j'ai aucune idée comment faire. Je n'ai trouvé aucune adresse mail dans le dépôt.
git is great because linus did it, mercurial is better because he didn't
Tout d'abord parce qu'aucun laptop n'a de lecteur optique. Mais se limiter à 700Mo pour les galettes est contraignant.
Pour ma part je suis partisant des archive minirootfs. C'est ce qu'il y a de plus flexible : on partitionne le disque comme on veut, on monte et un simple tar -xpf et le tour est joué.
J'ai réduit drastiquement l'installation de nos appliances en flashant nos cartes SD avec Alpine et son minirootfs plutôt que de copier une image fixe de 2Go de raspberry pi os.
git is great because linus did it, mercurial is better because he didn't
Le boitier flirc est génial et refroidit mieux qu'un ventilateur (si, j'ai testé, impressionnant).
Pour faire de la bureautique, navré de te décevoir mais tu risques d'être très frustré. C'est lent. Tout est lent. Ouvrir une page internet requiert de la patience et même si on promet du décodage 4k crois moi que ça marche pas avec tout.
J'ai aussi essayé de la visio, ça sature et c'était complètement inutilisable. Du coup mes Pi restent ceux pour quoi elles sont bien faites : du headless.
git is great because linus did it, mercurial is better because he didn't
Au travail c'est notre principal élément pour nos appliance. Heureusement qu'on a prévu la pénurie mondiale, on en a commandé 100 il y a 3 mois. Maintenant les prochaines approvisionnement ne sont pas avant fin janvier 2022. Et les compute module c'est carrément avril.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 3.
Et
strlenne renvoie pas la taille d'une chaine non plus. c.f.strlen("ça va")git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 6.
Non, tu n'as pas évoqué Rust. Tu as dit « Ou utilise Rust/autre langage moderne de son choix ». Ce n'est pas tout à fait la même chose.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 5.
C'est pas joli setjmp/longjmp. Comme disent certains “Exceptions are, in essence, sophisticated GOTO statements”.
Loin de moi l'idée de penser que les exceptions sont mauvaises, mais ça n'a pas sa place dans ce langage aussi bas niveau qu'est le C. En C++ par exemple, un simple
std::cout << "hello\n"peut lever une exception ce qui signifie que dans les programmes très critiques il faut absolument lire la documentation de chaque fonction qu'on utilise. Mais aussi, si j'utilise une bibliothèque qui ne documente pas bien les exceptions qu'elle peut lever (car elle en oublie d'une couche plus bas niveau) je risque tout simplement de planter mon programme car j'arriverai dans la gestion de l'exception peut-être là où je ne le souhaite pas. Alors devons nous protéger tous les appels de chaque fonction ?On dit aussi que les exceptions sont performantes. Ce n'est pas le cas. Une fois on a réduit drastiquement les performances d'une boucle de notre application qui était écrite de cette manière :
En
Certes une erreur d'étourderie. Mais si la fonction
something()fait aussi des try-catch à tout va, les performances sont encore une fois impactées.Pour ma part j'ai utilisé une seule fois setjmp/longjmp dans mon application (un jeu vidéo). L'idée est de faire un mécanisme de « panic » : s'il arrive quelque chose d'irrécupérable (carte corrompu, image manquante, …) au lieu de crasher l'application à la sauvage, j'affiche quelque chose à l'écran avant de quitter (un peu comme un BSOD). Mais c'est la seule utilisation viable que j'en ai.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
Exactement. De toute façon c'est assez simple, il y a la règle de Rust : à chaque fois qu'une discussion commence sur le C ou le C++ elle finira toujours par aboutir sur Rust.
Ce dont les gens ont tendance à oublier avec le C :
Longue vie au C.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
Elles sont tirés de ton chapeau personnel ces statistiques ?
Il y a des projets récents en C, y compris dans le jeu vidéo et dans le reverse engineering. Faut juste se renseigner.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 8.
Et à l'inverse le système d'exploitation le plus utilisé sur les serveurs au monde et dans la téléphonie mobile est écrit en C. Pour autant, pas de pannes majeures à ce que je sache.
Les boites à outils modernes comme LLVM fournissent une panoplie de “sanitizers” qui rendent le développement bien plus simple. La plupart des erreurs peuvent être déterminés pendant le cycle de développement. Pour ma part, j'ai déjà été sauvé à plusieurs reprises grâce à
-fsanitize=address. (Et pas qu'en C).git is great because linus did it, mercurial is better because he didn't
# linuxfr
Posté par David Demelier (site web personnel) . En réponse au lien De gauche, ils revoteront Macron. Évalué à 1.
Quel rapport avec les logiciels libres ?
git is great because linus did it, mercurial is better because he didn't
# Utiliser les deux shift
Posté par David Demelier (site web personnel) . En réponse au message Utiliser shift sans maintenir appuyé?. Évalué à 3.
Ça ne répond pas tout à fait à ta question mais j'ai moi même régulièrement mal à mon petit doigt droit à force de massacrer la touche shift. Je suis développeur et je fais essentiellement du snake_case, en qwerty. Le seul inconvénient cet agencement par rapport à l'azerty c'est que _ est accessible en shift. Du coup je l'abuse beaucoup et j'ai parfois mal à mon petit doigt droit.
On m'a conseillé de me forcer à aussi utiliser le shift gauche (idem pour altgr/option/ctrl/cmd), qui lui, le pauvre est aussi propre qu'une salade fraichement coupée alors que l'autre paye son usure. J'essaie tant bien que mal mais c'est pas évident. En fait l'idée est de ne jamais appuyer sur le shift du même côté que la touche désirée. En gros les 3/4 des gens qui font un bon vieux ctrl+s dans Word, le font mal.
Exemples :
super_cool(je dois utiliser shift gauche car _ est proche de la main droite)ssh pi@192.168.1.10(je dois utiliser shift droit car @ est à gauche)C'est très difficile de perdre des habitudes, surtout quand on écrit à une vitesse phénoménale comme moi.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Dumb tvs
Posté par David Demelier (site web personnel) . En réponse au lien LG annonce de nouvelles fonctions de ciblage publicitaire pour ses téléviseurs "intelligents". Évalué à 5.
Hélas je ne crois pas trop. Les fabricants disent eux même que faire une non-Smart TV ça ne se vendrait pas.
La seule solution actuelle c'est de ne pas les connecter à internet.
git is great because linus did it, mercurial is better because he didn't
# Dumb tvs
Posté par David Demelier (site web personnel) . En réponse au lien LG annonce de nouvelles fonctions de ciblage publicitaire pour ses téléviseurs "intelligents". Évalué à 8.
Quand j'ai aidé ma maman à acheter une nouvelle télé, on a pris une samsung car on était assez satisfait de la dernière (datant de 2011) sauf que ça a bien changé.
Au premier démarrage, un tas de questions stupides à choisir. J'ai fait refuser partout. Résultat maintenant dans le menu il y a un grand bandeau en permanence qui t'invite à te connecter un compte pour avoir du contenu personnalisé. Plus jamais de samsung.
Pour ma part, j'ai acheté une Philips Ambilight car j'adore le concept lumineux. L'autre jour j'ai eu une mise à jour … de ma télécommande. Va vraiment falloir qu'on m'explique comment on a pu en arriver là.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Cargo.lock affligeant
Posté par David Demelier (site web personnel) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 4.
Non les modules C++ sont juste une alternative saine aux
#include.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Cargo.lock affligeant
Posté par David Demelier (site web personnel) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 1.
Tu n'as pas à tout faire à la main
D'ailleurs le plus simple c'est de chercher dans les projets “awesome”.
Pour C, pour C++.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Cargo.lock affligeant
Posté par David Demelier (site web personnel) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 10.
Ça change rien, je viens d'essayer en local et ça a téléchargé 92 dépendances. C'est plus que le nombre de paquet total de mon image minimale de alpine.
Toujours pas d'accord. Boost c'est un framework bloat, il y a certes beaucoup de modules mais la plupart sont indépendants. Mais tu prends un mauvais exemple.
Personnellement quand je développe en C ou en C++, j'ai jamais eu à utiliser une lib externe pour faire des trucs aussi basique que générer un nombre positif dans une plage précise.
Dans mon application actuelle voilà mes dépendances :
Je comprends pas l'intérêt de faire une bibliothèque (comprendre paquet cargo) pour une ou deux fonctions.
Ça n'a absolument rien à voir avec le langage. Tu peux faire du full statique en C si ça te chante. Les 3/4 des bibliothèques sont fournies en statique et comme le linker est intelligent il inclue aussi que le nécessaire (à condition que la bibliothèque soit pas amalgamée).
git is great because linus did it, mercurial is better because he didn't
# Cargo.lock affligeant
Posté par David Demelier (site web personnel) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 8.
Quand je vois le Cargo.lock du projet je suis content de toujours développer en C et C++ et ne pas faire parti du nouvel npm.
git is great because linus did it, mercurial is better because he didn't
# Et renommage du fichier par défaut
Posté par David Demelier (site web personnel) . En réponse au lien Linux Preparing To Finally Remove Support For The a.out Format. Évalué à 3.
On fait du ELF depuis des lustres mais on continue d'appeler l'exécutable par défaut
a.out. J'aimerais bien que ça sorte le nom du fichier sans son extension.git is great because linus did it, mercurial is better because he didn't
# SPOF
Posté par David Demelier (site web personnel) . En réponse au lien Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps. Évalué à 0.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Alpine
Posté par David Demelier (site web personnel) . En réponse au message Quelle est votre distribution linux préférée ?. Évalué à 6.
Non alpine est utilisable en desktop aussi, il y a même GNOME et KDE !
Évidemment il reste toujours des paquets pas forcément compatible ou manquant mais comme c'est super simple d'en rajouter ça va vite. D'ailleurs je suis la raison pour laquelle il y a beaucoup de jeux et d'émulateurs ;o)
git is great because linus did it, mercurial is better because he didn't
# Alpine
Posté par David Demelier (site web personnel) . En réponse au message Quelle est votre distribution linux préférée ?. Évalué à 5.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: SCM public ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche Greycess Knight RPG : sortie de la première version !. Évalué à 10.
C'est mignon tout plein mais; c'est pas parce qu'une personne n'utilise pas GitHub ou tout autre forge qu'il va y avoir un impact écologique. Pour que le torrent marche, il faut que les gens laissent leur PC allumés et laissent le partage actif, est-ce réellement mieux ?
Mis à part le côté partage, je souligne surtout le fait que développer quelque chose d'opensource sans la possibilité de contribuer facilement c'est légèrement contradictoire.
Les projets mednafen et lua sont opensource mais avec un développement fermés et c'est bien dommage. Pour envoyer un patch, tu sais pas si tu es sur la dernière version ou non (en ayant téléchargé une version snapshot) donc si ça se trouve ton patch est plus obsolète.
Il n'y pas que la convivialité de voir le code en ligne et de ne pas attendre un temps variable de torrent, il y a la faculté de pouvoir cloner, mettre à jour, voir l'historique, créer des patch Mercurial ou git, etc. Surtout pour un projet qui est encore en travaux.
git is great because linus did it, mercurial is better because he didn't
# SCM public ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche Greycess Knight RPG : sortie de la première version !. Évalué à 8.
Une raison particulière de pas héberger le code sous un SCM public comme Mercurial ou git ?
Je n'arrive pas à le compiler sous mac car il y a des erreurs dans le CMake, j'aurais bien voulu envoyer un patch mais du coup j'ai aucune idée comment faire. Je n'ai trouvé aucune adresse mail dans le dépôt.
git is great because linus did it, mercurial is better because he didn't
# Entièrement d'accord
Posté par David Demelier (site web personnel) . En réponse au lien L'heure de la retraite pour les images ISO des distributions ?. Évalué à 10.
Tout d'abord parce qu'aucun laptop n'a de lecteur optique. Mais se limiter à 700Mo pour les galettes est contraignant.
Pour ma part je suis partisant des archive minirootfs. C'est ce qu'il y a de plus flexible : on partitionne le disque comme on veut, on monte et un simple
tar -xpfet le tour est joué.J'ai réduit drastiquement l'installation de nos appliances en flashant nos cartes SD avec Alpine et son minirootfs plutôt que de copier une image fixe de 2Go de raspberry pi os.
git is great because linus did it, mercurial is better because he didn't
# Le choix est simple
Posté par David Demelier (site web personnel) . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 0.
Tout sauf Go.
Plus détaillé :
En fait il y a trop de raisons, j'y suis encore jusqu'à midi. Je vous laisse chercher.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: facile ;)
Posté par David Demelier (site web personnel) . En réponse au message [Achète] Raspberry pi 4. Évalué à 5. Dernière modification le 09 décembre 2021 à 08:42.
Non, car nous en utilisons entre 1 et 10 par semaine. Tu continues de parler^Wjuger sans savoir :-)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: cohérence
Posté par David Demelier (site web personnel) . En réponse au message [Achète] Raspberry pi 4. Évalué à 8.
Le boitier flirc est génial et refroidit mieux qu'un ventilateur (si, j'ai testé, impressionnant).
Pour faire de la bureautique, navré de te décevoir mais tu risques d'être très frustré. C'est lent. Tout est lent. Ouvrir une page internet requiert de la patience et même si on promet du décodage 4k crois moi que ça marche pas avec tout.
J'ai aussi essayé de la visio, ça sature et c'était complètement inutilisable. Du coup mes Pi restent ceux pour quoi elles sont bien faites : du headless.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: facile ;)
Posté par David Demelier (site web personnel) . En réponse au message [Achète] Raspberry pi 4. Évalué à 3. Dernière modification le 08 décembre 2021 à 08:55.
LOL.
Faudrait réflechir avant de répondre.
Au travail c'est notre principal élément pour nos appliance. Heureusement qu'on a prévu la pénurie mondiale, on en a commandé 100 il y a 3 mois. Maintenant les prochaines approvisionnement ne sont pas avant fin janvier 2022. Et les compute module c'est carrément avril.
git is great because linus did it, mercurial is better because he didn't