Re: [gull] Bash get stat simulteneously on many hosts

[Daniel Cordey via gull]

On 31/5/24 21:45, felix via gull wrote:

N'hésitez pas à commenter, c'est un peu mort, par ici et il fait
un temps de chiotte dehors...


Oui, intéressant, mais je suis plutôt à utiliser les APIs des 
différentes solutions de monitoring é distance. En général tu installes 
un "agent" localement et tu l'interroges et peux récupérer des données 
facilement. Ces "agents" sont souvent très complets et versatiles ; en 
plus d'être simples à exécuter. Tu pourrais adapter ton script pour les 
utiliser et étendre la couverture des données traitées ; le gros du 
travail ayant déjà été fait du côté des "agents".


Quand aux chiottes, je les ai mises dans une pièce à l'intérieur... je 
trouve plus pratique :-)


dc___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] 3 liens

[Daniel Cordey via gull]

Hola,

On 9/5/24 19:52, Philippe Strauss via gull wrote:


Build a Debian DEB File From Your Project’s Source - The New Stack:

https://thenewstack.io/build-a-debian-deb-file-from-your-projects-source/


Et pour ceux qui veulent créer un fichier DEB à partir de leur code 
Python, il y a stdeb :


https://pypi.org/project/stdeb/

dc___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Requêtes SQL en LIKE ...% avec psycopg3

[Daniel Cordey via gull]

Pour compléter ce qu'a dit Marc, je dirais qu'il faudrait :

- Utiliser f-string dans la mesure du possible (je ne sais pas si flask 
est en Python3)


- Détecter toute présence des caractères  ';' et '%' dans les entrées et 
annuler toute la requête


Comme protection ultime, et lorsque les requêtes sont complexes, j'ai 
utilisé systématiquement PLY/SLY (Lex & Yacc pour Python) pour filtrer 
mes "entrées". Si les requêtes contiennent des dates, combinées avec des 
mots et des fréquences (par exemple). Un analyseur à base de 
lexique/grammaire est indispensable et surtout le seul moyen sûr et 
efficace de filtrer les entrées. Le filtrage à l'aide de regexp() ne 
peut être sûr que dans des cas extrêmement simples (mais c'est très rare 
finalement).


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Linux,Le support long terme au noyau Linux passe à 2 ans

[Daniel Cordey via gull]

Le 10/3/24 à 14:34, Yves Martin via gull a écrit :

J'ai adoré la qualité de Debian et les mises à jour quasiment
parfaites
et cohérentes pendant plus de 20 ans, mais peut-être, effectivement,
que
ce modèle va s'éteindre.

Sincèrement, je ne crois pas.
Car container ou pas, il faudra toujours un système "hôte" pour tourner
le moteur de container quel qu'il soit (on commence à en avoir un
certain nombre) et la qualité Debian est un grand plus dans ce
contexte.


Non, je ne pense pas non plus que le modèle Debian va s'éteindre, mais, 
à mon humble avis, il va subsister, mais de manière beaucoup plus 
discrète que jusqu'à aujourd'hui. Le monde évolue et les web apps 
prennent de plus en plus d'importance (pour de multiples raisons). Donc, 
il va y avoir un besoin massif de services non-stop, etc. Le concept de 
"server" est gentiment remplacé par celui de "service". Or, un service 
doit être mobile et résilient, et les technologies qui permettent de le 
gérer facilement dépassent la simple notion du "server". C'est un fait 
qui correspond à la demande et qui se généralise sans grands effets 
d'annonce. Tout ceci se fait tranquillement, car on ne change pas une 
architecture IT comme ça du jour au lendemain. Debian, c'était très bien 
et c'est toujours très bien, mais ça ne suffit plus.J'ai toujours été 
gêné par le cycle des release de Debian que je trouve trop lent pour de 
multiples raisons; et je me refuse à jouer aux équilibristes en 
bricolant entre "stable" et "testing".



De plus, une image de container n'est quasiment jamais construit "ex-
nihilo" même quand il s'agit de tourner un service compilé en Go (qui
sur le principe n'a besoin d'aucune bibliothèque partagée d'un système
POSIX classique)


Non, pas d'accord du tout. Docker permet de construire des images de 
manière très facile et en n'incluant que le strict nécessaire. De plus, 
il ne se passe pas une semaine sans que de nouveaux outils gravitants 
autours de Docker et de ses outils associés ne voient le jour. De plus, 
les images ainsi construites peuvent justement avoir n'importe quelle 
distro comme de base de fonctionnement. C'est d'ailleurs l'objectif de 
Docker. La création d'une image simple prend quelques minutes, mais il 
est aussi possible de faire des tas de choses très sophistiquées au 
niveau réseau. file system, etc. L'avantage étant que la réplication 
d'un service ainsi construit peut-être ensuite diffusé sans limites sur 
n'importe quel hôte.



Et les images de container à base de Debian (qui certes dans ce cas
n'inclut pas le kernel Linux, puisque c'est le sujet initial ici)
profitent des bonnes propriétés de la distribution en terme de
modularité des packages et de mises à jour de sécurité.


Précisément, inclure une image complète Debian est "over killing". Il 
est d'ailleurs très rare et d'utiliser une distro complète à intégrer 
dans une image. D'ailleurs, ça n'a pas beaucoup de sens et c'est 
inefficace (place mémoire, temps de démarrage, etc.). On se limite donc 
très souvent à utiliser une base minimum comme Alpine qui ne fait que 5 
MB, et on ajoute ce dont on a besoin. Ceci permet de construire des 
images vraiment petites.



Tout comme l'introduction de la virtualisation a réorganisé certains
aspects des distributions, il en est déjà de même pour la
containerization depuis quelques années.


Oui, mais ça ne s'arrête pas là. On peut utiliser des conteneurs de 
manière manuelle ; ce qui est déjà une bonne étape. Mais pour se 
construire un cluster de serveur Web, DB, etc. on va utiliser des 
technologies comme Kubernetes, qui dépasse largement les domaines 
couverts par Docker et qui justement permet cette fameuse approche CI/CD.


Pendant des années, j'ai suivi les pratiques consistant à faire des MAJ 
le moins souvent possible et à ne pas rebooter mon système, à moins 
d'une absolue nécessité. Mes années de production dans un environnement 
24/7 m'ont fait changer mon fusil d'épaule. Pourquoi ? Pour trois 
raisons principales.


La première est que le cycle 'stable' de Debian était trop lent et ne 
permettait pas d'adopter des technologies dont nous avions besoin pour 
répondre à des demandes croissantes de performances et de capacités. 
Comme une nouvelle fonctionnalité de MariaDB... non supportée par la 
version 'stable'. On peut bricoler avec 'testing', mais alors, je ne 
vois pas pourquoi je n'utiliserais pas directement une distro Ubuntu...? 
Multiplier les bricolages est une stratégie qui n'a aucun sens dans un 
environnement de production intense. La gestion des bricolages finis par 
vous prendre trop de temps et causer des problèmes.


La deuxième raison est liée à la première... Mettre à jour votre système 
tous les 2-3 ans est un bon moyen de vous créer des problèmes... Vous 
utilisez MariaDB, nginx, uwsgi, python2.7, etc. et soudainement, vous 
migrez tous ces sous-systèmes vers de nouvelles versions... Vous partez 
alors pour une semaine d'enfer... Dans un environnement où vos clients 
attendent 

[gull] HP CEO evokes James Bond-style hack via ink cartridges

[Daniel Cordey via gull]

Hola,

Les mecs de HP Inc sont complètement dérangés. Une telle attitude est 
vraiment méprisable. On prend les gens pour des idiots.


https://arstechnica.com/gadgets/2024/01/hp-ceo-blocking-third-party-ink-from-printers-fights-viruses/

Perso, j'ai cessé d'acheter tout matériel HP depuis des années. Cette 
société n'a plus rien à voir avec ce qu'elle était dans les années 80.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Almost all VPNs are vulnerable to traffic-leaking TunnelCrack attacks

[Daniel Cordey via gull]

Pour info :

https://www.helpnetsecurity.com/2023/08/14/vpn-vulnerabilities-tunnelcrack-attacks/

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] AI & Open Source

[Daniel Cordey via gull]

Petit rappel des bénéfices des logiciels libres (Open-Source dans ca 
cas), destiné aux septiques et aux directions des grosses boîtes qui 
prennent leur décision en fonction de leurs partenaires de golf.


https://slate.com/technology/2023/05/ai-regulation-open-source-meta.html

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: sécurité

[Daniel Cordey via gull]

Le 21.05.23 à 09:11, Miçhael Parchet via gull a écrit :

Je trouve ça scandaleux et dégueulasse ce qui révèle Géopolitis moi je 
tiens à ma vie privée. Je ne veux pas être espionné par cette machine


Je crois que, malheureusement, la majorité des gens ne se préoccupent 
pas du tout de cet espionnage et collecte d'information de la part des 
gouvernement et d'entreprises privées. J'ai essayé de sensibiliser mon 
entourage aux dangers de Whatsapp (y compris en entreprise !), mais un 
grand nombre ne veulent pas abandonner. Le pire se sont les artisans 
(plombiers, électriciens, etc.) que l'on ne peut contacter que par 
Whatsapp. J'ai finalement renoncé à faire croisade pour d'autres 
solutions; les gens sont paresseux et pensent que ce n'est pas un 
problème puisqu'ils n'ont rien à se reprocher... Je pense 90% de la 
population.


Même avec ce genre d'information ils ne bronchent pas :

https://en.wikipedia.org/wiki/Tempora

Où pourtant Facebook est clairement mentionné !

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: OpenSIL

[Daniel Cordey via gull]

Le 07.05.23 à 16:21, Marc SCHAEFER via gull a écrit :


Donc, euh, c'est quoi la valeur ajoutée à part de faire la même
chose que Coreboot? [1] :)  Je pose la question honnêtement, car souvent
les annonces des vendeurs sont orientées marketing.


C'est la mise à disposition du firmware utilisé pour l'initialisation du 
CPU/CS/etc. en open-source (Open-Source Firmware). La description 
détaillée est là :


https://www.phoronix.com/news/AMD-openSIL-Open-Source

Et plus de détails concernant le contenu de la librairie est aussi 
publié par phoronix :


https://www.phoronix.com/news/AMD-openSIL-Detailed



D'autant plus que "AMD isn't anticipating it to be production-ready for
another three years, until 2026."


...
While this AMD openSIL effort is very promising, it's not yet considered 
production ready. The post ends with, "AMD openSIL firmware libraries 
and associated host firmware are released as Proof-of-Concept (PoC) code 
for 4th Gen AMD EPYC™ based reference platform. The PoC code is not 
meant for production use yet. The AMD openSIL code is provided ‘as-is’."

...

Marci d'avoir fait cette remarque. J'ai donc approfondi les infos 
initiales et fait j'en sais un peu plus maintenant. C'était donc une 
bonne remarque :-)


Certaines de ces infos ont été publiées au début mars, puis d'autre 
mi-avril et ce n'est que maintenant que la dernière publication de 
phoronix a fait tilt sur mon radar...


A part ça, j'ai eu beau cherché mais je ne sais pas sous quelle licence 
la librairie est publiée.


Les détails ultimes :

https://community.amd.com/t5/business/empowering-the-industry-with-open-system-firmware-amd-opensil/ba-p/599644

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] OpenSIL

[Daniel Cordey via gull]

Good news...

https://www.phoronix.com/news/AMD-openSIL-Presentation

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Sony et la fondation Raspberry Pi forgent une alliance

[Daniel Cordey via gull]

https://www.01net.com/actualites/sony-et-la-fondation-raspberry-pi-forgent-une-alliance.html

⁣Télécharger BlueMail pour Android ​___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Gordon Moore

[Daniel Cordey via gull]

Disparition d'un pionnier et du fondateur d'une entreprise qui a 
révolutionné le monde :


https://www.intel.com/content/www/us/en/newsroom/news/gordon-moore-obituary.html

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Codon

[Daniel Cordey via gull]

Le 20.03.23 à 12:02, Claude Paroz via gull a écrit :

Très intéressant... Mais sous licence Business Source Licence (non 
libre, donc).


https://docs.exaloop.io/codon/general/faq#is-codon-open-source


En effet ! Mais, cela veut dire qu'une entreprise ne peut pas monter un 
site qui compile du code Python contre rémunération (entre autre). Avis 
très personnel : ça ne me  dérange pas dans le sens où ce genre de 
licence est destiné à éviter l'appropriation dans le temps par certaines 
entreprises (suivez mon regard...). De plus :


"Importantly, as per the BSL, each version of Codon converts to an 
actual open source license (specifically, Apache) after 3 years."


Donc, ce n'est pas du free-ware ou truc vraiment non-libre; d'autant que 
c'est exactement la même licence que MariaDB !


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Codon

[Daniel Cordey via gull]

Le 20.03.23 à 11:36, Dominik Madon via gull a écrit :> Oui, très 
intéressant.


Attention cependant: il y a pour l'instant quelques limitations au niveau 
typage (pas forcément un problème sauf peut-être pour la longueur des entiers) 
et au niveau chaîne de caractères (ascii et pas unicode).


Exact, alors que le problème des int_64 peut des fois passer sous le 
radar, celui d'unicode est plus ennuyeux; Surtout que j'ai commencé à 
modifier tous mes codes pour abandonner le modes ASCII :-)


Merci de l'avoir rappeler.

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Docker change un peu les règles

[Daniel Cordey via gull]

Hola,

Aïe... Mais c'est un problème récurrent avec les logiciels libres. 
Quelqu'un doit bien payer pour les infrastructures hébergeant tous les 
projets/images...


https://news.itsfoss.com/docker-dropping-free-team-orgs/

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Codon

[Daniel Cordey via gull]

Hola,

Gros concurrent au niveau performance du code... Bonne nouvelle !

https://docs.exaloop.io/codon

"Codon is a high-performance Python compiler that compiles Python code 
to native machine code without any runtime overhead. Typical speedups 
over Python are on the order of 100x or more, on a single thread. Codon 
supports native multithreading which can lead to speedups many times 
higher still.


The Codon framework is fully modular and extensible, allowing for the 
seamless integration of new modules, compiler optimizations, 
domain-specific languages and so on. We actively develop Codon 
extensions for a number of domains such as bioinformatics and 
quantitative finance."


En prime, il existe un décorateur (@par) qui permet de paralléliser le 
code en mode natif (sans les blocages de Python) :


https://docs.exaloop.io/codon/advanced/parallel


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Ken Thomson

[Daniel Cordey via gull]

Ken Thomson abandonne Apple et choisit Debian...

http://techrights.org/2023/03/15/ken-thompson-transcript-scale/

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] Re: Truc et astuces: nice et ionice (rappel)]

[Daniel Cordey via gull]

Le 05.03.23 à 11:01, Marc SCHAEFER via gull a écrit :


Debian propose un kernel alternative RT depuis au moins 2009, je dirais
-- je l'avais justement utilisé dans un cadre de traitement audio temps
réel, jusqu'à me rendre compte que ce n'était, en fait, pas utile.


Le tempsréel n'est utile et nécessaire que dans de très rares cas et en 
plus c'est parfois assez délicat à utiliser et a paramétrer. En général, 
on a une seule application dédiée qui a besoin de RT. Je ne m'amuserais 
pas à mettre une application ayant besoin de RT avec d'autres services 
comme un serveur de DB ou du style. Ca implique aussi très souvent des 
I7O, donc des drivers qui doivent être adapté. Dans l'audio... c'est 
compliqué car il y a plein de process/daemon qui se parlent entre eux, 
sans compter les changements de stratégie dans ce domaine... je m'y perds !



Ubuntu est généralement basé sur Debian. Je n'utilise jamais Ubuntu.


Basé oui, mais c'est forcément un kernel spécial, du moins le coeur. 
Évidemment, la Ubuntu standard ne peut pas être utilisée pour du RT. 
Ubuntu utilise la technologie basée sur le développement de PREEMPT_RT 
patch, basé sur un kernel 5.15 avec des "backports". Il existe aussi un 
autre patch, linux_rt et linux_rt_lts, mais je ne sais pas qui les 
utilisent. C'est peut-être ce patch qui est proposé par Debian, mais qui 
n'est disponible que pour les architectures x86. Ubuntu ayant rajouté le 
support des ARM.


