totof2000 a écrit 2053 commentaires

Lorsque je compare avec des solutions comme esx ou hyperv, la question ne se pose même pas. Le cluster a une vue sur les toutes les vm et les hôtes se les passent lorsqu'un ne répond plus avec un délai de quelques secondes (temps de détection d'offline d'un hôte) et surtout sans perte de données.

Tu constates ça avec le même matériel ?

Normalement il est intégré à ta distribution (en tout cas il l'est pour Ubuntu 22.04). Perso je tenterais une suppression/réinstallation du paquet. Mais le problème ne vient pas forcément de hp-lip enlui-même : il faut peut-pêtre seulement redétecter ton improimante.

D'apres la loi, une contrefaçon est "toute reproduction, représentation ou diffusion, par quelques moyens que ce soit, d'une œuvre de l'esprit en violation des droits de l'auteur" (art. L335-3 du Code de la propriété intellectuelle).

De plus : selon le Code pénal (Article 321-1) :

Le recel est le fait de dissimuler, de détenir ou de transmettre une chose, ou de faire office d'intermédiaire afin de la transmettre, en sachant que cette chose provient d'un crime ou d'un délit.

Constitue également un recel le fait, en connaissance de cause, de bénéficier, par tout moyen, du produit d'un crime ou d'un délit.

L'Etat, prompt à condamner les citoyens qui téléchargent illégalement, mais qui s'asseoit sur la loi lorsqu'il est concerné.

Amusant (façon de parler) pour une IA "juridique"

En regardant ce matin, suite à tous les messages ici, j'ai vu qu'il y avait deux plugins pour ça.

J'ai eu de mauvais retours de Redmine utilisé dans une des boites par ou je suis passé : je ne l'ai pas utilisé personnellement, mais ce qu'on m'en a dit ne donne pas envie.

Il y a bien sûr gitlab en self-hosted (mais un peu gros pour tes besoins), gogs et forjeo. Ils ne font que du git. Il y a aussi RhodeCode community edition - qui lui semble-t-il gere d'autre types de dépots. tout ça c'est en self hosted. Ces outils incluent la gestion de features, taches, etc …. via dashboards. Personnellement j'utilise surtout gitlab en ce moment, je ne peux donc pas juger des autres. Pour gitlab, les fonctionnalités de gestion de projet dans la version gratuite sont basiques, mais suffisantes à mon avis pour ce que tu décris (c'est plus ou moins mon besoin et gitlab me suffit).

Le prix Pulitzer (de la fiction) propose de très nombreux mauvais romans quand même ; c'est très politisé et souvent sans intérêt (et c'est de pire en pire d'ailleurs).

Du dis de manière un peu plus directe ce ue je voulais sous-entendre. En fait ce sont plus les raisons ui font qu'il soit passé à côté qui me font penser qu'il n'est pas si mauvais que ça. Comme tu le dis, c'est très politisé et je pense que le roman doit bousculer les idées du "jury" - et qu'il doit le faire de manière plutôt bonne - qui fait qu'il ne l'ait pas eu.

il est tellement osé, perché, absolument beau et indigeste…qu'on lui a refusé le prix.

Ne l'ayant pas lu, je ne peux le dire, mais en fait ce que tu dis confirme mon intuition. Perso, le fait qu'il n'ait pas eu le prix aurait plus tendance à me le faire lire qu'autre chose.

Si j’implémente la communication entre les 2 threads via des messages IQ, est-ce que vous pensez que ça serait trop complexe  ?

Personnellement j'utiliserais des moyens de communication légers entre threads/processus, et je sortirais l'artillerie XML/XMPP par dessus pour la communication entre machines.

quand je vois qu'il a failli obtenir le Pulitzer pour L’Arc-en-ciel mais le jury a estimé que c'était « illisible », « surécrit » et « obscène »

… déjà s'il a "failli" avoir le Pulitzer poir l'Arc-en-ciel, c'est que c'est pas si mal que ça. Et d'un autre côté je me méfie des gens qui attribuent des bons points à telle ou telle oeuvre : on peut avoir un film, un livre, ou de la musque qui n'obtient pas le prix machintruc parce que le prix en question a ses propres filtres, mais ça n'en fait pas our autant des mauvaises oeuvres. La meilleure chose que tu puisses faire à mon avis c'est de te faire ton propre avis.

… mais pour un jeu, mettre du XMPP ça pourrait être lourd (je pense notamment aux étapes de serialisation/deserialisation XML).

