Sytoka Modon a écrit 4544 commentaires

Entièrement d'accord. Microsoft merde sur certain point mais la compatibilité est parfois un boulet en informatique et il le font quand même sur des années. S'il y en a un qui s'en fiche, et qui dégomme régulièrement les vieux machines pour alléger son système, c'est Apple.

Et puis quand j'ai commencé, je ne savais pas que LaTeX existait!

C'est vraiment étonnant. En 2000, presque tout le monde avait déjà basculé sous LaTeX, sauf peut être encore quelques matheux. Cette affirmation me semble plus que surprenante. En 2000, il me semble qu'on était déjà sous la distribution TeTeX sous GNU.Linux et que le temps de l'installation du tar.gz à la main sous /opt/texmf était révolue (je me souviens, on allait les chercher sur lip6, une machine de Paris VI.

Ne pas aimer LaTeX, je peux comprendre, mais en ignorer son existence, cela me parait invraisemblable.

Enfin, j'ai toujours eu l'impression qu'il y avait beaucoup de faille sur openssl. Cette bibliothèque revient très régulièrement dans la liste (ce n'est qu'une impression).

Les systèmes de paquet installent depuis des années sous /usr éliminant de fait celui-ci des partages NFS. Il est géré par les distributions classique (je ne parle pas des distribution cluster). C'est un fait acquis de nos jours et d'ailleurs, on assiste petit à petit à la fusion /bin /sbin /usr/bin /usr/sbin… (voir systemd). Il n'y a aucune RAISON de mettre des choses sous /opt… via un système de paquet. Celui-ci doit garder son status de pouvoir être monté par NFS.

Après, tu penses ce que tu veux. Les paquets qui mettent des choses sous /opt sont mal fichus. C'est vachement dur d'aller sous /usr/lib par exemple ? Enfin, c'est pas bien grave, on invente son /machin_a_moi pour ne pas être embêté mais bon, c'est idiot de polluer ainsi la racine…

Quelle idée d'écrire sous /home. Je suis sur que c'est formellement déconseillé par apt et rpm. D'ailleurs, cela pourrait être interdit, tout comme les MERDES de paquets réalisés par les industriels qui collent des saloperies sous /opt. /home et /opt doivent pouvoir être monter par NFS et donc cela les exclus de fait des gestionnaires de paquets. En plus, /opt est clairement réservés à l'installation manuelle de logiciels…

rpm et apt aurait du INTERDIRE ces dossiers en dur dans leur code source. Cela aurait été une bonne chose pour les codes privateurs…

Il vaut voir aussi les prérequis demandés… Sur certains logiciels, il faut vraiment un monstre pour faire tourner le portail !

seafile est aussi basée sur git mais une version modifiée, justement pour ces raisons : https://github.com/haiwen/seafile

Enfin, le CNRS a déjà du mal à nous maintenir le "KitCNRS" pour nos sites web et s'est marier à Microsoft pour son offre core dont elle délègue la gestion à BULL je crois….

drbd est bien trop bas niveau. Tu gères comment les pannes réseaux… Si tu veux du RAID1 distant, il vaut mieux faire du lsyncd ou du csync2 qui ne travaillent pas en mode block (même s'ils utilisent quand même l'algo de rsync derrière)

unison est plus adapté que rsync en effet si on parle de synchro. Il gère le bidirectionnel. Le produit était super en avance et le seul logiciel en CAML sur mes machines. Dommage qu'il soit en mode maintenance depuis des années.

seafile : http://seafile.com/en/home/

pyd.io : http://pyd.io/ (ex ajaxplorer)

Dans certain code de calcul, par exemple code hybride MPI/OpenMP, si la performance n'est pas prise en compte dès le début, cela ne marchera pas dans la plupart des cas. En effet, c'est pas toujours évident de rendre un code hybride s'il n'a pas été conçu pour dès le début.

Hommage caché à Leslie Lamport en plus (LaTeX converge vers e). Cela aurait un beau poisson effectivement ;-)

argent public => domaine public