A+
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Truc et astuces: nice et ionice (rappel)]

[Daniel Cordey via gull]

Le 04.03.23 à 13:38, Marc SCHAEFER via gull a écrit :


Attention, je parle bien d'ionice, et non pas de nice.


Oui, juste, mais je ne vois pas de grande différence. Si un process 
effectue une opération I/O, il va se trouver bloqué et ne sera de toute 
façon pas "élligible". Dès que l'opération I/O descend dans le kernel, 
cette notion de priorité disparaît. On peut au mieux "dégrader" sa 
priorité, mais pas l'améliorer. C'est particulièrement vrai dans le cas 
de "Idle".



Il ne me semble pas que sur Linux le fonctionnement de nice (et des
priorités de processus UNIX) ait changé.


Les différents schedulers développés ces dernières années, dans le but 
d'améliorer certaines situations, font donc joujou avec la priorité des 
process. Certains de ces codes privilégient certains I/O au détriment 
d'autres et cela a bien plus d'effets que la priorité d'un process; de 
même ionice aura peu de poids dans ce cas.


Les différentes tentatives d'améliorer les schedulers poursuivent un but 
qu'il est difficile d'atteindre. Il y a un antagonisme entre une station 
de travail et un serveur. Le premier à besoin de "raw" performance sur 
des applications verticales, alors qu'un serveur à besoin de throughput. 
C'est assez irréconciliable :-) En gros, favoriser l'un se fait au 
détriment de l'autre. Les nouveaux schedulers essaient de détecter une 
situation où la nécessité d'interactivité ne sera pas impacté par les 
exigences d'un serveur. Tout ceci est assez complexe (et hors sujet) et 
*nice ont un effet extrêmement limité sur ce que va vraiment faire le 
scheduler.



C'est juste, mais ici tu parles de la différence entre scheduling UNIX
classique (sans famine, avec même des processus de priorité inférieure
qui ont de temps en temps des cycles, donc pas de risque de priority
inversion [1]), contre scheduling temps réel (RT) qui peut créer des
famines et des bugs d'inversion de priorité.


Oui, exactement. Le temps réel est quelque chose de spécial, mais qui 
permet d'atteindre un certain niveau de déterminisme, ou de vraiment 
prioriser un process plutôt que d'autres; en évitant le swap et en le 
favorisant dans le scheduler (en agissant au niveau des priorités dans 
les profondeurs du kernel).



Tu as raison, mais moi je parlais véritablement d'I/O scheduling, une
extension spécifique à Linux, configurable avec la commande ionice, dans
la mesure où le backend le support, par exemple bfq. Pas de temps réel.


Oui, effectivement. Même sur un système idle (mon PC), on a un peu plus 
de 1'000 interruptions par seconde et quasi 7'000 context switch par 
seconde. Autant d'occasion de recalculer le process le plus éligible. Il 
y a donc beaucoup de candidats qui vont entrer en compétition avec noter 
process dont on a changé la priorité I/O. Or, avec ionice, on dit "on 
aimerait bien que...", sauf que le scheduler va dire "Oui, mais j'ai la 
cache, le DMA, les drivers... ah oui, toi... un moment". Contrairement à 
ce que l'on pourrait croire, on n'a que peu d'influence avec *nice, sauf 
dans des cas particuliers, mais je dirais certainement pas en mode 
interractif.




Il n'y a à mon sens aucune raison d'utiliser du RT scheduling, sauf
applications spéciales à latence garantie (p.ex. traitement audio ou
autre), et là on va alors séparer entre applications RT spécifiquement
écrites et laisser nos applications (processus) UNIX en priorité
classique, car elles ne sont pas forcément prêtes à tous les problèmes
qui peuvent se poser dans un système RT.


Exact.


[1] https://fr.wikipedia.org/wiki/Inversion_de_priorit%C3%A9


La première version du kernel HP-UX pour les processeurs PA-RISC était 
"temp réel". A l'arrivé des système multi-processeurs, il a été question 
de récrire la gestion du temps réel en utilisant des sémaphores pour les 
structures du kernel. C'est tombé à l'eau à l'époque. Je ne sais pas 
quelle base est utilisée par Ubuntu pour son kernel temps réel, mais il 
y a toujours eu une base de développement temps réel pour les kernel *X, 
mais c'est plutôt une branche qui évolue en parallèle du kernel standard 
de Linux.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Truc et astuces: nice et ionice (rappel)

[Daniel Cordey via gull]

Le 04.03.23 à 12:46, Marc SCHAEFER via gull a écrit :


Soit c'est psychologique, soit ça rend effectivement les I/O plus
souples dans mon workload et refait marcher l'ionice.


nice a subsisté dans les différentes version UNIX (AIX, HP-UX, Solaris), 
mais avait déjà été passablement castré par certaines distribution. La 
gestion de ces priorités est compliquée et sa gestion, se complexifiant, 
a tendance a ralentir l'ensemble. Raison pour laquelle, comme le dit 
Marc, les valeurs de priorité issues de "nice" ne sont plus traitées en 
I/O. Ceci est encore exacerbé par l'utilisation de différents 
"scheduler" qui essaient, par des méthodes heuristiques, d'améliorer la 
priorité des process en fonction de différents critères. C'est pour 
éviter de se trouver en contradiction avec ces "schedulers" que nice 
n'est presque plus pris en compte.


De plus, "nice" était utilisé pour améliorer le niveau de priorité de 
processus spécifiques (DB serveurs, etc.), mais pour du bash... vu la 
vitesse de frappe de l'être humain au clavier... faut pas exagérer :-)


Si l'on veut vraiment avoir un impact sur le niveau de priorité des 
processus et que cela ait un effet réel, il faut utiliser un kernel 
Real-Time, entre autre disponible comme une LTS spéciale chez Ubuntu 
(actuellement 22.04 LTS) et décrit ici :


https://ubuntu.com/blog/real-time-ubuntu-is-now-generally-available

je ne sais plus qui a dit :

"Ce n'est pas parce qu’une nouvelle technologie existe qu'il faut 
l'utiliser"


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] setuptools

[Daniel Cordey via gull]

Hola,

La version 23.04 d'Ubuntu amène avec elle la version 3.11 de Python qui 
est plus rapide que la version 3.10. Sur un seul code bien spécifique, 
court et peu optimisable, j'ai un gain de 16% par rapport à la version 
3.10, et 22% par rapport à la version 2.7. Normalement, cette version 
3.11 doit permettre des gains de 100% dans certaines situations. A vous 
de voir.


Avec cette nouvelle version de Python, d'autres choses changent. Pour 
tous ceux qui font des packages Python et qui ont utilisé d'abord 
distutils, puis setuptools, il y a un gros changement que je n'avais pas 
vu venir. En exécutant mes commandes habituels d'installation (basées 
sur setup.py), je suis tombé sur un message me disant que cette commande 
était déclarée obsolète et n'existait plus ! C'est en lisant l'article 
ci-dessous que j'ai découvert pourquoi et compris les raisons de ce 
changement que je trouvais assez brutal, mais justifié finalement.


Voici donc l'article qui décrit ce qui a amené à ce changement et ce 
vers quoi on doit tendre. J'avoue que ça me semble très logique et même 
souhaitable; ayant moi-même été confronté à certains des problèmes 
évoqués. Donc, préparez-vous à ce changement et bonne lecture :


https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] GNU commands in Python

[Daniel Cordey via gull]

Et pour ceux qui n'arrivent pas à quitter les commandes bash, mais 
veulent quand même faire du Python...


https://pypi.org/project/cmdix/

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Truc et astuces: nice et ionice (rappel)

[Daniel Cordey via gull]

Le 03.03.23 à 20:59, Philippe Strauss via gull a écrit :
y a ce truc là qui a l'air pas mal pour les mecs (ou filles) comme moi 
qui n'aime pas le langage bash ou shell en général:


Moi ça va :-) Il m'arrive de commencer à écrire un outil en bash et je 
fini pratiquement à chaque fois par le récrire en Python. Pourquoi ? 
Parce que passé une certaine taille, bash devint illisible et 
inmaintenable. L'erreur est de faire dela "programmation" en bash, alors 
que l'on devrait le limiter à faire des choses simples DE MANIÈRE 
SIMPLE. Très souvent on veut rajouter des fonctionnalités à un code bash 
et ça fini par devenir trop compliqué. Des tableaux, des listes, etc. en 
bash, oui c'est possible, mais ce n'est pas très lisible et reste très 
limité. Il faut savoir s'arrêter d'écrire en bash quand ça devient 
"lourd"; et ça devient très vite lourd.




https://xon.sh/ 

pas encore essayé mais l'idée me plait bien.


Wow, je ne conaissais pas !


PLEUR PAS FELIX Y A ENCORE 20 ANS DE JOB A ECRIRE DU BASH POUR DES CLIENTS.


Pas sûr que les clients se réjouissent d'avoir des centaines de lignes 
de code en bash que seuls trois ou quatre geek peuvent comprendre... 
C'est un problème de maintenance. Parmis les jeunes, qui va comprendre 
toutes les subtilités du bash ? C'est là qu'il faut se montrer 
intelligent et faire la part des choses en ayant un mix adéquat et en 
rendant les choses confortables.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] Re: Ethernet down 30 secondes au boot

[Daniel Cordey via gull]

Le 02.03.23 à 23:25, Marc Mongenet via gull a écrit :


Je me dis finalement que le plus probable est un défaut matériel de ma
carte mère.


C'est plus probablement le chip du NIC... Rageant de devoir changer de 
carte-mère juste pour ça.


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Ethernet down 30 secondes au boot

[Daniel Cordey via gull]

Le 01.03.23 à 09:24, Will van Gulik via gull a écrit :

On avait eu des comnportements étrange sur des " vieux " switchs cisco,


J'ai aussi eu un problème avec le port d'un router CISCO (vieux). Ce 
port n'a jamais fonctionné en full-duplex alors que la configuration 
était juste dans le router. En changeant de port le problème 
disparaissait. Aucun message d'erreur dans les logs...


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Ethernet down 30 secondes au boot

[Daniel Cordey via gull]

Le 28.02.23 à 18:19, catseyechandra via gull a écrit :

l'autonégociation a été standardisée avec le 1Gbit/s sauf erreur de ma part, 
mais cela date, plus trop sûr.


Ce n'est pas le standard ou la technique qui est en cause, mais la 
gestion qui en est faite par le driver. Des fois, quelques millivolts 
peuvent faire basculer un trigger dans un sens ou dans un autre.



donc sur les cartes 1Gbit/s il ne doit plus y avoir trops de problèmes de ce 
genre normalement.


Oui... comme toute l'informatique... il ne devrait pas y avoir de 
bugs... Et pourtant. Un bon exemple sont les boîtier TV de toutes 
sortes, bourrés de bugs. Pourtant, on ne cesse de nous bassiner avec des 
outils soit-disant hyper-intelligent, des langages qui évitent les bugs, 
des équipes de développement qui font passer Linus Torvald pour un 
rigolo, de l'intégration continue, des tests automatisés, etc. Et 
pourtant, on constate tous les jours le niveau lamentable des codes 
produits et de la fiabilité de ce que l'on est forcé d'utiliser. 
J'aurais même tendance à dire que c'est de pire en pire...


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] antivirus toutes plateformes

[Daniel Cordey via gull]

Le 28.02.23 à 17:31, Philippe Strauss via gull a écrit :


en d'autres termes qu'est ce qui est le moins pire dans ce monde de m...?


Aujourd'hui, la stratégie des entreprises et de leurs fournisseurs est 
de filtrer les mails sur le serveur de mail et ensuite d'avoir des 
process consommateurs de CPUs qui supervisent les activités du PC. Les 
fournisseurs qui tiennent la route sont FireEye/Mandiant (Mandiant ayant 
maintenant été racheté par Google), CrowdStrike, etc. Ces process se 
connectent à un concentrateur qui se charge de remonter l'info vers un 
SOC... Mais ça c'est de l'industrie, mais ça fonctionne assez bien, à 
condition d'avoir toute l'infrastructure et les services qui vont avec. 
Ce n'est donc pas pour les particuliers, mais à mon avis, c'est la seul 
chose qui peut vraiment apporter quelque chose au niveau de la supervision.


M* propose ses propres produits comme "Advanced Treat Protection" et "W* 
Defender" (entre autre). Mon expérience avec ces deux derniers produits 
n'est pas bonne. En deux ans d'utilisation dans l'entreprise, 4a n'a 
jamais rien généré d'autre que des faux positifs... Ce sont de super 
produits qui qualifient les librairies M* comme des malwares.


Je suis très septique sur l'utilité des anti-virus sous W*. Ils 
utilisent presque tous la technique des signatures, qui est une 
technologie dépassée et que les pirates ont appris à contourner 
facilement depuis plus de 10 ans. Les vendeurs rajoutent tous le mot 
"AI" dans leur portefeuille de solutions... Naturellement c'est du pipo 
total et vous pouvez aussi effectuer la commande suivant sur votre 
système : "sudo mv /usr/bin/grep /usr/bin/ai"... c'est la même chose. 
Les AV consomment du CPUs pour des prunes, vident la batterie des 
portables et ne sont capables de détecter que les anciens virus... les 
nouveau restent in-détectés jusqu'à mise à jour du fichier de signature 
et sont quasi incapables de détecter un process se baladant dans le système.


Sous W*, on propose des solutions qui s'apparentent à du spray 
désodorisant, alors que toutes les portes et le fenêtres de la maison 
sont ouvertes !


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Ethernet down 30 secondes au boot

[Daniel Cordey via gull]

Le 28.02.23 à 00:30, Marc Mongenet via gull a écrit :

L'Ethernet de mon PC a toujours posé des problèmes au boot, et je suis à 
la recherche de pistes de debug.

> ...

Ca me dit vaguement quelque chose et il me semble que j'ai eu ce genre 
de problème il y a longtemps. Sauf erreur, mais je ne me souviens plus 
trop, c'est un problème de driver qui ne négocie pas correctement avec 
l'autre partie et déduit qu'il est à 100 Mb/s. Il me semble que j'avais 
fini par coder en dure (en utilisant ethtool) à 1 Gb/s et en sautant la 
partie négociation.


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: gap: journalctl vs ps

[Daniel Cordey via gull]

Le 24.02.23 à 18:56, felix via gull a écrit :

Alors non:
J'ai un gap immédiatement après avoir booté!

Je pense qu'il s'agit d'un bug (systemd: 247.3-7+deb11u1).
Si vous avec une version plus récente (ubuntu) et que vous ne
voyez pas systemd démarrer avant le kernel, manifestez-vous!


J'ai une Ubuntu 22.10 et un kernel 6.2 et j'ai aussi un décalage.

Pose la question à ChatGPT :-)

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: gap: journalctl vs ps

[Daniel Cordey via gull]

Le 20.02.23 à 09:30, Philippe Strauss via gull a écrit :
un deux deux corrige ses timestamps d'après NTP non? l'autre reste du le 
temps de ta RTC avant le démarrage de NTP.

à mon avis.

O... ça c'est une bonne idée !

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] pour petit serveur économe

[Daniel Cordey via gull]

Hola,

Le 05.02.23 à 16:58, Paul Bartholdi a écrit :

J'ai fait beaucoup de benchmark dans ma vie, depuis 1964, ça fait 
bientôt 60 ans...


En 1964, je jouais à l'astronaute dans la soucoupe volante de la vallée 
de la jeunesse de l'expo nationale... Donc, je vois qu'il y en a des 
plus vieux que moi sur cette liste :-)


Finalement, le calcul des décimales de Pi est assez intéressant. Il 
combine calcul sur entiers (surtout), flottants, manipule des quantités 
immenses de données (plusieurs GO) etc, mais ne représente aucune 
situation réelle spécifique.


Oui mais chaque benchmark/test est finalement spécifique. Aujourd'hui, 
l'IA manipule beaucoup de valeurs flottantes de faible résolution (8 
bits !), et les DB beaucoup d'entiers... le machine learning utilise 
aussi beaucoup le calcul matriciel ce qui fait que les nouveaux CPUs 
incluent des opérations spécifique sur de petites matrices. Grande 
quantité de données... oui, mais comment sont-elles accédées (je parle 
ici de cas généraux et non pas du calcul des décimales de Pi) ? 
Séquentiellement, aléatoirement ? Il est en fait très compliqué 
d'essayer de déterminer la performance d'une architecture pour une 
application donnée à partir de benchmarks synthétiques. IBM avait 
réussit à imposer son MIPS à la fin des années 60 et cette référence a 
encore été utilisée par DEC (VAX) jusqu'au milieu des années 80, où 
l'arrivée des processeurs RISCs à clairement montré les limites de cette 
jauge. Et c'est là que Linpack a vraiment décollé :-)