Il ne faut pas oublier que XML, à la base, c'est un format commun pour que des applications qui tournent sur des systèmes avec format incompatibles puissent lire/écrire des docments - ou communiquer ensemble. LA tu es dans la communication inter-thread/inter-processus sur la même machine à priori, donc j'ai l'impression qu'un bon vieux format binaire que les threads et les processus pourront lire (via la même lib) fera l'affaire. Au pire voir s'il n'existe pas un bus local style dbus mais en plus léger qui pourrait faire l'affaire. A moins qu'a terme tu prévois de faire tourner tes processus sur des machines différentes (mais completement différentes en terme d'archi) et dans ce cas XML pourrait être utile..

C'est tout de même assez standard aujourd'hui.

Non, en tout cas pas pour ceux qui ne font que très peu de vidéo (et j'en faiss partie).

Ne pas le connaitre est entendable mais fais partie du standard qu'une description ici n'est pas forcément des plus pertinente

Ce genre de commentaire pédant me donne envie de répondre assez sechement mais je m'abstiendrai par respect des autres utilisateurs.

Je sais, je pourrais (et j'irai certainement ) chercher sur internet ou demander à une IA … mais le journal aurait gagné en lisibilité à employer un terme acccessible au plus grand nombre plutôt que de supposer que tout le monde sait ce que c'est, ou à expliquer le terme dès le début.

D'un autre côté, vu leur taille, est-e qu'il est possible d'avoir un environnement de test qui simule tous les cas possibles et imaginables rencontrés sur un environnement de prod ? Je pense que ça doit être bien diffcicile. Et même si c'est faisable, il faut penser justement à tous ces cas possible et les simuler.

Autrement dit, des tests c'est bien, mais les tests ne sont pas la garantie absolue de ne jamais rencontrer de bugs. On réduit juste la probabilité de les rencontrer.

C'est clair … Puis penser qu'on va savoir maîtriser un BSD quelconque juste parce qu'on ait faire du Linux, et ensuitec conclure que BSD c'est le bordel, c'est un peu présomptueux je trouve. les BSD ont un tas d'avantages par rapport à Linux (notamment le fait que l'on a un ensemble kernel + userland cohérent), mais un de leurs "pont faibles" pour des personnes qui ne le connaissent pas, c'est que c'est moins "user frienly" d'une part, et d'autre part, beaucoup d'outils fait pour Linux ne tournent pas (ou mal) sous les xBSD : ce n'est pas la faute à BSD, c'est juste que les devs/éditeurs ne veulent plus faire de portable (on ralait de la même façon il y a 15-20 ans sur les softs Windows Only qui ne tournaient pas sous Linux).

On passe de protocoles standardisé (imap, etc … ) a des trucs specifiques au fournisseur de services. JE suis le seul que ça inquiete ?

Bof …. Quand on se pose pas de question par rapport à l'usage qu'on fait de sa machine avant d'installer un système, on en arrive là.

Pour ma part je prévois toujours d'installer FreeBSD sur mon PC portable (il faut que j'achete un ssd et que je prenne le temps de réorganiser mes données ), mais je garderai un Linux pour le jeu (steam) parce que je sais très bien qu'à la base FreeBSD ne le permet pas, même s'il existe un port pour ça.

Le titre devrait être plutôt "FreeBSD comme alternative au chaos Linux pour remplacer Windows"

Dans le fait qu'une grosse lib, a plus de chances d'avoir des bugs que plusieurs petites lib, et est plus chiant à maintenir, est-ce que ça un rapport avec les attaques par supply-chaines ? toujours pas.

Il y a quand même un petit avantage a avoir une lib qui fait beaucoup plutot que plusieurs petites libs qui font des petites choses : la confiance. Il est plus facile de faire confiance à une lib qui est maintenu par une équipe identifiée, même si cette lib fait plein de choses, que de faire confiance à un tas de petites libs éparpillées non ?

Si tu recodes coreutils, qui globalement n'est pas fait pour être utilisé en réseaux, et où la majorité des failles mémoire aussi graves soit elles seront difficilement exploitables, recoder en Rust pour de la sécurité, reste questionnable.

Bof .. Une elevation de privilege du à une erreur dez gestion de mémoire … c'est pas anodin non plus.

Et si on assume que Rust est plus vulnérable au supply-chain attaque, alors ça reste plutôt négatif en terme d'impact sécuritaire.

C'est là ou moi (et d'autres) ne sommes pas d'accord. Dans l'absolu Rust n'est pas plus vulnérables au supply chain attack que n'importe quelle autre langage. LA différence avec C c'est que Rust est plus ancien, et qu'on a pas encore un ecosysteme de libs matures permettant de faire aussi bien que C en terme d'attaque par supply chain. C'est de mon point de vue la seule différence aujourd'hui (mais je peux me tromper).

Bof …

En C t'a souvent des libs à tout faire, et rien que SDL, t'a des htable, des threads, une gestion du filesystem.

Nul doute qu'avec l'essor de Rust on en vienne à avoir ce même genre de lib à tout faire.

Tu peux rajouter des lib métier comme FFMpeg, json-c ou 2/3 autres.
Mais tu dépasses rarement la 10éne de libs.

Bof … pas convaincu : tu as une dizaine de lib directe mais des dépendances indirectes t'en a aussi. J'ai bien souvent été surpris des trucs qu'installait un apt-get pour un simple utilitaire en ligne de commande.

En fait, mis à part le fait que d'un côté il y a des tas de libs à tout faire qu'il n'y aap as de l'autre, je ne vois pas de grande différence entre les deux mondes : il y a des dépendances, et il est nécessaire de chaque côté d'e s'assurer que les dépendances utilisées soient fiables. Ensuite on se retrouve à gérer d'un côté des dépendances basées sur des libs dynamiques, et de l'autre des dépendances sur des libs statiques. L'un n'est pas mieux que l'autre.

À un moment donné faut arrêter de considérer la gestion mémoire comme le problème principal des failles de sécurité

A un moment donné il faut arrêter de prendre les gens de haut juste pour se la ramener et cesser de faire dire aux gens ce qu'ils n'ont pas dit. Ou ai-je dit que la gestion mémoire est le problème principal des failles de sécurité  ?

Oui c'en est une mais on peut faire des conneries dans tous les langages.

Oui mais si le compilo t'évite d'en faire ou te le signale c'est quand même un plus non négligeable. D'autant plus que la gestion mémoire n'est peut-être pas la cause principale des failles de sécurité (comme le démontre la faille de sudo-rs), mais ça reste quand même une grosse source de failles de sécu (30% => environs 1/3 c'est pas négligeable).