J'étais moi aussi partisan de cela à 100%. Travaillant dans un laboratoire de recherche public lié aux SPI (Sciences Pour l'Ingénieur), on se rend compte que ce n'est pas toujours aussi évident que cela… Il y a une part de subvention cachée (la recherche est faites chez nous mais ce sont des boites vitales pour la France qui en profite). De plus, les autres pays ne jouent pas toujours le jeux. Il ne faut pas être le dindon de la farce ! Est-il raisonnable de tout publier sur les moteurs de la fusée Ariane par exemple ? J'avoue ne pas avoir de réponse à tous les cas que j'ai vu dans les laboratoires…

Donc public oui mais avec certaine contrainte. Délai après la parution des articles… Je me suis rendus compte que même le CERN qui est très ouvert n'est pas ouvert à 100%. En plus des contraintes économiques liées aux entreprises, il y a aussi une concurrence entres états (L'Europe étant ici en régime fédéral).

Va faire un film ou tu ne vas pas te faire racker par un ancien producteur… Plus les droits sont long, plus les majors bloquent le système et verrouille la création via attaques ou procès. Tant que tu es petit, tu ne leur fait pas d'ombre.

D'un autre coté, les droits d'auteurs changent et sont passés à 70 ans après la mort… Si les états ne jouent pas le jeux, il ne faut pas s'étonner que les citoyens au bout d'un moment en aient marre !

De plus, le tarif est carrément excessifs. C'est quasiment aussi cher en epub qu'en papier ! Si les éditeurs souhaitent vraiment pousser le format numérique, il faut une différence de prix qui prenne en compte l’absence de support matériel et donc de coût de fabrication du support. On sais qu'une copie numérique n'a pas le même coût qu'une copie physique !

Heureusement que les citoyens ne sont pas toujours des moutons gentils ;-)

Cela prouve surtout que les droits d'auteur ou les brevets tels quels n'ont pas de sens en informatique… Beaucoup trop long dans les deux cas !

A vrai dire, les droits d'auteur tuent la création (indépendante) aujourd'hui car ils sont déjà bien trop long.

un produit comme Windows c'est le haut de gamme

Quasiment tous les ordinateurs haut de gamme du monde tournent sous GNU/Linux ;-)

Il y a (avait) un problème de sécurité avec LXC. C'est assez facile d'arrêter la machine maître par exemple si mes souvenirs sont bons. Avec LXC, on dresse la liste des choses qu'on ne veut pas et non l'inverse, ce qui est aussi problématique.

Bref, très performant mais personnellement, je ne les utilise qu'en interne, jamais dans un DMZ.

Attention, sed du GNU, je ne sais pas si c'est portable sur tous les sed ;-)

Super. Je voulais passer à collectd pour pas mal de truc. Pourquoi pas essayer en même temps ta surcouche. Merci.

La ligne

cat /etc/bind/blacklist | sed 's/{/IN {/g' > sedtempfile && mv sedtempfile /etc/bind/blacklist

Peut être remplacé par

sed -i -e 's/{/IN {/g' /etc/bind/blacklist

L'option -i (inplace) est bien pratique et peu connu

La news précédente était un peu plus clair sur ce que cela fait.

https://linuxfr.org/news/sortie-de-rhq-4-9

Qu'entendez vous par : "l'accès à distance à Collectd rendant l'installation encore plus modulaire," ? Je n'aime personnellement par trop que le serveur central de monitoring installe quoi que ce soit…

Imaginons un cluster de 50 noeuds par exemple actuellement géré via ganglia. Comme faire avec ce produit ? Avec ganglia, si mes souvenirs sont bon (j'ai fais cela il y a longtemps), on configure les noeuds pour qu'ils remontent a un serveur central et ce dernier se démerde (je simplifie un peu…).

Par rapport a ganglia, c'est robuste au perte de connexion. Avec ganglia en mode non multi-cast (on est obligé chez nous) donc unicast, le client ne sais pas se reconnectéer au serveur si celui-ci est relancé (enfin, je n'ai pas réussi). Bref, il faut un ordre de démarrage et c'est très très chiant (et pas du tout robuste).

Le portage de MS Office Android vers Linux devrait être aisé, si le logiciel est bien codé.

Déjà dans cette phrase, il y a une hypothèse… MS est incapable (ou le fait exprès) d'avoir une version MacOSX réellement compatible.

Mais surtout. Office est un outil graphique au contraire du formateur TeX. Or la pile graphique d'Android n'a rien à voir avec la pile X-Window (ou même Wayland). Donc le portage est immense… et ne sera pas fait !