(*) Les décimales de Pi forment un excellent test pour les programmes de 
compression. Si le fichier est compressible, c'est qu'il est faut, à 
moins qu'il le réduise à quelque chose comme "Pi avec 10^8 décimales".


C'est vrai... avec un nombre de décimales tendant vers l'infini, même la 
compression différentielles tend vers 0 :-)


Bon... je ne connais que les 50 premières décimales de Pi, ce qui reste 
toutefois trop pour être manipulé par une valeur en quad précision (128 
bits) :-)


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] pour petit serveur économe

[Daniel Cordey via gull]

Le 04.02.23 à 20:23, Philippe Strauss via gull a écrit :

Dans la même veine mais au sujet des petits SBC ARM, un bon comparatif 
de la radxa rock pi 5B et du raspberry pi 4:


Intéressant, merci

Je jalouse un peu les GFLOPS/W des apple M1 et M2 à vrai dire même si je 
ne vas pas acheter apple désormais après mes expériences avec le chip T2.


Well... Les GFLOPS sont calculés en utilisant le benchmark Linpack, qui 
date quand même pas mal. Ce benchmark a été conçu dans les années 70 et 
ensuite modifier pour tourner en version parallèle. Sauf que... cela 
utilise BLAST qui est une librairie écrite en assembleur, destinées à 
améliorer les performances en utilisant les fonctionnalité de 
vectorisation des CPUs, ce qui fait que ces performances sont très 
spécifiques à un type de calcul et peuvent utiliser les fonctionnalités 
des nouveaux CPU/GPU. Donc, les résultat peuvent être un peu biaisés si 
l'on veut comparer des performances de calcul pour différentes 
situations. Déduire ensuite le GFLOPS/W risque de donner une fausse 
vision de la véritable performance/W du CPU. Sans compter que Linpack va 
principalement tourner dans la cache L1 ou L2 suivant les CPUs...


Il me semble avoir vu d'autres benchmarks de mesure de perf/W pour les 
M1 et M2 et justement ceux-ci n'étaient pas vraiment devant... Raison de 
plus pour prendre les valeurs des GFLOPS/W avec des pincettes. De ce que 
j'ai vu, Apple a conçu ses CPUs pour de la performance avant tout, mais 
pas vraiment pour faire de la basse consommation. Perso, je ne tiens 
plus compte des benchmark utilisant Linpack... depuis 1987 !


Il ne faut pas non plus oublier que les fabricants vont mettre en avant 
les benchmarks qui les mettent en valeur vis à vis de la concurrence. 
C'est une vielle bataille qui existe depuis plus de 40 ans...


Il est souvent difficile de comparer les performances d'un CPU avec un 
autre car certaines familles ont des orientations différentes (serveur 
vs Desktop vs jeux). On peut trouver des suite de benchmarks réalisés 
par différentes personne et elles sont très instructives. En les 
regardant en détails on s'aperçoit peut-être qu'un CPU A va 5 fois plus 
vite que le CPU B sur un benchmark, mais que dans un autre cas il est 5% 
plus lent. Toutefois, ça permet de savoir quel genre d'optimisation a 
été privilégiée par un CPU ou un autre. De plus, les CPUs pour serveurs 
ont des performances qui peuvent fortement dépendre des chipset 
associés, alors qu'une partie des fonctionnalités des chipset se 
trouvent intégrées aux CPU des desktops, mais avec des performances 
moindre et des fonctionnalités en moins (ce qui ne se voit pas forcément 
facilement).


En conclusion, il est très difficile de séparer le bon grain de l'ivraie 
dans le discours des fabricants et le seul benchmark valable est celui 
de votre application ou la mesure de votre usage, associé à une appareil 
de mesure des Watts !


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] pour petit serveur économe

[Daniel Cordey via gull]

Le 03.02.23 à 10:13, Philippe Strauss via gull a écrit :
toujours sur la veine des petits PC économes avec de la "réserve de gaz 
sous le pied" tout de même:


- AMD Ryzen 5800U : 6,7W au repos

https://www.asrockind.com/en-gb/4X4%20BOX-5800U 



Ouai... super cool. Bonnes perfs ! Par contre, bien qu'ils te mettent 4 
ports de display, tu ne peux faire que du 4K. Si tu as déjà un écran de 
34", le deuxième écran est alors petit. Il faudrait du 8K...


A quel prix ?


la gamme des NUCs asrock est bien, avec des Intel tout récents:

https://www.asrockind.com/en-gb/faned-embedded-box-pc 



Les procs Intel consomment plus à performance égale (et encore). Ca a 
pour effet, qu'il faut un petit ventilo dans le boîtier et tu as 
l'impression que ton boîtier va décoller à chaque fois que le CPU monte 
en fréquence.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] la loi européenne sur le chat et le mail

[Daniel Cordey via gull]

Le 01.02.23 à 14:39, Philippe Strauss via gull a écrit :

https://mullvad.net/en/blog/2023/2/1/eu-chat-control-law-will-ban-open-source-operating-systems/
 



Est-ce que ça veut dire que les pirates ont moins de 17 ans ?


cela s'annonce mal, p*tain ça pue à l'horizon...


C'est pas nouveau et ça ne m'étonne pas, venant de politiciens

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] M* Defender

[Daniel Cordey via gull]

Hola,

Je pense qu'il vaut mieux que je ne fasse pas de commentaires...

https://www.theregister.com/2023/01/31/microsoft_defender_linux/

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] Re: [SPAM] naaan c'est pas de la pub pour *ntel outside!

[Daniel Cordey via gull]

Le 22.01.23 à 12:04, Philippe Strauss via gull a écrit :
Au contraire il me semble que c'est bien la bureautique qui bénéficie le 
moins des multicore, pour preuve intel et ses performance core contre 
efficiency core.
mais sous linux il n'y en a pas réélement besoin, libreoffice est pas 
bien gourmand.


Oui, je ne vois pas l'utilité de paralléliser l'écriture de document 
texte ou autre :-)


je connais pas le domaine de la base de donnée de ce côté, si ce n'est 
(ne sont) quelques datastructures parallélisable sans locking en mémoire.


Ca dépend des "moteurs". Certains sont "threaded", d'autre en 
multi-process. La clef réside encore dans la manière de partager les 
informations entres les différents process/threads. C'est la même chose 
pour les serveurs Web. Dans le cas de *wsgi, tu as le choix entre 
multi-process ou multi-threading, ou encore une combinaison des deux. 
Mais, comme, encore et toujours, c'est un problème d'accès mémoire qui 
va limiter l'avantage des CPUs multi-coeurs. Il y a d'ailleurs plein 
d'articles au sujet du goulot d'étranglement de l'accès à la mémoire sur 
le site de netxplatform. Il y a aussi de gros débats au sujet de ces 
accès, admettant finalement que DDR* a une limite et qu'il faut 
envisager autre chose car le monde réalise enfin que le véritable frein 
à l'amélioration des performances ne réside pas dans des CPUs plus 
puissant (contrairement à ce que nous vendent les constructeurs).


Depuis le début on a eu "l'unité centrale" et la mémoire. Or, maintenant 
c'est une erreur. La masse de données est telle que l'on doit renverser 
ce paradigme et penser que le centre est représenté par les données et 
que l'on doit cesser de penser "déplacement" des donnés RAM/SSD <-> CPU. 
Les données ne doivent plus bouger et c'est la puissance de calcul qui 
doit se déplacer. C'est surtout vrai pour les data-center et les 
serveurs de base de données. Plutôt que d'avoir des DB serveurs que l'on 
interroge et un transfert des données (utilisant le réseau) vers les 
serveurs de traitement, il faut laisser les données dans les data-center 
et envoyer l'ordre d'exécution du code plus proche des DB serveurs. A la 
fin, on finira par comprendre que l'on doit avoir des ALU dans les chips 
mémoire; ce qui nous permettra d'accélérer massivement le traitement des 
données. Couplé à de mmap ça peut être d'enfer. Mais tout ça est de la 
musique d'avenir et on en est encore à subir le marketing des fabricants 
qui sont dans l'impasse et nous imposent leurs solutions inefficaces.


https://www.nextplatform.com/2022/04/06/the-hbm3-roadmap-is-just-getting-started/
https://www.nextplatform.com/2022/08/22/the-expanding-cxl-memory-hierarchy-is-inevitable-and-good-enough/
https://www.nextplatform.com/2023/01/18/what-do-we-do-when-compute-and-memory-stop-getting-cheaper/
https://www.nextplatform.com/2022/07/05/the-future-of-system-memory-is-mostly-cxl/
https://www.nextplatform.com/2021/03/11/its-time-to-start-paying-attention-to-vector-databases/
etc.

Bonne lecture :-)

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] naaan c'est pas de la pub pour *ntel outside!

[Daniel Cordey via gull]

Pour info, ton message a bien passé malgré Pinochet :-)


Ah pas évident la progr. parallèle.


Non, les journaliste font les perroquets des fabricants de CPU et ne 
réfléchissent pas à ce qu'ils disent. Selon des statistiques publiées à 
l'époque par... je ne sais plus qui... Les programmes confiés à des 
machines comme le Cray n'arrivaient à utiliser que 15% des performances 
théoriques de vectorisation de ce genre de machine... Après une année 
d'optimisation du code. On a fait des progrès avec des librairies de 
traitement matriciel écrites spécialement pour tirer parti des systèmes 
multi-units (ALU, FPU, CUDA, etc.), mais ça reste très spécifique et 
limité.


L'un des problèmes de multi-threading en calcul est l'accès concurrent à 
des zones de mémoire communes. Y'a pas de solution... à moins d'avoir un 
compilateur qui pourrait séparer ces zones, qu'il faudrait identifier à 
la compilation ou avec "profile"... Et ensuite répartir ces zones dans 
différentes "banc" de RAM... C'est très compliqué et c'est spécifique à 
chaque machine !


1. utilisation bureautique. max 5 coeurs sont utilisés en simultané, CPU 
idle la plupart du temps.


Oui, en effet. Mais c'est sans doute l'une des situation où l'on arrive 
à tirer le mieux parti des CPUs multi-coeurs.



2. utilisation multimedia


Oui, mais là je ne vois pas un vrai avantage d'avoir du multi-coeur. 
D'autant que pour le 3D et le Raytracing il y a déjà des librairies 
adaptées pour les différents GPUs. Pour visionner un film... A part le 
décodage déjà optimisé avec des fonctions dans les CPU/GPU, je ne vois pas.



3. compilation


Oui, il existe une version parallélisable de gcc :

https://gcc.gnu.org/wiki/ParallelGcc

concernant le multimedia et le numcomp, regardez intel ISPC, c'est un C 
augmenté dans le même paradigme que les shaders opengl ou vulkan, pour 
faire du SIMD et multithreading automatisé, c'est top, le reste 
intégralement de la m à côté mais c'est un certain investissement en 
terme d'apprentissage, pas sur la syntaxe, mais la sémantique de ce langage.


Je ne fais plus ce genre d'exercice depuis longtemps. Ça prend 
énormément de temps et ton code se trouve attaché à une architecture 
très spécifique. De plus, on retombe sur le problème lié aux zones 
mémoire communes qui ne peuvent pas tirer parti des multi-canaux d'accès 
à la RAM et se retrouvent à faire la queue sur un seul canal.


c'est en ça qu'il important d'avoir une TDP de base faible, les 
conséquences du point 1.


Exact !


(difficile d'éviter le frenglish dans nos domaines de l'informatique.. :)


Oui... j'essaie mais certains termes Français sont encore plus ridicules 
(bogue... !)


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] Re: SBC

[Daniel Cordey via gull]

Le 20.01.23 à 23:07, Yann Lehmann via gull a écrit :

Effectivement, 350w suffiraient certainement pour mon desktop, mais je 
me rappelle avoir eu du mal à en trouver une livrable immédiatement en 
dessous de 500w à l'époque (et j'en avais évidemment besoin tout de suite).


Et si je ne fais erreur, une alim efficace de 500w fera consommer moins 
qu'une cheap de 350w.


Oui, c'est juste. Mais... je consomme 15-18 Watts en fonctionnement avec 
mon système (CPU, RAM, SSD, NIC, etc.). Est-ce qu'un système qui 
consomme 10 fois plus va 10 fois plus vite ? Je ne pense pas. J'ai donc 
cessé d'utiliser des PC en tour avec ces grosses alims alimentant des 
grosses cartes-mère. Aujourd'hui, la performance/Watt est devenue 
quelque chose que l'on regarde un peu plus et je pense que c'est une 
bonne chose. Mais il subsiste des situation qui nécessitent encore des 
tours et des grosses alims; c'est une question d'usage et de recherche 
d'efficacité.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] naaan c'est pas de la pub pour *ntel outside!

[Daniel Cordey via gull]

Le 16.01.23 à 23:16, catseyechandra via gull a écrit :
processeur récent, veloce, pas trop énergivore (mais pas super bon 
marché..):


Véloce, pas trop énergivores et bon marché ? A mon humble avis c'est une 
question de point de vue. Ça dépend fortement de l'usage spécifique que 
l'on va en faire. Depuis ~2005, la fréquence d'horloge des CPUs stagne, 
de même que la performance en single-thread et le TDP. Pour continuer à 
vendre  de "nouveaux" CPUs, et prétendre que la loi de Moore n'est pas 
morte, on s'est contenté de miser sur l'augmentation de la densité 
(transistors/mm2)... en vendant le multi-core. Or, si l'on se penche un 
peu sur les performances ainsi obtenues, on ne retrouve pas les gains 
rêvés... On en est même très loin. Quelques benchmarks/applications bien 
spécifique bénéficient un peu de l'augmentation du nombre de cœurs, mais 
pour la plupart des autres cas le constat est affligeant. Il est 
fréquent de voir des applications ne gagner qu'un facteur 3-4 alors que 
l'on a 28 cœurs...


Tout est dans ce que l'on ne dit pas, ou très peu. Le problème réside 
dans l'accès à la mémoire et aux I/O. Le problème est que chaque cœur 
doit partager ces accès avec un certain nombre d'autres cœurs. On voit 
donc souvent un nombre de canaux d'accès très réduit par rapport au 
nombre de cœurs; entre 4 (dans le meilleur des cas, mais rare) et 
souvent 8. CAD que 8 cœurs doivent se partager l'accès à la mémoire... 
Les constructeurs on beau vanté l'augmentation de la bande passante, 
mais lorsque vous calculez celle-ci par cœur c'est très nettement moins 
glorieux. Pire... dans le cas d'un traitement multi-thread, en accédant 
à la même zone mémoire, il y a de très fortes chances que vos threads 
fassent la queue pour accéder à la mémoire.


Il en va de même pour les accès aux bus I/O (SSD, USB, NIC, etc.)

Et encore, on n'a pas parlé de la gestion de la mémoire cache L3, qui 
est splittée en 2 parties (voir plus dans certains cas) et a un temps 
d'accès moyen de ~50% du temps d'accès de la RAM.


Qui plus est, on s’aperçoit que la consommation augmente de manière 
non-linéaire et plus vite que les performances... On est donc sur la 
mauvaise pente.


https://www.nextplatform.com/2023/01/19/more-cpu-cores-isnt-always-better-especially-in-hpc/