De plus ma question tient justement compte du fait que les failles de sécu ne sont pas la seule problématique lié à la sécurité et le fait de ne pas avoir tout à réécrire pourrait justement permettre de corriger ces problèmes sans pour autant en introduire de nouveaux (ou limiter l'introduction de nouveaux problèmes) en limitant la réécriture du code au strict nécessaire.

Le C n'évoluera jamais dans le sens de Rust parce que c'est un paradigme entier à revoir.

C'est justement pour avoir ce genre d'avis que je pose la question : la réponse aurait pu être donnée sans condescendance.

En revanche, les sanitizers et analyse syntaxique aident déjà énormément au développement et le reste est bien sûr d'assurer des tests de non regression massive.

Si c'était suffisant, on n'aurait pas 30% de problèmes de sécurité liés à la gestion mémoire, icrosoft ne s'intéresserait pas à Rust, et d'ailleurs Rust n'aurait pas pris. Si les devs s'intéressent à Rust c'est justement parce qu'il répond à un besoin.

Est-ce qu'il serait possiblede faire évoluer le C pour qu'il integre un système de contrôle de mémoire "à la rust", tout en gardant une certaine compatibilité avec le code actuellement écrit ? Est-ce qu'il y a des discussions/recherches/évolutions potentielles dans ce sens ? Est-ce que ça vaudrait le coup ?

Disons que …. même si c'est gênant, le jour ou Donald Trump décidera d'interdire l'accès aux services numériques américains d'une association qui le dérange

J'ai omis un élément dans ma phrase (un ctrl+z de trop quand j'ai voulu reformuler) :

Disons que …. même si c'est gênant, le jour ou Donald Trump décidera d'interdire l'accès aux services numériques américains d'une association ou d'une petite entreprise qui le dérange

Et pour Systemd, les gens qui disent ça sont toujours des gens qui ne l'utilisent pas vraiment. Parce que comparer systemd-timesyncd avec ntpd, ça prouve juste que tu n'as rien compris.

Oui c'est ça … je n'utilise pas systemd. J'aimerais bien ne pas l'utiliser justement. Au minimum j'aimerais bien virer les trucs qui entrent en conflit avec des alternatives qui me plaisent mieux et qui sont bien souvent plus completes : mais je ne peux pas, et c'est surtout ça qui me gène.

Disons que …. même si c'est gênant, le jour ou Donald Trump décidera d'interdire l'accès aux services numériques américains d'une association qui le dérange, l'impact sera moins important que s'il interdit l'accès aux organismes d'état, banques, telecom ou autres grosses entreprises sensibles du genre. Et il est capable de faire ce genre de choses pour tout un pays. Après dans le monde associatif il y a quand même des associations qu'on pourrait qualifier de "sensibles" telles que celles qui soccupent des tutelles ou des curatelles : ça pourrait gêner pas mal de monde.

Les entreprises ou administrations françaises continuent à pousser leurs données vers les fournisseurs clouds américains …