La défense de notre modèle social

14.07.20 | par Le Grincheux | Catégories: Je hais les politiciens

Par le plus grand des hasard, je viens de tomber sur l'interview donnée par notre charmant président de la république, loué soit son nom, pour le 14 juillet.

J'y entends cet élément de langage que je ne peux plus entendre. Il faudrait, selon lui, défendre notre modèle social. C'est bien, c'est dit. Mais le défendre contre qui ? Contre les gens comme moi qui sont ultraminoritaires ? Soyons sérieux, le français adore son modèle social, la légende qui vient avec lui et sont persuadés, les imbéciles, que sans ce sacro-saint modèle social, ils seraient tous en train de crever dans la rue.

Or, lorsqu'on réfléchit à peine plus loin que le bout de son nez, on s'aperçoit très vite que le chômage est la conséquence de ce fichu modèle social ; que les faibles salaires, les faibles retraites et la faiblesse de l'économie sont aussi sa conséquence directe ; que le système de santé agonisant n'est dû qu'à ce satané système que l'immense majorité des Français veut absolument conserver.

Mais il faut toujours défendre ce système. Je pose donc à nouveau la question : contre qui ou contre quoi ?

La seule réponse logique est ainsi qu'il faille le défendre contre lui-même parce qu'il porte en lui les gènes de sa propre destruction.

 

Grandeur et décadence

12.07.20 | par Le Grincheux | Catégories: Je hais l'informatique

Je fus l'un des premiers à installer un système Linux sur un ordinateur en France, avec une pile de disquettes, Internet n'étant pas encore ce qu'on connaît aujourd'hui. Je me souviens même du premier serveur installé dans mon laboratoire qui tournait avec un noyau 1.0.9, ce qui ne nous rajeunit pas vraiment et j'ai même participé au développement du noyau pour des architectures exotiques comme les Sparc (à l'époque en 23 bits) et les Alpha. J'ai arrêté de participer à ce développement au cours de la vie du noyau 2.4 puisqu'il était impossible de suivre les modifications internes, surtout les changements de mémoire virtuelle, et tous les bidouillages introduits pas un développement effectué principalement sur architecture x86. Néanmoins, entre les noyaux 1.0 et 2.2 inclus, l'évolution de ce système d'exploitation en faisait quelque chose de prometteur. Vingt-cinq ans plus tard, que peut-on en dire ?

Durant toute une période, j'ai migré mes serveurs d'Unix propriétaires (Ultrix, OSF/1, Solaris, HP-UX) vers Linux parce le système était efficace, carré. Aujourd'hui, je constate que j'effectue la démarche inverse. Je ne réinstalle pas des Unix propriétaires, non, mais des NetBSD (sur serveur) ou des FreeBSD (principalement sur station de travail). Je n'installe plus des système Linux que sur des machines qui utilisent des outils bien particuliers ou pour des besoins spécifiques comme des ordinateurs portables dont les paramètres réseau, par exemple, doivent pouvoir être changés facilement par l'utilisateur sans attaquer avec vi des fichiers de configuration.

Comment en suis-je arrivé là?

Il est bizarre de voir que ce que les développeurs de Linux reprochaient à Windows au tournant des années 2000 se retrouve aujourd'hui presque intégralement dans Linux. Le développement se faisant quasiment exclusivement sur architecture amd64, le code n'est pas réellement propre et des tas d'hypothèses sont faites, hypothèses qui se vérifient sur amd64 mais pas forcément sur d'autres architectures (voir pour cela les problèmes sur Sparc64). Et même sur architecture amd64, il est devenu bien difficile de faire fonctionner de manière fiable des machines dans des configurations particulière — typiquement, une machine diskless peut aujourd'hui gravement dysfonctionner, soit par plantages totaux en cas de fichier de swap sur un disque NFS (problème officiellement corrigé, mais mon noyau ne semble pas être au courant), soit par destruction du serveur X par systemd pour des raisons incompréhensibles lorsque la machine se met à swapper. Mais il y a bien pire, une partie des principes Unix comme KISS (Keep It Simple, Stupid) est de plus en plus bafouée. Un exemple parmi tant d'autres, l'inénarrable systemd.