Pour moi, et les chiffres le prouvent (à part un très petit nombre de 
cas que les constructeurs s'empressent de mettre en avant en faisant 
comme si c'était une généralité), plus on augmente le nombre de cœur, 
plus c'est inefficace


Si l'on veut vraiment faire du "clustering", avoir N CPUs avec chacun 4 
cœurs est bien plus efficace qu'un seul avec 128 cœurs. Ca consommera 
moins et ça ira plus vite. En effet, un cluster de 32 CPUs de 4 cœurs, 
donnera de bien meilleurs résultats qu'un seul CPU à 128 cœurs. Sans 
compter le côté redondance...


A part ça, Intel ayant bien perdu de sa superbe depuis des années en 
distribuant ses bénéfices aux actionnaires, plutôt que de les 
réinvestire dans la recherche, ils font feu de tout bois depuis quelques 
temps pour essayer de rattraper le temps perdu. Ils sont à la traîne et 
perdent des parts de marchés au détriment de AMD, Nvidia et... de 
certains CPU Chinois (cht... faut pas dire)


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Think seriously about “safety”; then do something sensible about it

[Daniel Cordey via gull]

Hola,

La réaction de Bjarne Stroustrup au rapport de la NSA au sujet de 
"Memory Safety".


Je dois avouer que je suis entièrement d'accord avec sa vision. 
Seulement, la mode est au changements pour le changement... C'est la mode.


https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: SBC

[Daniel Cordey via gull]

Le 24.12.22 à 12:36, Yann Lehmann via gull a écrit :

Pour ça, il faut aussi avoir une alim qui va bien, c-à-d pas 
surdimensionnée et silencieuse elle aussi.


Je suis très content avec un modèle 500w de be quiet! (Pure Power 11 CM).


On cherchait pas des trucs qui consomment pas trop ? Tu dis "pas 
surdimensionné", mais ton modèle est une 500W... :-) Bien sûr, tout 
dépend de l'usage et des besoins, mais ça me semble un peu beaucoup pour 
un PC de bureau ou un petit serveur de disque ou un firewall B-)


Ca coûte certes plus du double d'une alim basique, mais je ne l'entends 
pas (et celle qu'elle a remplacée m'avait duré 15 ans).


Oui, on fini toujours par "payer" le bon-marché.

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: small & embedable is beatifull

[Daniel Cordey via gull]

Le 19.12.22 à 13:40, Philippe Strauss via gull a écrit :


RockChip RK3588:

https://www.mixtile.com/blade-3/


Intéressant. Je voulais me monter des serveurs à base de Pico-ITX en 
2015... A l'époque le choix et les performances étaient limités. C'est 
pas mal.



Et étoile montante, SiFive avec du Risc-V:

https://www.sifive.com/boards


J'attends que l'on puisse avoir des boards pico-itx (j'aime bien ce 
format compact) avec du Risc-V, avec 8 GB de RAM, M.2 2280 et 1-2.5 Gb/s 
ethernet. Et en POE ça serait top...


25Gig de connection au net, pas mal, moi je me dis qu'il y a encore bien 
du marché pour du routeur linux avec la/les QoS dispo.


Ce qui freine actuellement est le prix des routeurs/switches. Beaucoup 
d'infos sur les technologies réseau, vitesse, chips, etc. sur :


https://www.nextplatform.com/category/connect/

dans le noyau, 
les cisco n'arrivent pas à la cheville de Linux sur ce plan, et le coût 
de la mémoire pour faire du buffering sur des interfaces 100M/1G plutôt 
que 100G, il y a un truc à faire.


Oui pour du p2p... ça ce gâte lorsque tu augmentes le nombre de 
connexions réseau. Le swicthing devient très gourmand. Des chips 
spécifiques ont été développé pour faire face à ces volumes de paquets. 
Comme (par exemple) :


https://www.nextplatform.com/2022/08/16/like-a-drumbeat-broadcom-doubles-ethernet-bandwidth-with-tomahawk-5/

Avec un serveur/CPU classique tu vas très vite consommer 100% de ton CPU 
et saturer ta bande passante; en plus de consommer un max.


Plus du firewalling et VPN sur ma même box évidemment. Cible: 
l'interface 1Gbit/s. Vous mettez quoi comme fonctionnalité soft sur vos 
CPE clients résidentiel et PME, Nimag, si c'est pas secret d'entreprise?


Je sépare le swicthing/routage de la fonctionnalité de pare-feu. 
D'autant que je préfère avoir des petits firewall séparés, suivant les 
segments de mes réseaux et ce à quoi ils sont dédiés. L'avantage est que 
tu peux alors avoir de multiples Rpi comme firewall, plutôt qu'une seule 
grosse bête qui, si compromise, ouvre la porte à tout ton réseau. En 
plus, tu peux bricoler tes règles en étant certain de ne pas affecter 
l'ensemble de ton réseau, faire des tests et installer des trucs plus 
exotiques ou en béta. Qui plus est, si l'un tombe en panne, l'impact sur 
ton infrastructure va se trouver limité. En prod il est bien de prévoir 
de la redondance, même chez toi...


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] startup

[Daniel Cordey via gull]

Le 19.12.22 à 09:21, Philippe Strauss via gull a écrit :


Le toute animé dans le temps.

QQun conaissant OpenGL pour m'aider?


Oups... désolé... ça fait plus de 25 ans que je ne me suis plus plongé 
dans ces trucs d'éclairage et de positions des lumières et de 
l'observateur... Essaie de trouver des tutos spécifiques sur youtube (ça 
serait mon point de départ aujourd'hui). Il y a beaucoup de paramètres, 
dont le type de surface...


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] Re: SBC

[Daniel Cordey via gull]

Le 18.12.22 à 14:35, Philippe Strauss via gull a écrit :


J'apprends qqchose sur le hardware à fouiller le net pour discuter dans 
ce thread de mails, surtout grace à cette page wikipedia, la technique 
de recherche de CPU que j'ai trouvée est la suivante:


- regagrder quel est la géométrie la plus petite, 7 nm actuellement sur 
cette page.


- regarder les TDP minimaux pour 7 nm, virer les vieux coucous

- retenir les récents avec la plus grande dynamique de fréquence d'horloge.


Bonne stratégie de base :-)

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: SBC

[Daniel Cordey via gull]

Le 17.12.22 à 17:40, Philippe Strauss via gull a écrit :

https://en.wikipedia.org/wiki/List_of_CPU_power_dissipation_figures

Ce sont des CPU d'ordis portables en fait à 10-15W au repos.

Bon à savoir, mon prochain serveur perso ce sera ce genre de 
dissipation, pas plus.
J'ai déplacé mon wattmètre pour être plus précis (avant il était avant 
ma prise multiple). Donc... mon mini PC Ryzen 7 ne consomme que 10-15 W 
finalement. ce n'est que lorsque je fais un recover de mes deux browser 
(Brave et Chrome Beta), ayant entre 130 et 160 tabs chacun, que je monte 
dans les 50 W. Ca ne dure que quelques secondes et ça redescend très 
vite entre 15 et 20 W. Naturellement, mes 300 tabs occupent pas mal de 
mémoire et il serait facile de se cantonner à moins et limiter ainsi la 
consommation. Il est donc tout à fait possible d'avoir ce genre de 
PC/Serveur à consommation assez basse.


Il existe des CPUs de plus faible consommation, aussi sur de petits 
formats (Pico-ITX), mais ça tape dans des CPUs nettement moins 
performants, tel que des Intel J1900, N3710 ou N4200, Alder Lake U, 
Tiger Lake UP3 ou des AMD T56N. Là, on tape dans les 5-6 Watts, mais les 
performances sont quand même supérieures à un RPI.


Par exemple : http://www.commell.com.tw/product/SBC/LP-180.HTM

Tout dépend donc des besoins que l'on a. Mais je trouve que ces boîtiers 
Mini PC ont un assez bon rapport performance/watt. Il est claire que la 
tendance est à la baisse et on verra ce que les fondeurs nous sortirons 
d'ici quelques années. Mais c'est déjà nettement mieux que l'ancienne 
génération à 60 W, et celle à 130 W. N'oublions pas que ces mini PC ont 
des performances plus qu'acceptable en graphique. Quand on voit la 
taille et le nombre de ventilos sur certaines cartes graphiques, on peut 
éviter de culpabiliser au niveau de la conso de ces petits boîtiers :-)


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] SBC

[Daniel Cordey via gull]

Le 14.12.22 à 22:11, Philippe Strauss via gull a écrit :

regardez le petit bijou que j'ai trouvé cet aprèm.:

https://www.aliexpress.com/item/1005003362147854.html?spm=a2g0o.productlist.0.0.48f32be12sua7b_pvid=8756adaa-07ac-478b-8a0c-399cd03f475e_p4p_detail=2022121323492315456967521255720003205969_exp_id=8756adaa-07ac-478b-8a0c-399cd03f475e-0_ext_f=%7B%22sku_id%22%3A%221230876136683%22%7D_npi=2%40dis%21CHF%21585.96%21351.57%21%21%21%21%21%402101d4a716710041637398052e5f20%211230876136683%21sea=QNiKWId7y9km_pvid=2022121323492315456967521255720003205969_1_pvid=2022121323492315456967521255720003205969_1

oups l'URL est longue.

dans le genre rapport perf./prix, c'est pas mal. imbatable dans la gamme 
PC/CPU desktop je crois bien.


C'est mon ordi perso (bureau) depuis février 2022. C'est absolument Top. 
Boîtier très silencieux !



Operating System: Kubuntu 22.10
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 6.1.0-060100rc5-generic (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 5700U with Radeon Graphics
Memory: 15.0 GiB of RAM
Graphics Processor: RENOIR

Boîtier, plus écran 34 pouces, plus disque externes USB3 2 TB, plus 
clavier (keychron avec LEDs). Le tout ne consomme que 50-55W.


Très bonnes performances, en tout cas largement suffisantes pour moi. Ne 
ne jouant pas à des jeux vidéos, je ne peux pas juger de ses 
performances dans ce domaine.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Commentaires avisés

[Daniel Cordey via gull]

Le 08.12.22 à 08:30, Dominik Madon a écrit :


Alors que nous venions de recevoir nos diplômes d'informaticiens de l'EPFL en 1995 (putain ça fait 
long), nous l'avons croisé sur le chemin du retour de la cérémonie. L'un de nous lui a lancé en 
plaisantant: "Et voilà, tout ça pour programmer en Visual Basic maintenant" Il a répondu 
du tac au tac: "Ce n'est pas très important tant que vous programmez bien."


C'est assez juste mais certains langages ne t'aident pas :-)

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Commentaires avisés

[Daniel Cordey via gull]

Hi all,

Suite de la discussion au sujet des langages de programmation :

"I don't think you can be a professional in the computing industry 
knowing just one language."


Bjarne Stroustrup

Bon, c'est l'inventeur du C++... et il enseigne à Columbia. Perso, et 
pour ceux qui ne le connaissent pas, je recommande l'écoute de cette 
vidéo. C'est instructifs et très claire, en plus d'être une magnifique 
leçon d'un des grands de cette industrie :


https://www.youtube.com/watch?v=86xWVb4XIyE

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Commentaires avisés au sujet de Rust

[Daniel Cordey via gull]

Le 02.12.22 à 22:14, Philippe Strauss via gull a écrit :
es goûts, les couleurs, les opinions sur les langages de
programmation, c'est pas x-files, c'est pas inexplicable, c'est comme 
tellement de chose une histoire de mémoire, d'expériences, dans tous les 
sens de ces deux termes.


je dirais... en partie. Il y a quand même des langages qui sont plus 
adaptés à traiter certains sujets que d'autres. Par exemple, R est un 
langage conçu pour les statistiques... On peut faire les mêmes 
opérations en Python mais il se peut que l'on doive écrire plus de code, 
mais R n'est pas un langage d'usage général. C'est donc un peu de goût, 
et un peu de "fait pour". Je dirais que ta remarque est juste pour un 
usage général. Dans ce cas, ma préférence va toujours à la simplicité et 
à la rapidité. Moins il y a de code à écrire, plus petite est la 
probabilité d'erreurs; le nombre de bugs pouvant être directement lié au 
nombre de lignes de code !


- quels langages étaient disponible entre tes 20 et 35 piges, pour 
résoudre aux mieux les problèmes informatiques qui te titillaient, te 
fascinaient, la doc que tu as trouvé dans ces moments cruciaux, les 
conseils, entourages, prof. si cursus scolaire dans le domaine??


Cursus scolaire assez lunaire dans le domaine... Un prof de math disant 
"Je suis chargé de vous enseigner l'informatique. Sachez que je suis 
contre !". Un autre n'y comprenant strictement rien et d'autres ma 
taxant parce que j'utilisais des commandes pas encore enseignées 
(FORTRAN IV). Et donc, tout seul et contre l'avis des profs : FORTRAN, 
ALGOL, PASCAL, PL/Z, BASIC (HP), Assembleur. Par la suite, ça n'a pas 
changé... j'ai appris tout seul tous les autres.


J'ai bien essayé de faire comprendre que l'informatique pourrait être 
très utile pour dessiner les graphiques et acquérir les données au labo, 
mais je me suis vu rétorqué : "Contentez-vous de respecter les 
protocoles du laboratoire !"


De plus, à l'époque, l'électronique digitale était "mal vue", c'était 
tout analogique (ce qui est quand même sympa).
Donc les langages qui parlent aux gens du "numerical computing", un peu 
matheux sur les bords, ça me parle vraiment, le reste, l'informatique de 
gestion, bof, circulez il n'y a rien à voir pour moi.


L’étymologie du mot "informatique" contient "information". C'est donc 
une approche très différente de "Computer Science" ! Or, je rigole car 
aujourd'hui, le monde de l'informatique manipule massivement de 
"l'information" et la partie calcul est largement minimisée. Ce qui fait 
que ce que tu appelles "informatique de gestion" est en fait ce qui 
constitue 99% de l'informatique aujourd'hui (IA, SQL, Web, etc.). Tous 
les langages dont on parle aujourd'hui, sont adaptés à ces types de 
traitement et pas vraiment aux calcul pure (seul Fortran et R à mon avis).


Mais chacun son truc, en fait chacun son expérience personnelle, ce qui 
a imprimé sa mémoire à soit.


Oui, et surtout les besoins avant tout. Certains langages sont des 
langages conçus de manière théorique et soit tentativement imposés 
(ADA), ou quasi (Java).



Et ça m'a fait adorer C/OCaml/Rust et python aussi.


Je ne vais pas contester ton choix et ça se défend dans plein de situation.

Et vous, quels sont vos intérêts premiers en progr., 


Simplicité, efficacité, concision, performance, souplesse, robustesse, 
cohérence. Ça élimine pas mal de langages... :-)



les sujets qui vous ont titillé, passioné?


La découverte du C, de Xlib (https://en.wikipedia.org/wiki/Xlib) et 
l'implémentation de Xtoolkit 
(https://en.wikipedia.org/wiki/X_Toolkit_Intrinsics) . Ayant besoin 
d'écrire un widget PEX (https://en.wikipedia.org/wiki/PHIGS) pour Motif 
et n'ayant pas accès aux code source, j'ai dû faire du reverse 
engineering uniquement avec les fichiers *.h, ce qui m'a permit de 
comprendre les bases de l'implémentation de la programmation objet en C 
(découverte de gros bricolage avec les calculs des pointeurs dans les 
structures avec sizeof() !!!). nsuite, j'ai découvert la manière dont 
C++ était implémenté en C en regardant le code C généré par le 
cross-compilateur C++ des années 80.


Et quel langages et livres ont répondu au mieux à 
vos questionnements et désirs de créer, même si de manière immatérielle, 
dans le monde numérique?


Maurice Bach (The design of the UNIX operating System)
Brian Kernighan (The C programming language)
Denis Ritchie (The C programming language)
Bjarne Stroustrup (data structure, C++)
David Baezley (Python Essential reference)

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Commentaires avisés au sujet de Rust

[Daniel Cordey via gull]

Bonjour à tous,

Il y a quelques temps, Philipe Strauss posa une question d'opinion au 
sujet du langage Rust. Dans cette optique, voici un petit article de 
quelqu'un qui semble bien connaître Rust, et il m'apparaît utile de le 
lire pour connaître son avis et bénéficier de son expérience :


https://scribe.rip/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454

Bonne lecture

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SECURITY] [DSA 5257-1] linux security update

[Daniel Cordey via gull]

Pas de problème Philou :-) J'assume le GRUMPIDANT...

Oui, le bug wifi... En effet, le plus problématique.

Combine d'iscrits ? Bonne question, mais surtout combien d'actifs ou de 
réactifs ?


A+

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Fwd: [SECURITY] [DSA 5257-1] linux security update

[Daniel Cordey via gull]

Merci Philippe,

