Par contre ça a quelques inconvénients, comme par exemple le fait de devoir rentrer le mot de passe à chaque boot. On n'a pas trop de détails sur l'installation, mais si c'est un truc autonome, ça peut être compliqué à mettre en œuvre (apporter un écran et un clavier juste pour le boot).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je connaissais pas ce truc. Si c'est avéré (toujours croiser les sources, même d'un média sérieux !), c'est tout simplement honteux.
L'article parle qu'on le voit particulièrement pour les votes d'articles controversés, ce serait intéressant d'en retrouver un qui, après ces corrections, n'était même pas censé passer (ce qui montrerait définitivement l'abus).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Oui, de mon temps c'était Gentoo qui était la référence sur laquelle on finissait systématiquement quand on cherchait de la doc. Ils ont eu un gros soucis et ont tout perdu (je crois).
Heureusement celle de Arch est au moins du même niveau.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Du coup oui, si tu as beaucoup de temps, et que tu es vraiment bon pour pondre le design idéal à chaque fois, coder en C est plus efficient oui
On est d'accord, je ne dis rien d'autre que ça. J'ai dis à plusieurs reprises que l'inconvénient du C est que pour accéder à l'optimisation, il faut un bon niveau, une bonne connaissance du hardware etc.
C'est d'ailleurs pour ça qu'il est assez régulier de voir un programme codé en langage XYZ, puis une petite routine qui est critique niveau temps d'exécution codée en C (et aussi en ASM, ça se voit encore) pour être parfaitement optimisée (et appelée souvent etc.)
Mais je ne comprends pas les arguments qui tendent à dire qu'un langage quelconque, avec une fonctionnalité quelconque (JIT, ramasse miette, …) pourrait être foncièrement plus rapide que le C, car au pire, tu implémentes cette fonction si astucieuse en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Oui et l'assembleur aura des performances encore meilleures, pour la même raison (mais il est pas dans la liste :) ).
Le C étant considéré comme un "assembleur portable", il y a très peu de surcoût au C. C'est l'avantage du C, mais aussi son inconvénient (pour être performant, il faut coder en connaissant le hardware).
Mais je ne vois toujours pas d'exemple où un code bien écrit en C est moins performant qu'un code bien écrit en C++/Java/Python.
un superbe example que c'est faux, c'est la différence de performance entre qsort et std::sort
Bin je comprends pas trop, le mec trouve justement que le C est plus performant :
C quick-sort time elapsed: 0.061
C++ quick-sort time elapsed: 0.086
Et après ça parle de "inline". Si c'est ça la raison, il suffit de l'ajouter dans son code source C. Dis autrement, je ne vois pas ce que le C++ pourrait faire que le C ne fait pas. Il n'y a pas d'instructions assembleur magique qui sortiront en C++ et pas en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Il se pourrait qu'un langage qui ne prenne pas en charge les pointeurs mais qui utilise les références (et un ramasse-miettes) batte C dans certains cas simplement parce que la gestion de la mémoire peut être plus efficace
Bin non. Le ramasse miette est là pour palier aux manquements du codeur, pas du langage. Il rajoute justement une gestion supplémentaire qui est moins efficace (puisque parfois il va déterminer qu'il ne faut rien libérer, il a donc tourné pour rien) pour que le codeur n'ait pas à penser "où dois-je allouer, ai-je bien penser à libérer" ? Mais c'est pas une optimisation de performances du tout.
Une compilation à la volée peut également permettre d'appliquer certaines optimisations, potentiellement dépendantes des données à l'exécution
Là je voudrais un exemple concret parce que réellement je vois pas. La compilation à la volée qui a un comportement dynamique… quel langage l'implémente ? Et surtout je veux un benchmark, parce que compiler à la volée, ça coûte.
Une compilation à la volée peut aussi prendre en compte les spécificités matérielles (architecture CPU spécifique par exemple), là où les programmes C sont souvent compilés pour un grand ensemble de machines.
Là aussi c'est un argument fallacieux : tu compares un truc mal fait en C avec un truc potentiellement mieux fait dans un autre langage, sans au final apporter un vrai benchmark ni un vrai exemple. On parle du langage lui-même, pas de la façon de l'utiliser.
Et si tu objectes que le C est plus difficile à optimiser, c'est exactement mon commentaire du début : pour optimiser du C, c'est à l'humain de se décarcasser, mais au final, c'est plus efficace.
Il faut bien comprendre ce qu'est le C : une simple surcouche de l'assembleur. Tous les concepts du C sont directement implémentés par le silicium. Les langages évolués apportent des concepts énormément plus pratiques (objet par exemple) pour le codeur, mais pas pour la machine.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Mais dans le cas d'un gros programme de plusieurs centaines de milliers de lignes, est-ce qu'il est toujours aussi performant ?
Oui.
Le C est tellement proche de l'implémentation machine qu'il sera toujours plus performant.
Par contre, un gros programme de 100k lignes de codes en C ne fera que 10k lignes de code en Python (exemple pris au hasard dans la liste), sera plus facilement maintenable, sera plus facile à écrire etc. Mais moins efficace sur la machine.
Pas de secret, soit l'humain se fait chier, et ça optimise (assembleur powa) soit il se fait moins chier, et tu crées des exécutables lourds et lents.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je ne suis pas certain d'avoir compris ton besoin exactement, mais je me lance.
De ce que je comprends, il me semble que ton but est de copier des fichiers à distance sur ton NAS. C'est clairement le domaine de scp.
rsync est là pour synchroniser des répertoires à distance, et typiquement des répertoires bien gros, où peu de données changent : sa force est de ne copier que ce qui est nécessaire.
Là il semble que de toutes façons tes fichiers seront différents chaque jour, et donc rsync devra chaque jour, de manière sûre et certaine recopier 6x2 fichiers. Autant utiliser scp.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
C'est justement un soucis supplémentaire si on n'accepte de lire que des articles qui nous plaisent
Clairement. Et la frénésie actuelle autour de l'IA (qui propose des lectures en fonctions des lectures passées, donc grosso-modo qui fige le passé pour en faire un futur) ne promet rien de bon sur ce sujet :(
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
bizarrement, tu ne parles pas de média "libres" pas compatibles avec tes idées politiques
A sa décharge, c'est statistiquement plus probable qu'il ne connaisse que les soucis des médias de son bord politique : pour savoir qu'un média X a été muselé, encore faut-il aller le lire.
Par exemple, les déboires de la presse spécialisée dans l'élevage des mouches drosophiles en Franche-Comté m'échappe totalement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Très intéressant la question préjudicielle de constitutionnalité. Je conseille à tout le monde de lire le lien de Zenitram, c'est facile à comprendre.
TLDR: tu dois donner les clés de déchiffrement aux autorités (c'est la loi), ce n'est clairement pas en opposition à ton droit au silence ni à la présomption d'innocence (c'est la constitution).
Donc pour résumer : tu donnes les clés, et tu te tais.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Le plus honnêtement du monde, je ne vois pas pourquoi ne pas utiliser Firefox en fait. Certes je suis rarement allé voir ailleurs, mais c'est justement parce que Firefox répond à tous mes besoins, admirablement bien (perfos, stabilité etc.)
C'est quoi qu'on lui reproche généralement ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
J'exagère à peine, mais du moment que tu prends une bonne marque (Samsung, Sandisk, Kingston…) tu seras pas déçu, ils explosent tous ton vieux disque mécanique.
Si tu réagis vite, il y a en ce moment même une grosse promo sur les Kingston sur Amazon : 15€ le 120Go, 30€ le 240Go et 60€ le 480Go.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Est-ce que c'est même possible de mettre en place une cryptomonnaie écologique?
Alors c'est pas (du tout) ma spécialité mais j'en ai vu passer une qui justement ne demande pas de preuve de travail. La contribution au réseau est rétribuée, mais c'est pas basé sur la force de calcul, justement sur le constat catastrophique du Bitcoin qui est une course aux Watts.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Petits arrangements entre amis
Posté par gUI (Mastodon) . En réponse au journal [HS] Félonie au parlement européen. Évalué à 3.
Et à cette époque la France était déjà loin devant :(
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Disque chiffré ?
Posté par gUI (Mastodon) . En réponse au message Type de Raspberry Pi "non lisible" ?. Évalué à 4.
Oui c'est exactement à quoi ça sert.
Par contre ça a quelques inconvénients, comme par exemple le fait de devoir rentrer le mot de passe à chaque boot. On n'a pas trop de détails sur l'installation, mais si c'est un truc autonome, ça peut être compliqué à mettre en œuvre (apporter un écran et un clavier juste pour le boot).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Petits arrangements entre amis
Posté par gUI (Mastodon) . En réponse au journal [HS] Félonie au parlement européen. Évalué à 8. Dernière modification le 28 mars 2019 à 09:08.
Je connaissais pas ce truc. Si c'est avéré (toujours croiser les sources, même d'un média sérieux !), c'est tout simplement honteux.
L'article parle qu'on le voit particulièrement pour les votes d'articles controversés, ce serait intéressant d'en retrouver un qui, après ces corrections, n'était même pas censé passer (ce qui montrerait définitivement l'abus).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Wiki ArchLinux
Posté par gUI (Mastodon) . En réponse au journal Un irssi (ou autre chose) dans un tmux sur un serveur, avec systemd. Évalué à 6.
Oui, de mon temps c'était Gentoo qui était la référence sur laquelle on finissait systématiquement quand on cherchait de la doc. Ils ont eu un gros soucis et ont tout perdu (je crois).
Heureusement celle de Arch est au moins du même niveau.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . En réponse au lien Faites du C pour sauver la planète!. Évalué à 2. Dernière modification le 27 mars 2019 à 13:45.
On est d'accord, je ne dis rien d'autre que ça. J'ai dis à plusieurs reprises que l'inconvénient du C est que pour accéder à l'optimisation, il faut un bon niveau, une bonne connaissance du hardware etc.
C'est d'ailleurs pour ça qu'il est assez régulier de voir un programme codé en langage XYZ, puis une petite routine qui est critique niveau temps d'exécution codée en C (et aussi en ASM, ça se voit encore) pour être parfaitement optimisée (et appelée souvent etc.)
Mais je ne comprends pas les arguments qui tendent à dire qu'un langage quelconque, avec une fonctionnalité quelconque (JIT, ramasse miette, …) pourrait être foncièrement plus rapide que le C, car au pire, tu implémentes cette fonction si astucieuse en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . En réponse au lien Faites du C pour sauver la planète!. Évalué à 3. Dernière modification le 27 mars 2019 à 12:02.
Oui et l'assembleur aura des performances encore meilleures, pour la même raison (mais il est pas dans la liste :) ).
Le C étant considéré comme un "assembleur portable", il y a très peu de surcoût au C. C'est l'avantage du C, mais aussi son inconvénient (pour être performant, il faut coder en connaissant le hardware).
Mais je ne vois toujours pas d'exemple où un code bien écrit en C est moins performant qu'un code bien écrit en C++/Java/Python.
Bin je comprends pas trop, le mec trouve justement que le C est plus performant :
Et après ça parle de "inline". Si c'est ça la raison, il suffit de l'ajouter dans son code source C. Dis autrement, je ne vois pas ce que le C++ pourrait faire que le C ne fait pas. Il n'y a pas d'instructions assembleur magique qui sortiront en C++ et pas en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . En réponse au lien Faites du C pour sauver la planète!. Évalué à 3.
Tu as raison. J'attends donc avec impatience de voir un seul gros projet qui annonce avoir quitté une implémentation en C pour des raisons de perfo.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . En réponse au lien Faites du C pour sauver la planète!. Évalué à 7.
Bin non. Le ramasse miette est là pour palier aux manquements du codeur, pas du langage. Il rajoute justement une gestion supplémentaire qui est moins efficace (puisque parfois il va déterminer qu'il ne faut rien libérer, il a donc tourné pour rien) pour que le codeur n'ait pas à penser "où dois-je allouer, ai-je bien penser à libérer" ? Mais c'est pas une optimisation de performances du tout.
Là je voudrais un exemple concret parce que réellement je vois pas. La compilation à la volée qui a un comportement dynamique… quel langage l'implémente ? Et surtout je veux un benchmark, parce que compiler à la volée, ça coûte.
Là aussi c'est un argument fallacieux : tu compares un truc mal fait en C avec un truc potentiellement mieux fait dans un autre langage, sans au final apporter un vrai benchmark ni un vrai exemple. On parle du langage lui-même, pas de la façon de l'utiliser.
Et si tu objectes que le C est plus difficile à optimiser, c'est exactement mon commentaire du début : pour optimiser du C, c'est à l'humain de se décarcasser, mais au final, c'est plus efficace.
Il faut bien comprendre ce qu'est le C : une simple surcouche de l'assembleur. Tous les concepts du C sont directement implémentés par le silicium. Les langages évolués apportent des concepts énormément plus pratiques (objet par exemple) pour le codeur, mais pas pour la machine.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . En réponse au lien Faites du C pour sauver la planète!. Évalué à 3.
Oui.
Le C est tellement proche de l'implémentation machine qu'il sera toujours plus performant.
Par contre, un gros programme de 100k lignes de codes en C ne fera que 10k lignes de code en Python (exemple pris au hasard dans la liste), sera plus facilement maintenable, sera plus facile à écrire etc. Mais moins efficace sur la machine.
Pas de secret, soit l'humain se fait chier, et ça optimise (assembleur powa) soit il se fait moins chier, et tu crées des exécutables lourds et lents.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# rsync est-il le bon outil ?
Posté par gUI (Mastodon) . En réponse au message Rsync : Changer le nom du fichier au passage. Évalué à 6.
Bonjour,
Je ne suis pas certain d'avoir compris ton besoin exactement, mais je me lance.
De ce que je comprends, il me semble que ton but est de copier des fichiers à distance sur ton NAS. C'est clairement le domaine de
scp.rsyncest là pour synchroniser des répertoires à distance, et typiquement des répertoires bien gros, où peu de données changent : sa force est de ne copier que ce qui est nécessaire.Là il semble que de toutes façons tes fichiers seront différents chaque jour, et donc
rsyncdevra chaque jour, de manière sûre et certaine recopier 6x2 fichiers. Autant utiliserscp.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Vivent les plateformes qui assument
Posté par gUI (Mastodon) . En réponse au journal Liberté de la presse et chiffrage : Lundi.am, le parquet ouvre une .... Évalué à 7.
Clairement. Et la frénésie actuelle autour de l'IA (qui propose des lectures en fonctions des lectures passées, donc grosso-modo qui fige le passé pour en faire un futur) ne promet rien de bon sur ce sujet :(
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Vivent les plateformes qui assument
Posté par gUI (Mastodon) . En réponse au journal Liberté de la presse et chiffrage : Lundi.am, le parquet ouvre une .... Évalué à 8.
A sa décharge, c'est statistiquement plus probable qu'il ne connaisse que les soucis des médias de son bord politique : pour savoir qu'un média X a été muselé, encore faut-il aller le lire.
Par exemple, les déboires de la presse spécialisée dans l'élevage des mouches drosophiles en Franche-Comté m'échappe totalement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Rien compris
Posté par gUI (Mastodon) . En réponse au journal Liberté de la presse et chiffrage : Lundi.am, le parquet ouvre une .... Évalué à 5.
Très intéressant la question préjudicielle de constitutionnalité. Je conseille à tout le monde de lire le lien de Zenitram, c'est facile à comprendre.
TLDR: tu dois donner les clés de déchiffrement aux autorités (c'est la loi), ce n'est clairement pas en opposition à ton droit au silence ni à la présomption d'innocence (c'est la constitution).
Donc pour résumer : tu donnes les clés, et tu te tais.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Choix facile
Posté par gUI (Mastodon) . En réponse au journal Navigateur web, l'impossible choix. Évalué à 4.
C'est pas mon domaine, mais de loin comme ça, ça me fait penser à Matlab… c'est comparable ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Firefox
Posté par gUI (Mastodon) . En réponse au journal Navigateur web, l'impossible choix. Évalué à 10.
Le plus honnêtement du monde, je ne vois pas pourquoi ne pas utiliser Firefox en fait. Certes je suis rarement allé voir ailleurs, mais c'est justement parce que Firefox répond à tous mes besoins, admirablement bien (perfos, stabilité etc.)
C'est quoi qu'on lui reproche généralement ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# N'importe lequel
Posté par gUI (Mastodon) . En réponse au message Petit Disque SSD . Évalué à 0.
J'exagère à peine, mais du moment que tu prends une bonne marque (Samsung, Sandisk, Kingston…) tu seras pas déçu, ils explosent tous ton vieux disque mécanique.
Si tu réagis vite, il y a en ce moment même une grosse promo sur les Kingston sur Amazon : 15€ le 120Go, 30€ le 240Go et 60€ le 480Go.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Grands mots
Posté par gUI (Mastodon) . En réponse au journal L'Allemagne veut criminaliser l'hébergement d'un nœud TOR. Évalué à 10. Dernière modification le 21 mars 2019 à 18:02.
Il y en a qui devraient lire "Les Vieux Fourneaux" : il n'y a pas d'âge pour être révolutionnaire !!!
#niyeuxnimaitre
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Mmmm...
Posté par gUI (Mastodon) . En réponse au message Fermeture du compte. Évalué à 3.
Non, pas que je sache.
SamWang ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: unifying
Posté par gUI (Mastodon) . En réponse au message Clavier sans fil compatible linux. Évalué à 3. Dernière modification le 21 mars 2019 à 09:19.
Idem. Depuis cette anecdote je fous du Logitech partout sur mes Linux, et le système Unifying marche à merveille.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: unifying
Posté par gUI (Mastodon) . En réponse au message Clavier sans fil compatible linux. Évalué à 4.
On n'a pas les même notions de vitesse : mes claviers/souris Logitech tiennent plusieurs mois sur des piles rechargeables.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: C'est toujours mieux d'avoir un peu de contexte
Posté par gUI (Mastodon) . En réponse au message Messages d'erreurs incompréhensibles pour moi. Évalué à 6.
Et au passage, on peut préciser que dans
grep, l'option-Cpermet de rajouter les lignes autour (Context) de la ligne cherchée.dmesg | grep error -C 3affichera 3 lignes avant et après chaque ligne contenant "error".En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mais bien-sur !
Posté par gUI (Mastodon) . En réponse au journal Elphyrecoin : la cryptomonnaie au service de l'opensource. Évalué à 10.
Même pour le logo il s'est pas fait chier :
- https://myusedlighter.com/fr/
- https://economyvapes.com/products/vaporesso-gt4-gt8-3pcs-pack-core-coil-for-nrg-tank-and-revenger-kit
- https://www.derkerzenshop.ch/blog/
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Consommation électrique
Posté par gUI (Mastodon) . En réponse au journal Elphyrecoin : la cryptomonnaie au service de l'opensource. Évalué à 3.
Alors c'est pas (du tout) ma spécialité mais j'en ai vu passer une qui justement ne demande pas de preuve de travail. La contribution au réseau est rétribuée, mais c'est pas basé sur la force de calcul, justement sur le constat catastrophique du Bitcoin qui est une course aux Watts.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Je ne sais rien, mais je dirai tout
Posté par gUI (Mastodon) . En réponse au message Interface graphique pour borne (type distributeur de billets, etc). Évalué à 4. Dernière modification le 19 mars 2019 à 14:06.
Dans ce domaine, Qt est souvent cité.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Source?
Posté par gUI (Mastodon) . En réponse au journal Les éditions Diamond passent au numérique GAFAM. Évalué à 10.
Oui je suis aussi étonné.
Ils demandent donc l'exclusivité ? Et qui demande ça ? Apple ? Alors pourquoi c'est aussi disponible chez Google (et vice-versa) ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.