Pour démarrer un système Unix, il existe principalement deux techniques :

  • BSD : un fichier de configuration (généralement /etc/rc.conf et les fichiers inclus) indique quels sont les daemons qui doivent être démarrés avec le système. Les scripts de démarrage de ces daemons contiennent des dépendances et le daemon init (de PID 1) s'arrange alors pour les démarrer dans l'ordre nécessaire. C'est simple, efficace, sans surprise. C'est même économe en mémoire et en ressources diverses ;
  • SysV : c'est encore plus trivial. Un répertoire contient une collection de scripts exécutés dans l'ordre alphabétique. C'est à l'utilisateur de régler les dépendance en réglant le nom des différents scripts. C'est encore plus économe. Sans doute trop, cela demande à l'utilisateur de réfléchir un peu.

Ces deux techniques sont trop simples et on a vu arriver un daemon à tout faire dans Linux pour, soi disant, simplifier le problème. Il s'agit de systemd. Systemd, c'est un truc qui fait tout, qui sert à tout, qui a une syntaxe délirante et des fichiers de configuration planqués un peu partout (/lib/systemd/system, /lib/systemd/user, /etc/systemd/system, /etc/systemd/user et peut-être même ailleurs). C'est une usine à gaz avec des fuites qui empêche un démarrage rapide de toute machine ayant moins de 1 Go de mémoire puisque pour des raisons de rapidité (sic), tous les services devant démarrer sont lancés en même temps jusqu'à ce que toutes les dépendances soient satisfaites. Sur les machines un peu courtes en mémoire, ça fait chauffer le dérouleur de pages, et ça peut le faire chauffer longtemps. Mais il paraît que c'est un progrès indéniable.

Vous allez me dire que les machines classiques actuelles ont plusieurs gigaoctets de mémoire, que cela n'est pas un problème. C'est pourtant un problème puisque Linux est malheureusement de plus en plus utilisé dans l'électronique embarquée où on n'a pas forcément une telle quantité de mémoire à disposition. Un autre problème de systemd est qu'il est associé à un noyau en particulier. Lorsqu'un noyau pose problème, il peut être aujourd'hui impossible de démarrer sur un noyau plus ancien qui n'aura pas la bonne version de systemd, celle-ci étant unique pour l'ensemble des noyaux. Mais le pire est tout de même les effets de bords de systemd avec les autres daemons du système comme udev. Le noyau Linux a eu la bonne idée depuis des lustres de nommer les interfaces Ethernet en eth. Premier problème, d'une version à une autre, l'énumération ne se faisait pas forcément dans le même sens. Pour madame Michu qui n'a qu'une seule interface réseau, ce n'est pas grave. Pour quelqu'un qui utilise des serveurs avec plusieurs cartes Ethernet, cela peut rapidement devenir compliqué. Plutôt que de fiabiliser l'ordre d'énumération puisqu'il n'y a aucune raison que d'un noyau à un autre, l'ordre d'énumération sur une même machine ne change, un cataplasme sur une jambe de bois a été rajouté. Deux si je veux être précis. Historiquement, udev peut renommer les interfaces en fonction de leur adresse Ethernet. Plus récemment, les noms de périphériques ont été changés et ce qui était eth0 a pu devenir au gré d'une mise à jour de noyau enp0s31f6, ce qui était très pratique pour les gens qui utilisaient un firewall bloquant tout par défaut sur une machine à distance. Mais encore, en lisant la documentation et en acceptant d'ouvrir un peu tous les ports le temps de la migration, il était possible de s'en tirer.

Or arrive sur ces entrefaites l'inénarrable systemd qui, lui aussi, veut avoir son mot à dire sur le nommage des interfaces. À titre personnel, les interfaces réseau de l'un de mes serveurs sont les suivantes :