Mais comme l'a souligné Marc, une seule de ces vulnérabilité mérite un 
peu plus d'attention. Les autres sont des attaques locales, 
hypothétiques (mais à ne pas négliger quand même), et souvent des DOS.


Une pratique de mise à jour régulière des patchs de sécurité du système 
permet d'éviter tous ces problèmes. Il vaut mieux insister pour que tout 
le monde adopte une stratégie efficace des mises à jour. Perso, je fais 
un "apt update/upgrade" chaque jour. De plus, je colle au plus près des 
versions du kernel (pas indispensable !). Par exemple, ce matin je 
tourne une version 6.1 rc1


Mais, quand même merci pour ce petit rappel !

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Rust et tuto. d'un nouveau langage de programmation en général

[Daniel Cordey via gull]

Le 16.10.22 à 12:49, Concombre Masqué a écrit :


Avec C j’étais perdu en terme de structurer un programme (NB: je ne suis pas un 
grand dév., plutôt hobby et personne du traitement du signal ne se cantonnant 
pas à Matlab).


Tous mes développements sont constitués d'outils, de librairies de bas 
niveau et finalement d'autres de plus haut niveau. Chaque fonction était 
un fichier (*.c), associé à un fichier *.h, avec des flags permettant 
d'utiliser le fichier *.h comme "définition" ou comme "déclaration"; 
ceci évitant d'avoir des versions séparées, et donc des informations 
potentiellement différentes.


Tout ceci était gérer par un IDE écrit en TCL/TK et utilisant un gros 
fichier GNU Make contenant plein d'automatismes et de pratiques 
conventionnelles (définies par moi un fois pour toute). Les tests de 
conformité étaient intégré au code et devaient ne pas avoir d'erreur 
pour la construction automatique des librairies et leur installation


Ce qui fait que je pouvais avoir des centaines de fichiers sources (et 
includes), mais la maintenant et le développement était hyper facile. 
J'avais tout automatisé et je n'avais pas besoin de perdre mon temps à 
configurer des usines à gaz hyper fragiles pour ça.


Ah, j'oubliais... la doc de la signature des fonctions était 
automatiquement générée en HTML et intégrée à la doc de la librairie.



OCaml m’a appris énormément de ce point de vue.
Rust sera peut-être la synthèse ou plutôt le "sweet spot" performant entre C et 
le monde ML.


J'ai aussi mis très vite mis à la poubelle tous les trucs lourdingues et 
non-intégrés liés à *ML et autres. Il vaut mieux définir des choses 
simples que tu peux faire et maintenir avec un minimum d'effort, plutôt 
que de te lancer dans le développement de monstruosité in-maintenable et 
qu'à la fin tu ne peux même plus faire évoluer tellement c'est gros.


D'ailleurs, cela rejoins exactement ce qu'essaie de faire SCRUM, qui 
démontre l'échec des ces trucs à grands projets...



Carbon de google, cppfront d’un tout bon de chez krosoft s’inspirent largement 
de Rust. Et ce sont deux candidat pour remplacer ou faire drastiquement évolué 
C++. Google, Krosoft...


