Bonjour Nal,
Je t'écris pour te signaler la sortie de la nouvelle version du meilleur IDE java/php/node.js du marché : Netbeans 11 !
Repris par la fondation Apache (aka la poubelle d'Oracle), le haricot est toujours vivant avec quelques nouveautés:
Ah Nal,
Je sais que les projets de ta SSII sont encore sous Java 1.6, mais il est temps de migrer: la douzième version du langage libre le plus populaire en entreprise vient de sortir.
Les nouveautés sont peu nombreuses, mais sympathiques.
boolean joursOuvrees = switch (jour) {
case LUNDI, MARDI, MERCREDI, JEUDI, VENDREDI -> true;
case SAMEDI, DIMANCHE -> false;
};
Avec 66 nouveaux emojis 💩 et les nombres mayas pour recalculer la fin du (…)
Ceci est une traduction de mon entrée de blog récente. Quelques remarques avant de commencer :
D'autre part, comme ici on est chez les Français râleurs, je n'ai pas à prendre autant de pincettes que dans mon blog agrégé sur Planet Mozilla. Donc soyons clairs, ce texte se veut un coup de gueule. Il y a des soi-disant experts en sécurité qui prétendent que Firefox est vulnérable parce qu'il lui manque telle ou telle fonctionnalité présente chez tel concurrent. Sans vouloir nier l'utilité de ces fonctionnalités, j'ai pensé qu'il était temps de remettre les pendules à l'heure : la sécurité des navigateurs est un sujet trop vaste pour qu'une ou deux techniques en particulier puissent faire une grande différence au total, et ces « experts » et autres journalistes se ridiculisent en répétant, sans distance critique, le marketing d'une entreprise… avec laquelle je ne tiens pas à me brouiller, car si je critique son marketing, j'ai souvent eu à travailler avec ses ingénieurs dans les comités de standards, et ça se passe très bien.
Au fil de mon blog, j'ai largement dévié sur un autre sujet qui me tient à cœur : la sécurité de WebGL, qui a elle aussi été victime d'une campagne de dénigrement de la part, cette fois-ci, d'un autre concurrent, qui lui n'a vraiment pas fait dans la dentelle alors qu'ils avaient eux-mêmes une technologie avec les mêmes « failles ».
Sur ce, la traduction de ce blog se trouve en seconde partie
NdM : merci à Benoit Jacob pour son journal.
LinuxFr.org a déjà publié quelques articles à propos de systemd, sans entrer trop dans les détails des améliorations techniques.
On trouve en particulier un entretien avec son auteur, Lennart Poettering, et un journal contestant la qualité et les dépendances du code.
L’arrivée de systemd provoque pas mal de remous, justifiés ou non. On peut citer l’objectif « Linux only » affiché par l’auteur, les multiples dépendances et en particulier celle de D-Bus, la personnalité de l’auteur et la qualité de ses réalisations précédentes, le périmètre de responsabilité de systemd (gdm) et probablement de nombreux autres points.
Cet article a pour objectif de passer en revue les évolutions techniques et les objectifs de systemd. Les autres questions citées ci‐dessus ne sont pas injustifiées (en tout cas, pas toutes), mais sont en dehors du périmètre fixé.
L’article se base essentiellement sur les présentations de Lennart Poettering publiées sur son site en particulier, certains paragraphes sont des traductions un peu condensées de sa présentation initiale.
Merci aux relecteurs : Davy, Spack, npa.
Instantbird est un client de messagerie instantanée multi‐protocole.
Il utilise la bibliothèque de protocoles de Pidgin, libpurple, et est propulsé par les technologies Mozilla.
Ces technologies, de par le fait qu’elles soient très proches des technos Web (JavaScript, CSS, XML), sont très accessibles. De plus, grâce à l’utilisation du moteur de Firefox, l’écriture d’extensions devient un exercice très facile.
Maintenant que la version 1.0 est sortie, l’équipe d’Instantbird va pouvoir se concentrer sur les nouveautés et l’innovation dans le domaine de la messagerie instantanée. À suivre de très près donc.
Je continue mon exploration de ma nouvelle machine, et j'ai (dès le départ) profité de Compiz pour agrémenter l'expérience utilisateur. Ce que j'aime dans Compiz c'est le placement des fenêtres sur la moitié droite et la moitié gauche en un raccourci clavier, le cube avec les engrenages, et les fenêtres qui se déforment. C'est gadget, sauf le placement. (…)
Bon, le titre trollesque, c'est juste pour attirer le chaland. En fait, c'est plus subtil.
Daniel Kahn Gillmor (alias dkg) a testé systemd sur Debian. Il y trouve des points positifs : la gestion des daemons, la gestion saine des états des processus, l'élimination de la redondance dans les scripts init, le démarrage des services réseaux. Bref, tout ce qui convient à un serveur robuste se trouve dans systemd.
Mais il est aussi inquiet. Principalement par deux choses :
Ces dernières semaines les personnes clés des principales distributions se sont réunies pour discuter des problèmes liés aux données d'exécution (runtime data) utilisées lors de la phase de démarrage et surtout de leurs emplacements.
Lors du démarrage d'un système GNU/Linux différents programmes (initscripts, dracut, mdadm, etc) ont besoin de stocker leurs données d'exécution dans l'arborescence et cela avant les éventuels montages annexes (/home, /usr ou /var). Ces données sont aussi utilisées par les programmes et daemons lors du fonctionnement du système.
Actuellement, les distributions utilisent différents subterfuges pour stocker ce type de données dans des dossiers cachés : /dev/.mdadm, /dev/.mount, /dev/.systemd, /dev/.udev, etc. Elles utilisent pour la plupart le répertoire /dev pour stocker les premières données, ce dossier est de type tmpfs et est disponible dès les premiers instants du démarrage.
À la suite des derniers montages (/home, /usr ou /var) les daemons sont lancés, ils utilisent principalement le dossier /var/run pour leurs données et cherchent les données liées au démarrage dans les différents dossiers /dev/.xxx ou autres selon les distributions.
Pour en finir avec cette cacophonie, les principales distributions ont décidé d'ajouter le dossier "run" à la racine. Ce dossier fera partie de l'arborescence initiale des prochaines versions, il contiendra les données contenues auparavant dans les dossiers /dev/.xxx, /var/run, /var/lock, /lib/init/rw, etc.
Cette décision est techniquement simple et simplifie la liaison entre les données liées au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.
Les développeurs de dracut, udev et systemd ont déjà mis à jour ces logiciels. Les distributions utiliseront le répertoire /run de façon progressive avec, dans un premier temps, des montages de type bind des anciens répertoires vers /run.
Lennart Poettering (Pulseaudio, avahi, systemd) a rédigé un mail pour faire le point sur cette réunion, annoncer le changement et les phases de mise en place.
Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !
N. D. M. : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.