Root rayleigh:[~] > ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::c48a:96ff:fede:8a07 prefixlen 64 scopeid 0x20<link>
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
ether c6:8a:96:de:8a:07 txqueuelen 1000 (Ethernet)
RX packets 10316123 bytes 4301990769 (4.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10982367 bytes 9779960261 (9.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.1 netmask 255.255.255.0 broadcast 192.168.254.255
inet6 fe80::208:2ff:feaf:da70 prefixlen 64 scopeid 0x20<link>
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)
RX packets 8698421 bytes 1258112154 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7780169 bytes 2744108696 (2.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.81 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.82 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.83 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.84 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.85 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.86 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.253.1 netmask 255.255.255.0 broadcast 192.168.253.255
inet6 2001:7a8:a8ed:253::1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::208:2ff:feaf:da71 prefixlen 64 scopeid 0x20<link>
ether 00:08:02:af:da:71 txqueuelen 1000 (Ethernet)
RX packets 20477825 bytes 11652375271 (10.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21845494 bytes 13687329761 (12.7 GiB)

TX errors 7 dropped 0 overruns 0 carrier 7 collisions 0

lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.128 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::5246:5dff:fe72:efa2 prefixlen 64 scopeid 0x20<link>
ether 50:46:5d:72:ef:a2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9402 bytes 614631 (600.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7e00000-f7e20000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Boucle locale)
RX packets 17945139 bytes 6569208488 (6.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17945139 bytes 6569208488 (6.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
inet 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::6cb8:b3ff:fed0:235f prefixlen 64 scopeid 0x20<link>
ether 6e:b8:b3:d0:23:5f txqueuelen 100 (Ethernet)
RX packets 51661 bytes 18867944 (17.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 66902 bytes 4769816 (4.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::30f3:6dff:fe94:8c9b prefixlen 64 scopeid 0x20<link>
ether 32:f3:6d:94:8c:9b txqueuelen 100 (Ethernet)
RX packets 1545324 bytes 1307060028 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1371546 bytes 810892202 (773.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet6 fe80::7807:ceff:fefe:4c12 prefixlen 64 scopeid 0x20<link>
ether 7a:07:ce:fe:4c:12 txqueuelen 100 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35056 bytes 1824754 (1.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Il y a du monde. Vous noterez qu'il n'y a plus de eth0 mais un lan0. Pourquoi ? Parce que cette saleté de systemd a décidé depuis sa dernière mouture d'entrer en conflit avec le renommage des interfaces par udev et eth0 était renommé en je ne sais plus quoi. Heureusement que l'interface en question était une interface du LAN, ce qui ne m'empêchait pas de prendre la main à distance pour corriger le problème. Tout cela ne fait pas bien sérieux et n'est pas vraiment très sec. Cela me donne même l'impression d'essuyer du plâtre avec des briques.

Hier, j'ai installé sur un ordinateur portable tout neuf une Debian testing. Lors de l'installation, je me suis aperçu de la présence de liens étranges dans /. Typiquement, /bin était un lien vers /usr/bin, /sbin un lien vers /usr/sbin et /lib vers /usr/lib. Je me suis dit qu'il s'agissait de liens lors de l'installation. Non, ces liens restent sur le système final.

J'ai donc cherché un peu dans la documentation et je suis tombé sur des justifications totalement oiseuses :

Amélioration de la compatibilité avec les autres Unix / Linux dans le comportement. Après la fusion avec /usr, tous les binaires deviennent disponibles respectivement dans :

  • "/bin <–> /usr/bin"
  • "/sbin <–> /usr/sbin"
  • "/lib <–> /usr/lib"

simplement parce que /bin devient un lien symbolique vers /usr/bin, resp /sbin vers /usr/sbin… Cela signifie que les scripts/programmes écrits pour d’autres Unix ou d’autres Linux et portés à la distribution courante n’auront plus besoin de correction pour les chemins de système de fichiers des binaires appelés, ce qui est par ailleurs une source majeure de frustration. /usr/bin et /bin (resp. /usr/sbin et /sbin…) deviennent tout à fait équivalents.

J'ai rarement lu un truc aussi bête. /bin et /sbin contiennent les binaires nécessaires du démarrage du système, /usr/bin et /usr/sbin les autres. C'est simple, carré. Par ailleurs, les scripts doivent utiliser une variable PATH, donc ce problème n'existe pas.

Mais ce n'est pas la seule justification puisque je peux lire aussi:

Amélioration de la compatibilité avec les systèmes de compilation GNU : la majeure partie du logiciel Linux est construite avec GNU autoconf / automake (c’est-à-dire GNU autotools), qui ignorent la division /usr spécifique à Linux. Le maintien de la division /usr nécessite une gestion non triviale du projet dans le système de génération en amont et dans les packages de votre distribution. Avec la fusion /usr, ce travail devient inutile et le portage des paquets vers Linux devient plus simple.

J'utilise les autotools depuis vingt-cinq ans, je n'ai jamais constaté cela sauf si les scripts sont écrits par des pieds, mais dans ce cas, pourquoi mettre un cataplasme sur une jambe de bois ? On corrige en amont, on ne fait pas n'importe quoi en aval ! Les autotools sont justement faits pour gérer ce genre de problème. Quant à parler de la compatibilité Solaris, il y a un point que les gens oublient, c'est que Solaris est livré comme un tout et que, à l'instar des BSD, /usr concerne le seul système. La dernière fois que j'ai eu un Solaris entre les pattes (un 10, j'avoue), les programmes autres que ceux du système étaient dans /opt ou /usr/local. Chez Debian, ce n'est pas le cas, ils sont dans /usr/bin. J'attends donc avec une certaine impatience la conceté suivante, la fusion de /usr/bin avec /usr/sbin. Parce que les arguments que je lis pour la fusion de /bin avec /usr/bin et /sbin avec /usr/sbin s'appliquent de la même manière.

Un système Unix, un vrai, doit pouvoir démarrer avec une partition racine qui contient /etc, /bin, /sbin et /lib. Je sais qu'avec Linux, il est possible de bricoler avec initramfs, mais cela reste un bricolage qui ne devrait pas exister. /usr, /usr/local et /opt le cas échéant, doivent pouvoir être montés bien plus tard puisque ces partitions ne sont pas des partitions critiques. L'intérêt de la chose est de pouvoir démarrer sur une tout petite partition, même montée en utilisation normale en lecture seule. Cela permet de réparer un système endommagé, surtout lorsqu'on a les utilitaires de base compilés en statique.

Après avoir lancé cette argumentation, la réponse des développeurs de Debian fut laconique. Pour eux, dans une telle situation, il faut utiliser une image GRML appelée depuis le programme d'amorçage (grub2).

Là, j'avoue que les bras m'en tombent et je me demande pourquoi il faudrait faire simple quand on peut faire outrageusement compliqué. Comparons par exemple un NetBSD avec un système Debian/Linux. Je vais passer sous silence que le code du noyau NetBSD est un code qui est d'une qualité nettement supérieure au noyau Linux puisqu'une modification n'est poussée dans l'arborescence des sources que lorsqu'elle a été testée avec succès sur l'ensemble des architectures dites tier 1, ce qui n'est pas le cas avec Linux où elles sont poussées quand elles fonctionnent sous amd64 et advienne que pourra.

Il existe en particulier un répertoire /rescue dans NetBSD. Il contient tous les utilitaires nécessaires à la maintenance du système, compilés en statique et son contenu évolue avec le système. Ces utilitaires sont donc toujours à jour et il n'est pas nécessaire de maintenir à jour une image complète GRML.

La fusion de / avec /usr est une mauvaise idée parce que c'est une source de problèmes potentiels. Il faut que / (contenant /usr) soit en état d'être montée. Cette partition, dans un système Debian, fait plusieurs dizaines de gigaoctets puisque tous les paquets s'y trouvent. Si maintenant /usr est distincte de /, on se retrouve avec un initramfs qui doit monter / et /usr. Il faut donc que deux partitions soient en état d'être montées et que initramfs soit utilisable pour que le démarrage se passe correctement.
C'est bien pour cela que je trouve très bête (et je suis poli) le fait d'avoir ces liens de / vers /usr alors que le bon sens voudrait au contraire que l'on sépare bien ce qui est de l'ordre du mécanisme de démarrage de ce qui est de l'ordre de l'utilisation du système une fois celui-ci démarré. Certaines décisions me semblent prises sous l'effet de la mode — pour ne pas dire sous l'effet de la drogue — par des gens qui n'ont pas réfléchi plus que cela à ce qui se faisait par ailleurs. Si /bin, /sbin, /usr/bin et /usr/sbin ont été séparés depuis trente ans, il y a peut-être des raisons fondamentales, ceux qui ont fait ces choix n'étant pas plus bêtes que nous.

Dans un NetBSD, il n'y a typiquement pas besoin d'avoir une image GRML quelque part parce qu'il existe ce répertoire /rescue et que /bin, /lib et /sbin (et /etc) ne servent qu'au démarrage.

Exemple :

legendre:[~] > uname -a
NetBSD legendre.systella.fr 9.0_STABLE NetBSD 9.0_STABLE (CUSTOM) #6:
Sat Jun  6 16:01:51 CEST 2020 root@grincheux.de-charybde-en-scylla.fr:/usr/src/netbsd-9/obj/sys/arch/amd64/compile/CUSTOM amd64
legendre:[~] > du -hs /bin
1.7M    .
legendre:[~] > du -hs /sbin
12M     /sbin
legendre:[~] > du -hs /lib
18M     /lib
legendre:[~] > du -hs /rescue
20M     /rescue
legendre:[~] > du -hs /stand/amd64/9.0
23M     /stand/amd64/9.0

Pour peu que / soit une partition séparée (en lecture seule), il est toujours redémarrer même en cas d'effacement d'une bibliothèque critique puisque /rescue est là pour cela. Ce répertoire permet de démarrer un NetBSD en single user tout en permettant de travailler sur le vrai système sans jouer du mount -o bind et autres joyeusetés qui sont assez rapidement plantogènes pour peu que le noyau de l'image ne soit pas celui en cours sur le système à dépanner. En mettant un lien de /sbin vers /usr/sbin, cette possibilité est interdite par construction puisque cela augmente les chances que cela se passe mal. En effet, lorsqu'on est contraint de travailler en single user, il y a souvent des partitions qui ne sont plus en état d'être montées, donc il y a beaucoup plus de chances que cela se passe mal.

Exemple sur un serveur Debian :

rayleigh:[~] > uname -a
Linux rayleigh 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 GNU/Linux
rayleigh:[~] > du -hs /bin
12M     /bin
rayleigh:[~] > du -hs /lib
2,0G /lib
rayleigh:[~] > du -hs /usr/lib
9,6G /usr/lib
rayleigh:[~] > du -hs /usr/bin 1,1G /usr/bin rayleigh:[~] > du -hs /usr/sbin 64M /usr/sbin rayleigh:[~] > du -hs /sbin 17M /sbin

Pour démarrer, le système doit accéder à une partition en forme (assez en forme pour être montée au moins en read only) de 13 Go, voire deux partitions en forme dans le cas où /usr est distinct et où on joue avec initramfs. Et si une bibliothèque cruciale est corrompue, on n'a que ses yeux pour pleurer, car il n'y a aucun utilitaire compilé en statique pour réparer. Quiconque a déjà essayé de recompiler un apt en statique verra de quoi je veux parler. Remarquez bien, pour démarrer correctement un Linux de nos jours, il faut aussi que l'initramfs soit correct. Encore un truc qui est une aberration sans nom puisque les scripts appelés ne sont pas forcément ceux de /etc, mais ceux qui ont été copiés dans l'initramfs. Je conçois qu'on embarque des modules dans un système de fichiers spécial pour contourner les problèmes d'initialisation liés au bios. Mais on peut faire largement mieux avec un système comme grub2 sans passer par cette horreur qu'est l'initramfs et qui est une source d'ennuis

Ce n'était pas forcément mieux avant. Mais certains choix qui ont été fait par les concepteurs des systèmes Unix l'ont été pour d'excellentes raisons. Abandonner ces concepts simples peut torpiller un système d'exploitation. Personnellement, je ne suis pas plus gêné que cela tant qu'il me restera des BSD restant dans la philosophie Unix.

 

Le cas Dupond-Moretti

09.07.20 | par Le Grincheux | Catégories: Grincherie en panne

Le fait que le nouveau garde des sceaux ait réussi, dès sa nomination, à mettre tous les syndicats de la magistrature vent debout contre lui me le rend éminemment sympathique. Je connais bien trop cette sale engeance pour lui accorder le moindre crédit et je ne suis pas loin de penser que l'état actuel de la France est en grande partie dû à l'incurie de la plupart des magistrats qui, tellement indépendants et incontrôlables, sont en roue libre depuis trop longtemps et s'érigent plus en redresseurs de torts supposés — quitte à faire passer des défendeurs pour des victimes de la société — qu'en juges destinés à appliquer et à faire appliquer le droit si pas à la lettre, au moins dans son esprit.

Il faut dire qu'il a encore quelques jours, il déclarait encore à qui voulait bien l'entendre qu'il était totalement inacceptable dans un état qui se voulait de droit que les magistrats non seulement n'aient aucun compte à rendre mais encore ne soient responsables d'aucune de leurs décisions.

Je ne sais pas s'il pourra faire quelque chose pour changer cet état de fait, mais le simple fait qu'il l'ait dit fait que je lui laisse le bénéfice du doute.

 

Tracasserie administrative

08.07.20 | par Le Grincheux | Catégories: Mauvaise humeur

Il y a quelques mois, j'ai eu l'insigne honneur, en raison de l'inaction de mon expert-comptable, de participer à une audience correctionnelle pour non dépôt des comptes annuels de l'exercice 2018 de ma société. Je tente depuis d'effectuer ce dépôt sans succès et ce qui devrait être une simple formalité administrative — dont on se demande bien à quoi elle sert — se transforme en parcours du combattant.

Administration, allégorie.

Mon expert-comptable a en effet omis de me fournir la plaquette de dépôt des comptes annuels, cette plaquette étant différente de la liasse fiscale à déposer au service des impôts des entreprises (laquelle liasse a tout de même été fournie après injonction par ledit service et avec deux mois de retard). Je lui ai bien rappelé à plusieurs reprises de me fournir ce document sans succès. Après plus d'un an de bataille, cette charmante personne s'est permis d'antidater la plaquette de dépôt des comptes histoire de pouvoir dire que, vous comprenez, elle n'était pas responsable, c'était moi qui n'avais pas fait le nécessaire. Forcément, cela m'a un peu énervé. J'admets que l'on fasse des erreurs, mais lorsque ces erreurs ont été faites, j'ai horreur que l'on refuse de les assumer et que l'on fasse porter le chapeau à quelqu'un d'autre ! Les services du procureur qui m'ont convoqué m'ont très clairement indiqué que certains experts-comptables étaient coutumiers du fait, que la situation était inadmissible, mais que ces experts-comptables n'étaient jamais inquiétés alors même qu'ils étaient parfaitement connus.

Ceci étant, j'avais déposé en temps et en heure les comptes de 2019. Je dois dire que je ne paie plus un expert-comptable pour faire du juridique, je trouve que la facturation est énorme pour pondre une fois par an une assemblée générale d'approbation des comptes. Cela fait presque vingt ans que je dépose des comptes pour plusieurs sociétés, je sais faire au moins aussi bien qu'un expert-comptable.

Sauf que… sauf que la mafia des greffiers des tribunaux de commerce et des experts-comptables vous met tous les bâtons dans les roues qu'ils peuvent pour vous contraindre d'en passer par les services des experts-comptables voire en vous renvoyant vers des avocats spécialistes.

Depuis quasiment vingt ans, je dépose des comptes pour des SARL, SAS ou autres SA. Je sais donc faire. Cette année, la plaquette m'est revenue parce qu'elle n'avait pas été certifiée conforme par le président de la SAS. En vingt ans, je n'ai jamais certifié conforme la plaquette en question puisqu'elle est signée par l'expert-comptable et qu'il s'agit du document original. Je ne mettais qu'un coup de tampon « document original ». Pas une fois, et cela n'a jamais posé de problème à mes deux greffes précédents. Cette fois-ci, la plaquette m'a été retournée avec naturellement une mise à l'amende idoine. L'assemblée générale ordinaire avait, certes, approuvé les comptes de 2018 et 2019, mais n'avait déposé que 2019 en expliquant pourquoi. Autre mise à l'amende. Naturellement dans deux courriers recommandés différents, avec deux nouvelles mises à l'amende pour émission de deux courriers recommandés.

J'ai interrogé un juriste spécialisé dans les assemblées générales de sociétés commerciales qui n'a rien trouvé à redire à mon assemblée générale ordinaire. J'ai tout de même reconvoqué une telle assemblée, je n'ai que cela à faire, et j'ai pris la peine d'aller moi-même au greffe du tribunal de commerce pour déposer ces documents pour que l'on me réponde de vive voix que telle ou telle chose ne va pas plutôt que de m'envoyer un courrier recommandé pour chaque virgule mal placée.

Arrivé hier matin devant le greffe du tribunal de commerce, je suis avisé par un écriteau que celui-ci n'est ouvert que pour la délivrance des extraits Kbis. Un collègue de mon grand'père se serait écrié « et merde pour les autres ! » Un employé du tribunal m'ouvre tout de même la porte pour me renseigner. Je lui explique le problème et il me répond qu'il voudrait bien me laisser entrer, mais qu'il était là depuis l'ouverture, que le greffe était censé être ouvert, mais qu'il n'avait vu personne de la matinée, le rideau de fer étant même resté fermé. Il ne savait pas si ce guichet daignerait ouvrir dans l'après-midi et me rajoute qu'il faudrait téléphoner pour obtenir un rendez-vous. Mais pas téléphoner au greffe du tribunal du commerce, personne ne répondant, si vous voulez avoir ce service, il faut téléphoner au standard du tribunal judiciaire et se faire passer le greffe du tribunal de commerce par le standard. Bon à savoir, cela confirme que ce service est juste là pour encaisser de paiement des actes en se moquant du monde.

Il me rajoute même, maniant la litote, que le Covid-19 était un argument bien pratique pour que certains tirent au flan, qu'en l'occurrence cela faisait plus de quatre mois que le greffe en question fonctionnait au ralenti. Dans la discussion, il m'annonce encore que si vous cochez certaines cases comme le fait de ne pas être natif de la région, de ne pas recourir à un avocat ou un expert-comptable pour rédiger les assemblées générales, le greffe vous en fera voir de toutes les couleurs alors que si vous êtes un natif du cru, vous pouvez ne pas déposer vos comptes, tenir des assemblées générales totalement illégales voire utiliser des actionnaires décédés, personne ne vous tiendra rigueur. Il termine en me disant qu'il sait parfaitement de quoi il parle, subissant lui-même ce racisme de bas étage.

Pour l'une de mes anciennes entreprises, je n'avais pas de greffe du tribunal de commerce, mais le greffe du tribunal d'instance, chambre commerciale. C'était du velours, les décisions de justice étaient prises par des vrais juges (même s'il y aurait aussi à y redire) et non par des potentiels concurrents des entreprises jugées. Les tribunaux de commerce sont une des hontes françaises. Ils sont tenus par des gens qui ne sont pas là pour être au service des gens qui les paient mais pour leur soutirer le maximum d'argent et prouver par leurs capacités de nuisances leurs existences tout en avalisant tous les écarts des copains ou en poussant les heureux bénéficiaires de leurs services dans les bras de professionnels véreux sans lesquels il est quasiment impossible d'effectuer les démarches obligatoires.

Il est grand temps de réformer cette spécificité. Il est surtout grand temps d'enfin considérer que ce pays est corrompu jusqu'à la moelle et pue comme un bordel à marée basse.

 

La tyrannie de l'écologisme

30.06.20 | par Le Grincheux | Catégories: Je hais les écolos

C'est fait, le second réacteur de Fessenheim est arrêté. Les écologistes ont gagné et il va falloir investir sans plus tarder dans des groupes électrogènes. Et cette fermeture est une honte absolue, surtout lorsqu'on se targue comme les « escrolos » de lutter contre le réchauffement climatique.

Cette centrale en parfait état n'a pas été fermée pour des raisons de sécurité, ni parce qu'elle fut mise en service en 1977 et qu'elle serait obsolète. Les réacteurs de même type ont montré qu'ils pouvaient fonctionner largement plus que 43 ans. Non, elle a été fermée sous des prétextes fallacieux et purement politiciens par François Hollande et cette fermeture n'a pas été retoquée par l'actuel occupant de l'Élysée.

Cette centrale produisait deux fois 880 MW (puissance nette). À titre de comparaison, les chiffres sont têtus, une éolienne moyenne en France a une production maximale de 2 MW avec un facteur de charge de 24%, lui aussi moyen. Sur une année moyenne aussi, ce facteur de charge est de moins de 7% pendant 10% de l'année. En d'autres termes, pendant 10% de l'année, l'éolienne moyenne produit moins de 140kW. En étant particulièrement optimiste, on pourrait en conclure qu'il faudrait remplacer cette centrale par 12500 éoliennes. À titre d'information, on peut installer quatre éoliennes par kilomètre-carré, on aura donc une emprise au sol de 3125 km² soit un peu moins que la surface du département du Haut-Rhin (3525,17 km²).

Sauf que la fréquence du réseau doit être fixe et parfaitement contrôlée (elle sert d'étalon de fréquence). Cette fréquence varie en fonction de la consommation et de la production d'énergie. Plus la consommation est importante à production fixe, plus la fréquence baisse. C'est pour cette raison que le réseau d'énergie a besoin de sources pilotables à la demande et non de sources intermittentes et qu'il faut absolument des centrales électriques réagissant à la demande. Cela tombe bien, l'Allemagne vient de mettre en service une centrale non polluant et très faiblement émettrice de dioxyde de carbone à Datteln et brûlant principalement la source de charbon locale, la lignite, qui est une plaie environnementale. Quelques écologistes locaux ont bien râlé, sans succès.

Récapitulons. Nous fermons sous la pression des écologistes une centrale en parfait état à très faible empreinte carbone. Nous remplaçons cette centrale par une source pilotable en Allemagne produisant infiniment plus de dioxyde de carbone, le tout sous des prétextes écologistes. Ce n'est ni sérieux, ni cohérent.

Le réseau européen a été totalement déstabilisé il y a quelques mois — souvenez-vous, les horloges pilotées par la fréquence secteur prenaient du retard —, depuis quelques mois, nous frôlons très régulièrement le blackout (janvier 2019, 9 août 2019, 7 octobre 2019 date à laquelle RTE a autoritairement coupé plusieurs sites industriels pour protéger le réseau, plus récemment encore…). Notre consommation augmente régulièrement, d'autant plus que les véhicules électriques qui sont une aberration écologique consomment eux-aussi. Et nous voulons réussir à augmenter la production électrique en utilisant des sources renouvelables.

La fermeture de Fessenheim et l'ouverture de Datteln nous montre que c'est impossible. Pire, cela nous montre que la fermeture d'une centrale nucléaire pour des raisons écologiques impose l'utilisation de centrales thermiques grandes émettrices de CO2. Dans cette perspective, la percée des écologistes tendance pastèque (vert dehors, rouge dedans) ne me rend pas furieusement optimiste pour l'avenir de certaines villes.

Well done, old chap !

 

Pages: 1 3 5 ...6 ...7 8 9 10 11 12 ... 193