Un langage de programmation est toujours destiné à faciliter l'écriture 
de code pour un type de problème donné. Dans les années 60, on avait 
trois langages qui avaient clairement émergé, CAD FORTRAN, COBOL et 
ALGOL. Comme aucun de ces langage n'était satisfaisant pour traiter 
d'autres problèmes que cexu pour lesquels ils avaient été conçus, des 
ingénieurs ont eu la brillante idée de vouloir réunir le "meilleur" de 
chacun de ces langages pour un faire un seul. Oui, brillante idée qui 
pense qu'en réunissant le meilleur de chacun, on va avoir un truc 
extraordinaire à la fin. Le résultat fut "PL1"... un échec retentissant 
car finalement on a eu le pire de chacun... Pour moi, un gigantesque 
éclat de rire ! Donc, je regarde tout langage qui prétend faire la 
synthèse d'autres langages avec un filtre assez ironique en me 
remémorant PL1. Et tu sais quoi `Je suis chaque fois mort de rire. 
Combien de langage soit-disant révolutionnaires depuis 1990 ? Combien 
sont vraiment utiles et n'engendrent pas de nouveau problèmes, souvent 
pire que les précédents ? On oublie le fait qu'un bon langage de 
programmation c'est avant tout de la simplicité et un éco-système.


Autre magnifique contre-exemple... ADA :-)

Le seul langage qui a trouvé grâce à mes yeux, depuis cette époque, est 
Python. Donc, j'en reste à la combinaison Bash/Python/C suivant les 
besoins et je ne vois toujours aucune bonne raison d'ajouter un autre 
langage. Sachant qu'aucun langage ne va remplacer ce trio infernal à mon 
avis.



https://cichocinski.dev/blog/trying-new-programming-languages-helped-grow-software-engineer


Oui, en théorie et je passe souvent du temps à investiguer des nouveaux 
langages (j'ai un peu cessé depuis un moment). Mais... Si tu es employé 
par une entreprise, tu n'as pas le choix du langage ! Si tu dois engager 
des développeurs, tu veux avoir le choix et pas te cantonner à une liste 
de 200 mecs en Europe qui maîtrisent le langage. C'est aussi vrai pour 
les outils du genre reactjs, ansible, maven, jquery, etc.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Fwd: [SPAM] Rust et tuto. d'un nouveau langage de programmation en général

[Daniel Cordey via gull]

Le 16.10.22 à 11:33, Concombre Masqué a écrit :


T’as regardé depuis la bhoem gc ou jemalloc, dmalloc, et d’autres garbage 
collector que tu trouves en OSS?


Je ne veux surtout pas utiliser de GC ! Ma librairie n'était pas 
destinée à faire du "boundary" check en permanence, puisque cette tâche 
était dévolue aux librairies d'objets plus spécifiques. De plus, la 
fonction free() faisait de la défragmentation de manière automatique. 
Aussi, la librairie maintenait une liste triée des "espaces", afin 
d'optimiser les demandes d'allocation et d'éviter de faire des fragments.


Qui plus est, lorsque j'ai écrit cette librairie, aucune autre librairie 
de ce genre n'existait (1992-1993) et Linux était à peine naissant et 
donc pas envisageable pour mes développements.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Rust et tuto. d'un nouveau langage de programmation en général

[Daniel Cordey via gull]

Le 14.10.22 à 08:46, Philippe Strauss via gull a écrit :

Trôôôp bien ce tutoriel de Rust, _LE_ nouveau truc bien en terme de 
langage de programmation:


https://fasterthanli.me/articles/a-half-hour-to-learn-rust 



Surtout tutoriel destiné à des personnes ayant déjà un background en 
programmation, on s’entend.


QQun sur la liste qui pratique Rust depuis un certain temps, des 
opinions, premières impressions, commentaires?


Bon, j'ai finalement décidé de me pencher sérieusement sur ce nouveau 
langage, et voici mes commentaires :


- Un nième langage sensé résoudre les problèmes des 200 précédents.
- Encore un langage qui prétend qu'il va éviter les mauvaises habitudes 
et pratiques.
- Encore une syntaxe dont on détruit la simplicité pour introduire des 
choses compliquées qui pourraient se résoudre très simplement avec un 
peu de discipline.
- Encore un langage qui prétend que l'on peut programmer comme un pied 
mais que le compilateur va rendre ça tout propre.
- Encore un langage qui pense qu'en empruntant des concepts d'autres 
langages et en les combinant dans un seul c'est une grande idée qui va 
marcher.


En gros, un langage qui commence avec des choses simples et qui devient 
de plus en plus touffu au fil des fonctionnalités. Beaucoup d'emprunts à 
Python, sans en avoir la logique ni la simplicité.


Il y a 30 ans, j'ai écrit une librairie qui me permettait d'éviter les 
problèmes de dépassement de pile, le déréférencement des pointeurs 
accidentel et la gestion, et debugging, de la gestion dynamique de la 
mémoire en C (et je n'ai plus jamais eu de bus error, des segmentation 
fault, etc.). Pourquoi faut-il un nouveau langage pour résoudre ce 
problème ? Croire qu'un langage va résoudre le manque de discipline et 
les mauvaises pratiques relève de la naïveté.


je vais donc continuer à faire du Python et du C lorsque j'ai besoin de 
performance. Et je vais aussi continuer à utiliser massivement les 
pointeurs multiples et l'allocation dynamique de la mémoire en C, mais 
en utilisant des méthodes appropriées et de l'autodiscipline. Mais, je 
pense ne jamais utiliser ce langage qui, à mon humble avis, n'apporte 
rien d'intéressant.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Will Microsoft Ban Commercial Open Source from Its App Store?

[Daniel Cordey via gull]

Vous pensez que M* a déjà fait tout ce qu'ils pouvaient pour limiter 
l'usage des logiciels libre et/ou Open-SOurce (FOSS) ? Vous aviez tord, 
M* n'est jamais à cours d'idée dans ce domaine  :


https://news.slashdot.org/story/22/07/09/0247213/will-microsoft-ban-commercial-open-source-from-its-app-store

Je disais que je ne ferais jamais confiance à cette société... et 
j'avais bien raison :-)


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] SFC Urges Developers to Quit GitHub

[Daniel Cordey via gull]

C'est bien ce que j'ai toujours dit... On ne peut pas leur faire 
confiance :-(


https://linuxiac.com/sfc-urges-developers-to-quit-github/

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: The End of the Privacy of Digital Correspondence

[Daniel Cordey via gull]

Le 05.07.22 à 17:56, PirBoazo via gull a écrit :

hello,

Même le conseil fédéral s'en emeut.


https://www.ictjournal.ch/news/2022-06-27/le-conseil-federal-dit-sa-perplexite-quant-au-projet-europeen-de-surveillance-des


Si même le CF arrive à comprendre qu'il y a un blème... C'est que c'est 
vraiment très gros :-)


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: [SPAM] twitter, vmware

[Daniel Cordey via gull]

Le 26.05.22 à 21:32, Philippe Strauss via gull a écrit :


J'ose te demander de nous expliquer les deux choses suivantes, que je
ne comprends fondamentalement pas:


Pas de problème. Mais comme c'est est un peu "hors sujet" pour a liste, 
je propose d'envoyer cette réponse uniquement à ceux qui le demande et 
en-dehors de la liste du Gull. Donc, si vous désirez recevoir mes 
explications, envoyez-moi un mail et je vous inclurai dans la liste de 
distribution.


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] twitter, vmware

[Daniel Cordey via gull]

Le 26.05.22 à 15:27, Philippe Strauss via gull a écrit :

on est pas à nouveau dans une bulle internet avec twitter valant 44
milliards et VMware 61 milliards??
me paraît de ces chiffres énnnoormes! (mais chuis pas
économiste).
la publicité me paraît tellement sur-évaluée!

https://www.reuters.com/markets/us/chipmaker-broadcom-buy-vmware-61-bln-deal-2022-05-26/

(PAN PAN AGG!)


Si, si... cela fait un moment que l'on rejoue le boum des dot-com (mars 
2000). Ce genre de situation dangereuse se détecte lorsque des sociétés, 
ne faisant pas de profit, ont d'énormes capitalisations boursières et 
que l'on avance des PER (Price Earning Ratio) atteignant des sommets. 
Or, il y a quelques temps, j'ai détecté que l'on ne publie plus les PER 
quotidien des sociétés, mais une moyenne mobile (12 mois) de de 
celle-ci. Cela indique clairement que l'on ne veut pas que les gens se 
rendent compte qu'il y a une bulle et que l'on cherche à attirer les 
"petites mains" dans le marché, afin que les gros puissent prendre leurs 
profits juste avant que ces dernières se prennent le bouillon.


Depuis son plus haut de novembre 2021, le NASDAQ  s'est déjà pris 27% 
dans les dents... Les banques centrales (FED & BCE) ayant imprimé de 
l'argent comme des malades depuis des années, cette masse d'argent 
artificiel est arrivé directement dans les marchés boursiers. Il va bien 
falloir absorber cette bulle de liquidité d'une manière ou d'une 
autre... La fin des QE (Quantitative easing) de la FED et la BCE a 
marqué la fin de la récréation dans les marchés boursiers... La hausse 
des taux va leur filer un dernier coup sur la tête. On n'a pas fini de 
rigoler :-)


Depuis 2013 (date de l'entrée en bourse), Twitter n'a jamais fait de 
profit sauf en 2018 et 2019. Le reste du temps ils ont perdu de l'argent 
et continuent à en perdre. Le PER de Twitter est négatif depuis des 
années (~200 entre 2017 et fin 2021). Jusqu'à la fin des années 90, les 
valeurs de rachat d'une société représentait ~3 fois dont chiffre 
d'affaire. Mais depuis la folie des dot-com, il est devenu courant de 
voir que des entreprises soient rachetées avec des ratios... disons... 
assez incompréhensible. Les "market cap" des entreprises n'ont plus 
beaucoup de sens et nous sommes en train de regarder un gigantesque 
château de carte. On est un peu dans la situation du "coyotte" (bip-bip) 
qui continue à courir après avoir dépassé le bord de la falaise... 
jusqu'au moment où il se rend compte qu'il cours au-dessus du vide... :-)


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Duckduckgo

[Daniel Cordey via gull]

Le 25.05.22 à 17:48, Philippe Strauss via gull a écrit :


fragment de "imagine" de john lennon, cela traduit, en français: "rien
d'intéressant"
zarb!

essayez voire chez vous, "nothing to kill or die for", et donnez-moi la
traduction que vous obtenez.


:-) :-) :-) Même résultat chez moi avec Google translate. Or, si 
j'utilise deepl.com, j'obtiens : rien à tuer ou à mourir


EN fait, le résultat de Google est juste ! Celui de Deepl n'est pas bon...

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Duckduckgo

[Daniel Cordey via gull]

Le 25.05.22 à 12:39, Paul Bartholdi a écrit :


- Si on observe le trafic à l'entrée d'un serveur web on voit que les 
"renifleurs" occupent une grande place. Ne serait-il pas alors 
écologiquement raisonnable de n'avoir qu'un seul renifleur mondial où 
les "petits" viendraient se servir, comme Duckduckgo le fait avec 
bing, en mettant leurs talents dans la présentation des trouvailles ?  
C'est volontairement un peu provocateur !


J'ai un bloqueur d'adresses IP et j'ai bloqué facebook et twitter... La 
différence est incroyable... chute vertigineuse des spams...




Bon pont pour ceux qui peuvent en profiter !      Paul  (je suis à la 
retraite, dont "pont" connais plus)


Dans le même cas... je fais le pont 7 jousr sur 7... Quand je 
travaillais, je n'avais pas une minute, maintenant que je suis à la 
retraite, je n'ai plus une seconde...


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Duckduckgo

[Daniel Cordey via gull]

Le 25.05.22 à 13:45, Marc SCHAEFER via gull a écrit :

Il se peut aussi que Google, grâce à ton profil anonyme, voire ta
connexion, adapte les résultats de recherche à ce qui t'intéresse.

Absolument. J'en suis conscient et je le vois bien.

Je recherche principalement des infos liées à Python et aux technologies 
informatiques (algorithmes, etc.). Donc, Google me "sélectionne" bien ce 
que je recherche. Le modèle d'affaire de Bing est un peu différent et 
biaise vraiment les résultat vers des entreprises encore plus 
mercantiles qu'avec Google, car la plupart sont aussi liées à des 
produits M*, ce qui n'est pas le cas de Google.



On est parfois surpris de voir que les résultats Google sont assez
différents sur la machine de quelqu'un d'autre.


Exact ! Ou lorsque tu fais une recherche habituelle depuis l'ordinateur 
de quelqu'un d'autre. La différence est flagrante.


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Duckduckgo

[Daniel Cordey via gull]

Je me demandais souvent pourquoi je ne trouvais pas ce que je cherchais 
rapidement avec Duckduckgo... Normal, ça utilise Bing... et maintenant 
j'apprends ce deal qu'ils on fait avec M* Donc, je bannis 
définitivement ce pseudo-moteur de recherche... Peut-être que ça 
anonymise le premier niveau de recherche, mais ça utilise Bing qui n'est 
clairement pas comparable à Google et qui est bien plus biaisé que 
Google; entre autre :-(


https://www.reviewgeek.com/118915/duckduckgo-isnt-as-private-as-you-thought/

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: Fwd: [SPAM] VaudTax 2021

[Daniel Cordey via gull]

Le 05.03.22 à 11:26, gmaurer via gull a écrit :

Bonjour,

Sur mon UBUNTU 16.04 LTS, Vaudtax21 démarre normalement mais se plante 
lorsque je cherche à faire qqch.

Est-ce normal, ma version est trop vieille ou peut-on faire qqch ?


La 16.04 a 6 ans d'existence. Elle est maintenant en fin de support pour 
le hardware et les mises à jours de corrections de bugs et de nouvelles 
fonctionnalités. Seul les MAJ de sécurité sont garanties jusqu'en 2026. 
Ce qui fait que cette version a sans doute une version de la JRE qui 
n'est pas adéquate pour VaudTax2021, ni les bonnes librairies Webkit, 
etc. Bricoler une telle version pour pouvoir installé de nouvelles 
versions non supportées par la 16.04 me semble un non sens. Soit on 
accepte de ne pas mettre à jour son système avec les derniers goodies 
pour des questions de stabilité, mais introduire des trucs pas supportés 
dans un système que l'on veut très clean est antagoniste.


Perso, je ne suis vraiment pas favorable à cette approche des systèmes 
que l'on ne reboot (même si on reboot !) pas pendant des années et qui 
posent de plus en plus de problèmes au fur et à mesure que le temps 
passe. Je fais la MAJ de tous mes système basés Ubuntu en avril et 
octobre de chaque année, et je n'utilise pas de LTS; je tourne aussi un 
kernel 5.17 rc6. C'est ma stratégie depuis près de 10 ans et je n'ai 
jamais eu un seul problème. C'est aussi valable pour mes système de 
production. Attendre longtemps entre deux versions, engendre des tas de 
petits problème... c'est comme si on accumulait le problèmes pour les 
avoir tous au même moment. Souvent ces problèmes sont liés à des 
changements de syntaxe dans des fichiers de configuration et il n'y a 
pas forcément de messages d'erreur; et en production c'est très pénible 
et stressant.


Une possibilité serait de créer un conteneur (docker) avec une image 
plus récente, juste pour tourner VaudTax, sans devoir changer le système 
de base.


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Fwd: [SPAM] VaudTax 2021

[Daniel Cordey via gull]

Le 03.03.22 à 20:31, bjo via gull a écrit :

Hello,

La solution est une petite modification du script de démarrage qui 
référence la mauvaise librairie.


Voir: https://swisslinux.org/forum/viewtopic.php?pid=32881#p32881


En effet, merci ça fonctionne !

J'avais essayé de créé un lien symbolique mais ça n'avait pas 
fonctionner. Je ne comprend pas pourquoi ils incluent deux fois la même 
librairie avec deux noms différents, dans un répertoire, alors que le 
script fait une recherche dans un autre répertoire... C'est plus que 
bizarre. Je suis aussi d'accord avec toi quand tu t'étonnes qu'ils 
n'aient pas essayer de tester leur code... Gageons par contre qu'ils ont 
testé les 5 versions différentes pour W*.


Merci pour ton aide

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Hackers now demand NVIDIA should make their drivers open source or they leak more data

[Daniel Cordey via gull]

Le fond de l'affaire est répréhensible, mais la demande ne me déplaît 
pas et me semble un juste retour des choses, vu que Nvidia se moque des 
utilisateurs et des logiciels libres depuis bien trop longtemps.



https://videocardz.com/newz/hackers-now-demand-nvidia-should-make-their-drivers-open-source-or-they-leak-more-data

A+

dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] VaudTax 2021

[Daniel Cordey via gull]

Re bonsoir,

Le 02.03.22 à 22:35, Daniel Cordey via gull a écrit :


Il me dit avoir besoin de la libwebkit2gtt, disant qu'il ne la trouve 
pas et que je dois l'installer. Sauf, que j'ai déjà la nouvelle 
version. Décidément, chaque fois que j'ai affaire à Java, je ne peux 
que constater que j'ai eu raison dès le premier jour...


En fait la libwebkit2gtk-4.0. Cette librairie est bien dans le 
répertoire de recherche, mais je pense qu'il attend un autre nom...



dc@dcmalx2:~/tmp/bash$ ll 
/home/dc/VaudTax2021/VaudTax_2021-1.2-production-64bit/lib/ubuntu/usr/lib/x86_64-linux-gnu

total 112M
-rwxrwxr-x 1 dc dc  56M jui 27  2021 libwebkit2gtk-4.0.so.37*
-rw-r--r-- 1 dc dc  56M jui 27  2021 libwebkit2gtk-4.0.so.37.53.4
drwxr-xr-x 3 dc dc 4.0K mar  2 22:18 webkit2gtk-4.0/
dc@dcmalx2:~/tmp/bash$

Fournir toute le code en incluant les librairie, et ne pas être capable 
de trouver les fichiers... faut le faire ! Et le pire, les deux fichiers 
de librairie sont absolument identiques (cksum), mais on se tape le 
téléchargement de deux fois 56 MB...


dc@dcmalx2:~/VaudTax2021/VaudTax_2021-1.2-production-64bit/lib/ubuntu/usr/lib/x86_64-linux-gnu$ 
cksum lib*

180269626 58418736 libwebkit2gtk-4.0.so.37
180269626 58418736 libwebkit2gtk-4.0.so.37.53.4
dc@dcmalx2:~/VaudTax2021/VaudTax_2021-1.2-production-64bit/lib/ubuntu/usr/lib/x86_64-linux-gnu$

et chaque fichier a des droits d'accès différents. Ces mecs sont 
vraiment très très forts...


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] VaudTax 2021

[Daniel Cordey via gull]

Hello,

C'est chaque année la même histoire. VaudTax qui est écrit avec ce 
magnifique langage qu'est Java, promettant de "Write once, run 
everywhere", fait une nouvelle fois la démonstration du contraire : 
"Write painfully, runs nowhere"...


Il me dit avoir besoin de la libwebkit2gtt, disant qu'il ne la trouve 
pas et que je dois l'installer. Sauf, que j'ai déjà la nouvelle version. 
Décidément, chaque fois que j'ai affaire à Java, je ne peux que 
constater que j'ai eu raison dès le premier jour...


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] norme ISO2022 et QR pour paiements

[Daniel Cordey via gull]

Le 16.02.22 à 09:06, felix via gull a écrit :

Re,

Le truc, à partir de là, je ne sais pas trop!

  - Dois-je faire un CSV ou plutôt un XML genre pain001.xml

My two cents.

CSV. C'est ce qu'il y a de plus courant et peut-être utilisé par plein 
d'outils et programmes... Toujours lisible et facilement transformable. 
Alors que XML requiert souvent une application dédiée et est très 
pénible à lire, en plus d'occuper beaucoup plus d'espace.


dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: norme ISO2022 et QR pour paiements

[Daniel Cordey via gull]

Le 11.02.22 à 14:26, felix via gull a écrit :

Bonjour,

J'ai créé un petit script pour scanner les QR SPC (Swiss Payment Code):
   https://f-hauri.ch/vrac/getQrSpcCam.sh.txt
   https://f-hauri.ch/vrac/getQrSpcCam.sh

Il dépend de deux-trois utilitaires connexes: zbarcam (V >= 0.23.1), wmctrl,
xdotool, ncurses-bin et ogg123.


Wow... top !

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: C'est énorme!

[Daniel Cordey via gull]

Le 11.02.22 à 15:47, felix via gull a écrit :

J'exagère pas; Google et FB semblent déjà le faire, pour le compte de
l'U.E., et c'est une I.A. qui se charge du premier tri, non pas par mot
clé mais par "sémantique clé".

... Pour le compte de l'UE ou pour n'importe qui, tant qu'il paie!
Ce sont des mercenaires! (dans une guerre technologique)

A part quelques ovins, trop contents de jouer au futures méchoui-party  
des politiciens, la plupart des gens en ont marre de tout ça... mais ne 
sait plus comment en sortir. Et pourtant, c'est nous qui avons mis ces 
gens en place en votant pour eux... :-)


dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Une juriste traduit les CGU d'Instagram pour les enfants (et les adultes)

[Daniel Cordey via gull]

On 02/02/2022 09:26, felix via gull wrote:

...
 "Nous pouvons t'obliger à abandonner ton nom d'utilisateur, sans
  raison particulière".




Quel monde merveilleux... D'éminent pédagogues ont passé leur vie à 
formaliser les étapes de l'aprentissage chez l'enfant dans sa quête de 
devenir adulte. Ils ont très bien décrit toutes ces étapes et surtout à 
partir de quand un enfant est capable de comprendre certaines choses. 
Entre autre, les capacités d'abstractions, l'ironie, etc. ne sont pas 
perçues ou comprises avant un certain âge, mais en tout cas pas à 7 ou 8 
ans !


Ce texte en dit long sur la cupidité de ces entreprises (toutes) et le 
cynisme des juristes et des dirigeants. Que l'on tolère de tels 
agissemenst en dit aussi long sur la compromission, l'égoïsme, la bêtise 
et l'inculture de notre société et de nos politiciens. Facebook fait la 
même chose en ce qui concerne les photos... mais le nombre d'utilisateur 
des ces plateformes démontre le niveau de bêtise de la population... 
mais ça ce n'est pas nouveau. "Panem et circenses" !


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] [SPAM] Re: rsync, attention a l'option -t

[Daniel Cordey via gull]

On 31/01/2022 16:49, felix via gull wrote:

Bonjour Frédéric,

oui, cependant, afin d'éviter que des fichier modifié, ayant conservé
la même taille ne sombrent dans l'oubli,  perso j'aurrais fait, ( depuis
  le serveur source):

ssh target /bin/sh <<<'cd path/to/target &&
 find . -type f -exec sha1sum {} +' >/tmp/sha1sum.txt

cd path/to/source
LANG=C sha1sum -c Perso, je décommande ce genre de manip à la volée. Les chances que ça 
marche du premier coup sont... vraiment très faible, et une erreur 
(suivant ce que l'on a à faire et l'utilisation de variable vide suite à 
un typo) peut avoir des conséquences catastrophiques.


Donc, je recommande de développer le code dans un script localement, de 
le tester (en mettant 'echo' devant sed par exemple), et en copiant le 
script une fois testé sur le serveur d’exécution... puis de le lancer 
avec la commande ssh target my_script.


Tout ceci ne changeant en rien la séquence décrite  par Félix.

Aussi, attention avec LANG... Il est préférable de préciser la langue 
utilisée correctement (fr, en, ...), ainsi que l'encodage... (latin-2, 
ISO8859-1, UTF-8, ...) sinon gare aux surprises. Exemple LANG=en_CH.UTF-8


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Fwd: OIN

[Daniel Cordey]

On 23.11.21 10:36, Marc SCHAEFER wrote:

PS: j'ai écrit à gull-owner pour expliquer quoi modifier sur la config
de la liste pour mieux supporter le SPF des domaines tiers relayés.


Merci pour tes explications et ton action.

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Fwd: OIN

[Daniel Cordey]

En effet, la liste ne publie pas lorsqu'elle est en "cc".


 Forwarded Message 
Subject:Re: [gull] OIN
Date:   Sun, 21 Nov 2021 00:16:26 -0500
From:   Richard Stallman 
Reply-To:   r...@gnu.org
To:     Daniel Cordey 
CC: gull@forum.linux-gull.ch



[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Il y a une organisation européenne, FFII, qui essai d'opposer le
brevet unitaire. Elle a besoin d'appui. Je ne sais pas si ça
concerne la Suisse, mais en tout cas, je prie tous qui puissent
l'aider de le faire.

--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)


--
*Daniel Cordey*
Chief Executive Officer
logo
Phone : +41 76 221-3704
email : d...@pxcluster.com___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Fwd: OIN

[Daniel Cordey]

 Forwarded Message 
Subject:Re: [gull] OIN
Date:   Sun, 21 Nov 2021 00:16:26 -0500
From:   Richard Stallman 
Reply-To:   r...@gnu.org
To: Daniel Cordey 
CC: gull@forum.linux-gull.ch



[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Il y a une organisation européenne, FFII, qui essai d'opposer le
brevet unitaire. Elle a besoin d'appui. Je ne sais pas si ça
concerne la Suisse, mais en tout cas, je prie tous qui puissent
l'aider de le faire.

--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] OIN

[Daniel Cordey]

On 19.11.21 05:43, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Ce que le Open Innovation Network fait est utile.  C'est la seule
initiative qui a réussi à nous protéger d'un tas de brevets
informatiques.  Elle ne vise pas à curer l'injustice de base des
brevets informatiques, mais elle est beaucoup mieux que rien.

Merci beaucoup à M. Stallman pour cet encouragement à poursuivre la 
lutte contre les brevets logiciels !


A tous les membres du Gull lisant cette liste :

N'hésitez pas à vous inscrire à la Free Software Foundation  : 
(https://fsf.org)


Daniel Cordey
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] TOP 500

[Daniel Cordey]

Ha, ha, MDR... M* tourne Ubuntu 18.04 sur son nouveau HPC. A quand 
"Windows Server" sous Linux ? :-)


https://www.zdnet.com/article/microsoft-now-has-one-of-the-worlds-fastest-supercomputers-and-no-it-doesnt-run-on-windows/

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] OIN

[Daniel Cordey]

On 17.11.21 09:19, felix wrote:

Bon sang que c'est difficile de trier le bon grain!

J'aimerais savoir ce qu'en pense RMS, j'aime moyennement le contenu de
https://openinventionnetwork.com/community-initiatives/members-speak-out/

Limite l'impression qu'entre la ``linux foundation'' et ce genre d'initiative,
on cherche à discrediter GNU en particulier... Ce n'est peut-être qu'une
impression et on espère que je me gourre, mais 'faudra m'expliquer pourquoi IBM,
Google, Nec, Toyota, la ``Fondation Linux'', Philips, Sony, Suse, et encore une
étude juridique et enfin Microsoft, soutiennent cette initiative, alors qu'on 
n'y
voit pas le bout de la barbe de rms.

On va dire que je suis parano, mais je la sens moyen, celle là.


Il est vrai qu'il y a des trucs bizarres avec la Fondation Linux depuis 
quelques années. Mais c'est quoi GNU en fait ? Une association, une 
entreprise ? Une religion ? Une fondation ? C'est plutôt un mouvement et 
il est donc difficile de le rattacher en tant qu'entité à quelque chose 
du genre de OIN. C'est aussi vrai pour d'autres trucs comme Open Compute 
Project, etc.


Je ne vois pas là de dénigrement de GNU. OIN mentionne Linux, mais là 
aussi c'est très flou car Linux n'est pas non plus une entité très 
claire... De plus, Linux repose sur les licences GPL pour la grande 
majorité du code. Mais, par extension, cela englobe plein d'autre choses 
qui se trouvent sur et autour de Linux et utilisant des licences variées 
et plus ou moins libres.


OIN cherche à protéger les logiciels des brevets abusifs et c'est déjà 
une grosse étape dans la bonne direction. Ce qui n'empêche pas M* 
d'utiliser des société comme proxy pour faire du "patent trolling", mais 
ne jetons pas le bébé avec l'eau du bain.


dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] OIN

[Daniel Cordey]

Bonjour à tous,

OIN... Sans doute le meilleur moyen de lutter contre les brevets logiciels !

https://www.zdnet.com/article/bilibili-chinas-youtube-joins-the-open-invention-network/

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Bon livre sur C++

[Daniel Cordey]

On 18.10.21 19:03, Philippe Strauss wrote:

Hello les gullinois,

Je cherche à acquérir un bon livre sur C++, que recommandez-vous pour un 
programmeur C ansi se débrouillant pas trop mal, python et ocaml idem.
Je cherche un livre allant directement dans le vif du sujet, mis a jour 
récemment pour C++20 si possible, peut-être que le o'reilly « in a nutshell » 
ferait l’affaire si il n’était pas aussi vieux.
J’adore le python in a nutshell et le C par kerninghan et Ritchie (le langage 
C).


Ah le petit bouquin blanc de K du langage C, 10mm d'épais... une 
référence. J'ai toujours pensé qu'un livre d'un langage qui avait besoin 
de plus de 10mm d'épais était un mauvais langage... :-)


Ma référence pour le C++ reste (je fais une consession... 15mm) :

https://through-the-interface.typepad.com/.a/6a00d83452464869e20224e03dadc0200d-pi

Et pour Python, c'est "Python Essential Reference" de David Baezley

Pour toutes les nouveautés, je m'en réfère aux différents site pointant 
vers la doc de référence du langage et ses dernières évolutions; dont :


docs.python.org

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Truc et astuces: Lire un CSV en bash

[Daniel Cordey]

On 18.10.21 09:42, felix wrote:

Ça f'sait longtemps que je n'ai pas posté un truc...

Il s'agit de lire un fichier CSV conforme au
  RFC 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files


Bon... S'il existe un RFC, celui-ci laisse aussi la porte ouverte 
concernant les "implémentations" qui peuvent varier et qui n'entrent 
donc pas dans la définition de ce standard. Entre autre, la doc du RFC 
4180 dit clairement :


Interoperability considerations:

  Due to lack of a single specification, there are considerable
  differences among implementations.  Implementors should "be
  conservative in what you do, be liberal in what you accept from
  others" (RFC 793    [8  
]) when processing CSV files.  An 
attempt at a
  common definition can be found inSection 2  
.

Aussi, la documentation du module bash CSV dit aussi :

*This method is recommended only for simple CSV files*with no text fields containing extra comma|,|delimiter, or return lines. For more complex CSV support, see the next 
section toparse CSV with AWKicon mdi-link-variant  .


J'avais d'ailleurs immédiatement pensé à AWK lorsque j'ai vu ton exemple :-)

En regardant plus en détail le module CSV de Python, j'ai trouvé ce qui 
suit :


/class/|csv.||Dialect|

   The|Dialect|
   class is a
   container class whose attributes contain information for how to
   handle doublequotes, whitespace, delimiters, etc. Due to the lack of
   a strict CSV specification, different applications produce subtly
   different CSV data.|Dialect|
   instances
   define how|reader|
   and|writer|
   instances behave.

   All available|Dialect|
   names are
   returned by|list_dialects()|
   , and
   they can be registered with specific|reader|
   and|writer|
   classes
   through their initializer (|__init__|) functions like this:

   import  csv

   with  open('students.csv',  'w',  newline='')  as  csvfile:
writer  =  csv.writer(csvfile,  dialect='unix')
 ^^

Ma conclusion est qu'une implémentation en Python nous mettra mieux à 
l'abri des variantes de CSV, en étant capable d'écrire une code plus 
lisible et évitant de gonfler le code pour traiter les cas spéciaux.



Depuis un moment, on peut utiliser des modules chargeables dans bash, dans
l'arborescence de la distribution, il y a un dossier d'exemples, avec
de nombreux modules chargeables.


Merci pour cette info. En effet, ces commandes sont exécutées plus 
rapidement que celles qui se trouvent dans /usr/bin en évitant de faire 
un fork/exec. C'est donc un vrai plus au niveau performance, en plus 
d'apporter des commandes qui ne se trouvent justement pas en standard 
(comme csv).


dc
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] OT: Site web qui me manquait

[Daniel Cordey]

On 12.10.21 19:43, Philippe Strauss wrote:


Concernant la fonction publique, j’avais entendu un chiffre de 200.- CHF comme 
maximum pour accepter un cadeau de fin d’année.
Pas impossible que cela soit le maximum pour les conseillers fédéraux au delà 
duquel ils sont censé refuser le cadeau?


Cela dépend des cantons et des communes. Mais la règle général voudrait 
que tout cadeau soit déclaré et partagé. Chacun fixe ses règles comme il 
l'entend. Les entreprises privées sont devenues très strictes et on peut 
tout juste accepter un stylo ou une clef USB (qui contient peut-être un 
malware :-)). J'aurais tendance à dire qu'aujourd'hui, le privé est plus 
stricte que les administration et l'état (en général). Le problème 
réside dans la gouvernance et le contrôle; et il semble que le monde 
politique soit peu enclin à mettre en place des contrôles. Il existe un 
contrôle des finances à la confédération et qui fait bien son travail, 
mais ils sont sans doute en sous effectifs... pour qu'ils ne soient pas 
trop efficaces. Et nous avons la FINMA... qui semble n'avoir engager que 
des mal voyants; au point qu'ils ont eu besoin des Américains pour 
découvrir qu'il y avait des fraudes et du blanchiment à la FIFA :-)



Par contre je ne suis pas convaincu que la justice, de manière générale en 
suisse, s’intéresse beaucoup aux pots de vin, surtout dans le privé, j’ai une 
impression de laisser faire dans ce domaine.


Ce n'était pas un délit pénal et pouvait même être déduit des impôts 
jusqu'il y a peut. La loi a été changée, mais encore faut-il mettre des 
moyens pour attraper les fraudeurs.


Comme l'a dit Marc, le parlement fédéral n'est pas vraiment favorable à 
la transparence et ça permet de continuer à parler de lobbying avec la 
bouche en cul de poule.



En 2012, je me souviens avoir pêter un câble à propos du peu d’affaires de 
corruption reportée par la presse dans notre petite suisse romande ronronnante. 
En 10 ou 15 ans, je n’avais vu passer qu’une d’un chef chauffagiste de l’EPFL 
et un municipal (de gauche) veveysan.
Un fonctionnaire qui remue un peu trop la marmite risque son poste... 
raison sans doute pour laquelle ce swiss-leak existe.

50'000 USD pour moi c'est déjà de la corruption par métier.


Sauf erreur, cette définition n'existe pas dans le code pénal Suisse. 
Seul est reconnu la corruption active ou passive.



D'un autre côté, cela peut aussi être un soutien bienvenu pour exercer
un métier de journaliste dans des conditions difficiles!


Oui, à condition  de ne pas être manipulé.


En Suisse, on bénéficierait fortement d'une meilleure transparence du
financement des partis politiques et d'une meilleure protection des
lanceurs d'alertes -- mais ça semble être difficile à avaler pour la
droite du parlement.

Si ce n'était que la droite ça serait merveilleux :-)

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Lettre de la FSF

[Daniel Cordey]

Bonsoir à tous,

Voici le dernier mail de la Free Software Foundation, qui nous parles 
des nouvelles restrictions des libertés logicielles et personnelles que 
l'on trouve dans la nouvelle version Windows 11. Je vous mets le lien 
vers ce texte en anglais, et je joins aussi une version française que 
j'ai simplement passé dans Deepl. Toutefois, seuls les 5'000 premiers 
caractères de l'article ont été traduits, car je n'ai pas de compte chez 
Deepl. Vous pourrez certainement traduire le reste vous même.


Tout ceci afin de rappeler que l'on ne doit pas oublier ce qu'est 
véritablement un logiciel libre.


dc

https://www.fsf.org/news/lifes-better-together-when-you-avoid-windows-11

Le 5 octobre marque la sortie officielle de Windows 11, une nouvelle 
version du système d'exploitation qui ne fait rien du tout pour contrer 
la longue histoire de Windows qui prive les utilisateurs de liberté et 
d'autonomie numérique. Bien que nous ayons pu être encouragés par les 
slogans vagues et aspirationnels de Microsoft sur la communauté et la 
convivialité, Windows 11 fait des pas importants dans la mauvaise 
direction en ce qui concerne la liberté des utilisateurs.


Microsoft affirme que "la vie est meilleure ensemble" dans sa publicité 
pour cette dernière version de Windows, mais en matière de technologie, 
il n'y a pas de moyen plus sûr de maintenir les utilisateurs divisés et 
impuissants que les logiciels non libres. Développer des logiciels non 
libres est un acte antisocial en soi, car c'est choisir 
intentionnellement de créer une structure de pouvoir injuste, dans 
laquelle un développeur maintient sciemment les utilisateurs dans 
l'impuissance et la dépendance en retenant des informations. De plus en 
plus, cela implique non seulement la rétention du code source lui-même, 
mais aussi des informations de base sur le fonctionnement du logiciel : 
ce qu'il fait réellement, ce qu'il collecte et la fréquence à laquelle 
il moucharde les utilisateurs. "Moucharder" peut sembler dramatique, 
mais Windows 11 exigera désormais qu'un compte Microsoft soit connecté à 
chaque compte d'utilisateur, ce qui lui donnera la possibilité de 
corréler le comportement de l'utilisateur avec son identité personnelle. 
Même ceux qui pensent n'avoir rien à cacher devraient se méfier de 
l'idée de partager potentiellement toute leur activité informatique avec 
une entreprise, et encore moins avec une entreprise ayant des 
antécédents d'abus comme Microsoft.


Vous avez peut-être entendu dire que des milliers de machines 
fonctionnant actuellement sous Windows ne seront pas autorisées à passer 
à Windows 11 en raison d'une incompatibilité matérielle. À première vue, 
cela ressemble à une simple obsolescence forcée, mais la réalité est 
bien plus sinistre. Windows 11 exige désormais l'utilisation d'une 
petite puce dédiée fixée à la carte mère de l'ordinateur, appelée TPM, 
que la publicité et la presse grand public appellent "Trusted Platform 
Module". Ce terme est légèrement trompeur, car lorsqu'il est déployé par 
une société de logiciels propriétaires, sa relation avec l'utilisateur 
n'est pas basée sur la confiance, mais sur la trahison. Lorsqu'il est 
entièrement contrôlé par l'utilisateur, le TPM peut être un moyen utile 
de renforcer le cryptage et la confidentialité de l'utilisateur, mais 
lorsqu'il est entre les mains de Microsoft, nous ne sommes pas optimistes.


Nous nous attendons à ce que Microsoft utilise son contrôle plus strict 
sur la cryptographie qui se produit dans Windows comme un moyen 
d'imposer une gestion des restrictions numériques (DRM) plus sévère sur 
les médias et les applications, et comme un moyen de s'assurer qu'aucune 
application ne peut fonctionner dans Windows sans l'approbation de 
Microsoft. Dans de tels cas, il n'est plus approprié d'appeler une 
machine exécutant Windows un ordinateur "personnel", car elle obéit 
davantage à Microsoft qu'à son utilisateur. Il est d'ailleurs amèrement 
ironique que Microsoft appelle le programme qui vérifie la compatibilité 
d'un système avec Windows 11 "PC Health Check". Nous répondons qu'un PC 
sain est un PC qui respecte les souhaits de son utilisateur, qui exécute 
des logiciels libres et qui ne les restreint pas délibérément par une 
informatique perfide. Il ne renverra jamais non plus les clés de 
chiffrement de l'utilisateur à ses supérieurs. Les utilisateurs 
intrépides trouveront probablement un moyen de contourner cette 
exigence, mais cela ne change rien au fait que la majorité des 
utilisateurs de Windows seront contraints de se plier à un système 
d'informatique déloyale.


Microsoft sait que son programme de vidéoconférence "Teams" n'est pas 
l'application la plus appréciée au monde, car même les utilisateurs de 
Windows optent généralement pour une alternative plus populaire (bien 
que profondément problématique) comme Zoom. Aujourd'hui, il semble 
qu'aucun utilisateur de Windows ne puisse plus l'éviter, puisqu'il s'est 
vu attribuer une place 

Re: [gull] Virus no 48

[Daniel Cordey]

On 05.10.21 17:39, felix wrote:

Salut,

Pour vous dire que le numéro 48 du virus informatique, sorti en août,
va bientôt être retiré des rayons... Pour ceux qui l'aurraient loupé!


Y'avait quelque chose de spécial dans ce numéro ?



Attention, son prix à augmenté de 50%  ( Insuffisant à mon avis! ;)

C'est quoi ce bordel ?


...

Bon, si je dois être qualifié de spammeur, autant faire de la pub!


Non, ça va :-)

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Le nombre d'utilisateurs de Linux sur desktop ne cesse de croître tandis que celui de Windows baisse avec Linux : 10,92 % de progression par an, Windows : -1,95 % par an, sur les 12 derniè

[Daniel Cordey]

On 30.09.21 12:55, Miçhael Parchet wrote:

https://linux.developpez.com/actu/318602/Le-nombre-d-utilisateurs-de-Linux-sur-desktop-ne-cesse-de-croitre-tandis-que-celui-de-Windows-baisse-avec-Linux-10-92-pourcent-de-progression-par-an-Windows-moins1-95-pourcent-par-an-sur-les-12-dernieres-annees/


Merci, intéressant... Mais ce genre de stat ne reflète pas forcément la 
réalité. Statcounter ne mesure pas tous les accès, etc. C'est assez 
compliqué de déterminer la part de marché de W*. W* compte les licences 
vendues... alors que l'on essaie de déterminer qui utilise Linux. Ce 
sont deux choses bien différentes, sachant que certains utilisateurs 
installent Linux à la place de W* (mon cas) ou en dual-boot (ce qui ne 
peut pas être détecté).


Il y a aussi Chromebook qui représente plus de 30 millions de vente sur 
les 12 derniers mois, et je ne suis pas sûr que ces ordinateurs soient 
comptabilisé dans Linux Desktop.


Et finalement, la notion de Desktop évolue et va continuer à évoluer. On 
va avoir de plus en plus des terminaux intelligents, ne nécessitant pas 
un OS aussi lourd que W* ou Linux. Microsoft l'a d'ailleurs très bien 
compris avec leur offre O365; ça fonctionne bien et ils gardent les 
utilisateurs captifs sans imposer l'OS.


Le monde va devenir WebApp et nous n’aurons plus besoin d'un OS sur un 
matériel complexe... Donc, la guerre des OS est jouée... elle s'est 
déplacée vers les serveurs.


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Team$

[Daniel Cordey]

Pardon, 10 c'est bon ! Erreur...

⁣Télécharger BlueMail pour Android ​

Le 31 août 2021 à 11:42, à 11:42, Daniel Cordey  a écrit:
>Pour infos, W* 8 et 10 ne sont plus supportées par M* !!! Donc pas de
>patchs de sécurités... Et pas de support. Cela concerne aussi Outlook.
>
>⁣Télécharger BlueMail pour Android ​
>
>Le 31 août 2021 à 09:13, à 09:13, felix  a écrit:
>>Bonjour,
>>
>>A l'heure des conférences web, certains de mes clients se doivent de
>>collaborer
>>avec des entité tierces, et reçoivent des invitation pour des
>>conférences team$
>>par mail, qui sont censées s'inscrire ``automatiquement'' dans
>>l'agenda...
>>
>>Malheureusement, certains problèmes de compatibilité se posent avec
>les
>>outils
>>tels que thunderbird...
>>
>>L'idée serait d'installer office-365, avec outlook afin de pouvoir
>>échanger
>>avec les entreprises tièrces (basées sous ms) sans problèmes de
>>compatibilité,
>>mais en conservant l'infrastructure samba+postfix+cyrus-imap. (NB:
>Ceci
>>n'est
>>pas MON idée! ;)
>>
>>De là:
>>
>>- Mon client cherche des bras pour assumer l'installation et la
>>maintenance de
>>postes sous Window (8 à 10), qui seront connectés à une infrastructure
>>en
>>   logiciels libres (les candidats peuvent me contacter hors liste)
>>
>> - Tout commentaires sur le sujet est bienvenu... (évitons les
>trolls!)
>>
>>Merci de m'avoir lu jusqu'ici... En espérant n'avoir pas été filtré!
>>
>>--
>> Félix Hauri  --  http://www.f-hauri.ch
>>___
>>gull mailing list
>>gull@forum.linux-gull.ch
>>https://forum.linux-gull.ch/mailman/listinfo/gull
>
>
>
>
>___
>gull mailing list
>gull@forum.linux-gull.ch
>https://forum.linux-gull.ch/mailman/listinfo/gull
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Team$

[Daniel Cordey]

Pour infos, W* 8 et 10 ne sont plus supportées par M* !!! Donc pas de patchs de 
sécurités... Et pas de support. Cela concerne aussi Outlook.

⁣Télécharger BlueMail pour Android ​

Le 31 août 2021 à 09:13, à 09:13, felix  a écrit:
>Bonjour,
>
>A l'heure des conférences web, certains de mes clients se doivent de
>collaborer
>avec des entité tierces, et reçoivent des invitation pour des
>conférences team$
>par mail, qui sont censées s'inscrire ``automatiquement'' dans
>l'agenda...
>
>Malheureusement, certains problèmes de compatibilité se posent avec les
>outils
>tels que thunderbird...
>
>L'idée serait d'installer office-365, avec outlook afin de pouvoir
>échanger
>avec les entreprises tièrces (basées sous ms) sans problèmes de
>compatibilité,
>mais en conservant l'infrastructure samba+postfix+cyrus-imap. (NB: Ceci
>n'est
>pas MON idée! ;)
>
>De là:
>
>- Mon client cherche des bras pour assumer l'installation et la
>maintenance de
>postes sous Window (8 à 10), qui seront connectés à une infrastructure
>en
>   logiciels libres (les candidats peuvent me contacter hors liste)
>
> - Tout commentaires sur le sujet est bienvenu... (évitons les trolls!)
>
>Merci de m'avoir lu jusqu'ici... En espérant n'avoir pas été filtré!
>
>--
> Félix Hauri  --  http://www.f-hauri.ch
>___
>gull mailing list
>gull@forum.linux-gull.ch
>https://forum.linux-gull.ch/mailman/listinfo/gull
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Team$

[Daniel Cordey]

Il existe une application Teams pour Linux qui fonctionne bien. Elle couvre les 
chats, en vidéos,calendrier et tâches. Par contre... Pas de Outlook !

Dc

⁣Télécharger BlueMail pour Android ​

Le 31 août 2021 à 09:13, à 09:13, felix  a écrit:
>Bonjour,
>
>A l'heure des conférences web, certains de mes clients se doivent de
>collaborer
>avec des entité tierces, et reçoivent des invitation pour des
>conférences team$
>par mail, qui sont censées s'inscrire ``automatiquement'' dans
>l'agenda...
>
>Malheureusement, certains problèmes de compatibilité se posent avec les
>outils
>tels que thunderbird...
>
>L'idée serait d'installer office-365, avec outlook afin de pouvoir
>échanger
>avec les entreprises tièrces (basées sous ms) sans problèmes de
>compatibilité,
>mais en conservant l'infrastructure samba+postfix+cyrus-imap. (NB: Ceci
>n'est
>pas MON idée! ;)
>
>De là:
>
>- Mon client cherche des bras pour assumer l'installation et la
>maintenance de
>postes sous Window (8 à 10), qui seront connectés à une infrastructure
>en
>   logiciels libres (les candidats peuvent me contacter hors liste)
>
> - Tout commentaires sur le sujet est bienvenu... (évitons les trolls!)
>
>Merci de m'avoir lu jusqu'ici... En espérant n'avoir pas été filtré!
>
>--
> Félix Hauri  --  http://www.f-hauri.ch
>___
>gull mailing list
>gull@forum.linux-gull.ch
>https://forum.linux-gull.ch/mailman/listinfo/gull
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Australian court rules an AI can be considered an inventor on patent filings

[Daniel Cordey]

Apparemment les brevets logiciels n'étaient pas une idée déjà assez 
stupide, voilà que des idiots pensent que l'intelligence artificielle... 
c'est comme une personne ! On pensait avoir touché le fond... ben non !


https://www.theregister.com/2021/08/02/ai_inventor_allowed_in_australia/

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Who does that server really serve?

[Daniel Cordey]

Bonjour à tous et bonne fête du 1er août.

Intéressants commentaires de la FSF au sujet des services que l'on 
trouve dans le "cloud". Aussi explication de la raison pour laquelle on 
devrait parler de SaaSS, plutôt que de SaaS... je vous laisse lire 
l'article. Pour ceux qui ne parlent pas l'anglais, vous pouvez toujours 
utiliser "google translate" ou "deepl", qui sont en fait des services 
SaaSS :-)... ou vous mettre sérieusement à l'anglais (ce n'est jamais perdu)


https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

Cela m'a aussi permis de me remémorer un vieux problème, qui refait 
surface avec cette notion de SaaSS : 
https://www.gnu.org/philosophy/bug-nobody-allowed-to-understand.html


Bonne journée à toutes et tous.

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Administration: un rapport parlementaire prône le recours systématique au logiciel libre

[Daniel Cordey]

On attend d'avoir le même genre d'attitude de la part de nos 
administrations en Suisse :


https://www.zdnet.fr/blogs/l-esprit-libre/administration-un-rapport-parlementaire-prone-le-recours-systematique-au-logiciel-libre-39926175.htm

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Mise à jour du serveur

[Daniel Cordey]

On 12.07.21 09:33, Marc SCHAEFER wrote:


Ne serait-ce pas plus simple de repartir de zéro (un serveur web qui
sert de l'HTML statique, un serveur de mailing-list avec reprise de
l'historique) ?


Et surtout de faire évoluer la version Debian et son kernel. Parce que 
3.16... ça date un peu. Sauf erreur avec Debian 10 tu es en 4.19 il me 
semble.


dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Mise à jour du serveur

[Daniel Cordey]

On 12.07.21 08:11, Marc SCHAEFER wrote:

Dans certains rares cas (si peu de mémoire physique), il est plus
intéressant toutefois d'avoir le kernel en 32 bits que ce mode
hybride.
Exact ! Si l'on n'a pas d'application nécessitant plus de 3GB 
d'adressage pour les data (du programme), inutile se d’encombrer avec du 
64 bits. Ça dégrade l'utilisation des caches du CPU et diminue la bande 
passante RAM-CPU.

"The 64bit kernel can be installed on Debian 32bit. You can see that the
amd64 kernel is available for 32bit Debian on it's package page. This
can be used as an alternative to using a PAE enabled kernel to support
more than 4G of total RAM. Note that 32bit binaries still can not access
more than roughly 3G of RAM per process."
En plus, ça ralenti un peu l'exécution, car il faut émuler le "space 
register" 64 bits. Mais il me semble que tous les CPUS manipulent de 
l'adressage virtuel en 48 bits depuis très longtemps... Non ?


@Félix : Quel est le CPU physique (celui du host) ? Est-ce un 32 bits ou 
un 64 bits ?


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Mise à jour du serveur

[Daniel Cordey]

On 10.07.21 22:28, Claude Paroz wrote:

Le 10.07.21 à 19:44, felix a écrit :

Bonjour,

...

Par ailleur, je me représente mal un kernel -amd64 pour i386!?
  ( /proc/cpu dit:  ``flags   : ... lm ...''  )


Repris d'une page Web askubuntu.com:
i386 refers to the 32-bit edition and amd64 (or x86_64) refers to the 
64-bit edition for Intel and AMD processors.


Mais justement, s'il s'agit d'une architecture cible i386, on ne peut 
normalement espérer y faire tourner une version pour 64 bits... A moins 
que... je vais peut-être apprendre quelque chose... Il doit bien y avoir 
une explication ! Et si Félix nous faisait un petit :


grep 'model name' /proc/cpuinfo

dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] UE et wiretapping d'email et apps de chat

[Daniel Cordey]

On 07.07.21 13:53, Miçhael Parchet wrote:

Bonjour,

Comment le parlement a-t-il pu refuser qu’une poursuite soit effacé 
automatiquement une fois payé. Je me demande quel a été les arguments 
Dézin et des autres mais avez-vous la certitude que le peuple aurait 
voté la même chose si cela avait été une initiative. C’est la preuve 
que dans leur château, les parlementaires semble faire ce qu’ils 
veulent et ils font passer des lois sans même consulter le peuple.


Il n'y a donc pas d'automatismes, mais il est possible de faire annuler 
une poursuite en requérant du tribunal du

for :

Annulation ou suspension de la poursuite par le juge
Art. 85
1. En procédure sommaire
Le débiteur poursuivi peut en tout temps requérir du tribunal du
for de la poursuite l'annulation de la poursuite, s'il prouve par
titre que la dette est éteinte en capital, intérêts et frais, ou la
suspension de la poursuite, s'il prouve par titre que le créancier
lui a accordé un sursis.
Art. 85a
2. En procédure ordinaire ou simplifiée
1 Le débiteur poursuivi peut agir en tout temps au for de la
poursuite pour faire constater que la dette n'existe pas ou
plus, ou qu'un sursis a été accordé.


Source :

https://www.fedlex.admin.ch/eli/cc/11/529_488_529/fr

http://www.unine.ch/files/live/sites/cemaj/files/shared/documents/formation_continue/2017/10_Bohnet_Atelier.pdf

dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] UE et wiretapping d'email et apps de chat

[Daniel Cordey]

On 07.07.21 14:41, Miçhael Parchet wrote:

Bonjour,

Désolé, ce n’est pas ce que j’ai trouvé au chiffre 16 des conditions 
générales de sunrise

...


Conditions datées de février 2017. Texte  obtenu sur le site web de Sunrise en 
novembre 2020 !


Date à laquelle j'ai résilié mon contrat.


Alors vous dites que ça ce n’est pas valable c’est discutable oui mais 
est-ce que c’est valable ?


Cette liste n'a pas pour but d'enseigner le droit. Pour plus 
d'informations, veuillez vous référer aux lois (et jurisprudence) 
relatives au code civile Suisse; et surtout au code des obligations : 
https://www.fedlex.admin.ch/fr/cc/internal-law/22).


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] UE et wiretapping d'email et apps de chat

[Daniel Cordey]

On 07.07.21 13:45, Miçhael Parchet wrote:



C’est bizarre cette histoire de résiliation. Je suis client chez 
Sunrise depuis bien longtemps et je me souviens avoir reçu une lettre 
indexé à ma facture me précisant bien le changement de conditions 
générales mais là où le bat blesse c’est qu’on est presque obligé de 
les accepter et qu’on peut pas les négocier sans quoi on doit quitter 
l’opérateur. Je n’ai pas essayé mais peut-être un coup de téléphone 
peut suffire à demander des explications. Le département de 
résiliation est le numéro suivant


0800 100 600


Essayé... écouté plein de musique pendant mes nombreuses tentatives... 
j'ai fini par abandonner (ça fait peut-être partie de la stratégie ?)



Je vous laisse la page de conditions générales au bout de ce lien 
https://www.sunrise.ch/fr/clients-prives/aide/sonstige-hilfe/rechtliches.html 


"16. Résiliation ordinaire
Les résiliations sont possibles par téléphone ou par écrit. Si le client 
utilise plusieurs prestations de service de Sunrise, il doit spécifier 
quel service il veut résilier."


Conditions datées de février 2017. Texte obtenu sur le site web de 
Sunrise en novembre 2020 !




Si vous n’arrivez pas à la lire, n’hésitez pas à utiliser un programme 
de synthèse vocale


Wow !!!




Donc de là à tirer une conclusion hativesur la base d’une expérience 
selon laquelle on peut toujours résilier par courrier sans avoir lu 
les lettres annexé aux factures ne me semble pas normal. Peut-être 
faudrait-il demander une copie des conditions générales à Sunrise à 
laquelle ils font référence


Sans vouloir vous vexer, sachez que je traite des contrats d'entreprises 
depuis plus de 20 ans et que j'ai discuté de ce cas avec un avocat avant 
d'entreprendre cette démarche. De plus, Je vois mal Sunrise accepter mes 
arguments si ceux-ci n'avait pas été solides sur le plan légal. Je n'ai 
jamais vu une entreprise céder lorsqu'elle tenait le couteau par le 
manche :-)


dc


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] UE et wiretapping d'email et apps de chat

[Daniel Cordey]

On 07.07.21 07:51, Marc SCHAEFER wrote:


En Chine, certaines options de la société (voyager, prendre un crédit,
etc) sont soumises à des crédits sociaux.  Traverser la rue hors des clous peut
faire perdre des crédits sociaux, par exemple.
Les gesticulations des autorités au sujet de la COVID-19 se rapprochent 
gentiment de ce principe... On n'en arrivera pas jusqu'à bloquer un 
emprunt, mais l'accès à des lieux ou manifestations se dirige dans ce 
sens. Les autorités dictent des règles et se mettent ensuite d'accord 
avec un organisme chargé de fournir les tests... (les pharmacies). Or, 
les pharmacies sont débordées (certaines n'ont plus de vaccins) et 
certaines abandonnent purement et simplement cette mission. Résultat des 
courses ? Il faut 2 semaines pour obtenir un rendez-vous pour un test 
antigénique (pour des spectacles). C'est une forme de discrimination 
sournoise qui ne dit pas son nom et où les acteurs peuvent se contenter 
de dire "c'est pas moi" et rejeter la faute sur les autres.

Pour donner un exemple *en Suisse*, assez ancien: un ami a inversé deux
paiements (soit d'une assurance, soit d'un opérateur télécom). Donc
entendons-nous bien: en tous temps, il avait versé la somme juste, mais
attribuées aux mauvaises factures.
Les départements des finances et contributions des cantons sont de 
grands spécialistes de cette pratique. Essayez de ne pas utiliser le bon 
code pour un paiement... Une fois sur un autre compte, c'est galère et 
vous êtes confrontés aux règlements particulièrement bornés et pas 
souples de l'administration.

Pour le moment, la LPD, aussi insuffisante soit-elle pour protéger
l'individu, suffit, ici, toutefois.


Récemment, le parlement a refusé de modifier la loi afin d'effacer le 
nom de quelqu'un qui a reçu un avis de poursuite une fois la somme 
payée. Je n'ai toujours spas compris la logique de cette attitude, mais 
il semble qu'il y ait une volonté de punir les gens pour des raisons qui 
m'échappent.





Mais en Suisse, globalement, le consommateur est bien moins protégé
qu'ailleurs. Exemple: pour convertir un M-Budget prépaid en abo: un SMS
suffit. Pour faire le contraire: 60 jours de préavis, passer en magasin
est la seule solution. Aucun courrier n'est accepté.


Lorsque vous avez un abonnement d'entreprise et que vous voulez 
l'arrêter et transférer votre numéro chez un autre fournisseur, Swisscom 
vous oblige à passer par un abonnement privé pendant 60 jours. Cet 
abonnement privé ne peut être une offre spéciale et doit donc être un 
abo "plein pot" ! Il n'y a aucune justification technique, juste des 
pratiques commerciales tolérées par la loi et exploitant la marge de 
manoeuvre que notre parlement se garde bien de restreindre.




Idem pour UPC qui refuse désormais (est-ce légal) les résiliations par
courrier recommandé.


Sunrise (maintenant avec UPC), a les même exigences. Sauf que... il 
semblerait que ce soit contestable ! En effet, lors de la résiliation, 
le client doit pouvoir être en mesure de prouver qu'il a bien demander 
celle-ci. Le courrier "recommandé" est donc le seul moyen à disposition 
du client. Les Sunrise/UPC essaie d'être la source de l'information, 
mais le client n'est pas à l'abri d'une défaillance de l'opérateur et ne 
sera donc pas en mesure de prouver sa demande. Il faut donc s'en 
remettre à l'opérateur pour enregistrer la conversation (mais vous ne 
détenez pas la preuve) et, qui plus est, il faut arriver à parler à 
l'opérateur ("toutes nos lignes sont occupées..."). Il y a aussi le chat 
mais encore faut-il qu’il fonctionne !


J'ai fait l'expérience avec Sunrise en novembre 2020. J'ai envoyé un 
courrier recommandé pour résilier mon contrat. Or, auparavant, j'avais 
vérifier les condition générales sur leur site, et celui-ci disait que 
l'on pouvait faire la demande par écrit (leur site n'était d'ailleurs 
pas à jour et ne contenant pas les nouvelles conditions générales !). 
J'ai fait une copie d'écran que j'ai conservé ! J'ai ensuite reçu un 
mail et un courrier me disant qu'ils (Sunrise) ne pouvait pas 
enregistrer ma demande car leurs "nouvelles" conditions générales 
précisaient que cela devait se faire par téléphone. J'ai répondu (encore 
par courrier recommandé), que je n'avais pas été mis au courant des ces 
nouvelles conditions, et que je m'en tenais à mon premier courrier. J'ai 
aussi précisé que je ferais opposition à tout "commandement de payer" et 
que je me réservais le droit d'entreprendre toute action qui me 
semblerait juste pour faire valoir mes droits, s’ils persistaient à ne 
pas tenir compte de mes courriers. Quelques semaines après (et après 
d'autres factures), j'ai eu un appel d'un juriste qui a reconnu que la 
situation était floue... et toutes les factures ont été annulées et ma 
résiliation acceptée. Ce qui n'a pas empêché la réception de nouvelles 
factures que j'ai ignoré (sans que cela ait eu d'autres conséquences).


Donc, même si vous avez les nouvelles conditions générales, disant que 
la