J'ai jamais vraiment compris l'idée de copier quelque chose qui existe pour en faire une version libre. Le bureau de macOS est beau certes, mais son gestionnaire de fenêtre est une calamité, à l'utiliser presque au quotidien je peux vous dire que je préfère de loin les gestionnaires de fenêtres que j'utilise sous Linux (que ce soit GNOME, dwm ou même KDE).
La barre de menu unifiée est historique et permet probablement de gagner de la place à l'écran mais elle reste contre intuitive aussi, quand votre application se situe en plein milieu de l'écran vous devez vraiment monter les yeux et la souris pour faire parfois des choses simples. Ça peut paraitre anecdotique, mais c'est le quotidien tout de même. En terme d'UX on a connu mieux. Je suis bien content que GNOME ait lâché l'idée pour l'intégrer directement dans la header bar.
Quitte à développer de nouvelles choses, autant faire quelque chose qu'on a jamais vu et de plus convivial.
git is great because linus did it, mercurial is better because he didn't
Coder un jeu en Java ? Il y a vraiment des gens sensés qui font ça de leur plein gré ?
Exit Android et Minecraft. à part ça j'ai jamais vu de jeu codés en Java sur ordinateurs ou consoles. C'est le dernier langage qui me viendrait à l'idée.
git is great because linus did it, mercurial is better because he didn't
Autant d'engagement pour le plus gros flop de Nintendo, il faut le faire. J'ai déjà joué à quelques jeux sur VB et à part Wario Land c'est presque que des navets.
Il y a beaucoup de choses que je comprends pas dans le projet.
Le code est du C++ mais il est dans des fichiers .c (en vrai cela ne pose pas de problème mais il faut configurer le compilateur pour qu'il considère ça comme du C++.
C'est un SDK pour développer un jeu natif pour Virtual Boy c'est bien ça ? Mais il y en a très peu dans la nature, alors on va finir par jouer que sur émulateur ?
git is great because linus did it, mercurial is better because he didn't
Aucun de ses composants n'est obligatoire et tous apportent des fonctionnalités intéressantes.
La création dynamique des périphériques dans /dev n'est pas spécialement nécessaire. Ce sont des points d'entrés spéciaux, en espace disque ça pèse rien. Avoir à les créer dynamiquement nécessite de gérer les permissions à la main et donc écrire des règles udev. Chez nous on doit en écrire pour changer les permissions des ports série pour que notre application ne tourne pas en root. Donc on est obligé de faire tourner udev (ou mdev) juste pour ça. Dans un système comme OpenBSD on fait un chmod/chown et ça persiste. Bien sûr udev reste utile pour d'autres choses comme charger des modules à la volée.
Pour ce qui est de l'audio, non ALSA seul est rarement utile. Enfin si sur une machine totalement statique. Mais sur un ordinateur portable où on va pouvoir le docker et donc faire apparaitre une carte son externe, un casque audio USB, une enceinte bluetooth il est primordial de faire tourner PulseAudio pour changer de périphérique à la volée sans éditer un asound.conf à chaque fois. PulseAudio a mis un certain temps à se stabiliser et voilà qu'on le jette pour passer à PipeWire. Il est bien loin le temps du « quand ça marche, ne touche à rien ». Chez OpenBSD il y en a qu'un seul : sndio.
Pourquoi avoir fait /sys alors qu'on a déjà /proc ? Sans parler du de l'architecture monstre qu'ils sont avec si peu de cohérence. Sur le papier l'idée est bonne, dans la pratique elle l'est moins.
git is great because linus did it, mercurial is better because he didn't
Vous ne vous êtes jamais demandé pourquoi votre téléphone a besoin de 30 à 60 secondes pour démarrer ?
Un Android oui. Un iPhone 12 mets 5 secondes montre en main. Pour une fois qu'Apple ne fait pas quelque chose de bloat.
Et puis, il y a le poids. Les applications web pourraient s’ouvrir jusqu’à 10 fois plus vite si on bloquait simplement toutes les publicités.
Il n'y a pas que les publicités. Il y a les tonnes de polices embarquées, le Javascript de 12 millions de ligne de code à charger. Etc. Là c'est pas un problème de technologie et de performance, juste un problème d'éducation.
git is great because linus did it, mercurial is better because he didn't
Impossible de se souvenir en avoir rencontré ces dernières années
Dans mon ancienne entreprise où on utilise npm/nodejs, slack, vscode le tout sur 8 Go de RAM. La construction du projet enclenchait très souvent l'OOM. Du pur délire.
git is great because linus did it, mercurial is better because he didn't
Quand je vois les protocoles de gestion Debian, j'ai l'impression d'avoir affaire à un véritable gouvernement. Tant de blablas, de procédures, de votes juste pour savoir si Debian est pour ou contre le retour de RMS. Si tout ce temps était passé à développer à la place on aurait des bureaux encore plus stables, non ?
git is great because linus did it, mercurial is better because he didn't
J'utilise gaim (avant de passer à pidgin) sur ma Fedora Core 3, j'avoue que j'aimais beaucoup. C'était principalement pour AIM (enfin je crois, ça remonte, j'ai honte d'oublier) à cette époque j'utilisais aussi IRC (via XChat), un peu de jabber et beaucoup de MSN (via le légendaire amsn, j'y étais !).
Aujourd'hui le seul que j'utilise encore c'est IRC. Pour moi c'est le protocol le plus adapté pour la communication brute instantanée : il a l'avantage de ne pas être gêné par des containers de gif, d'emojis, de “likes”, d'images, de vidéos encastrées, etc. Cet exemple en dit long sur la non-qualité du contenu dont IRC est exempt.
Concernant les autres protocols, j'ai un peu l'impression qu'ils sont morts non ? Qui utilise encore ICQ ? Zephyr et autres ? Malheureusement les plateformes « modernes » comme Slack/Discord ont tendance à faire de l'ombre aux autres.
git is great because linus did it, mercurial is better because he didn't
« cette fois ci c'est mon pouce que je lève pour nvidia »
En revanche, X.Org c'est bien, mais drm/kms ça serait mieux ou alors c'est déjà le cas ? J'avoue ne plus suivre l'actualité nvidia depuis un moment. Le commit en question ne concerne visiblement que xwayland donc je suis un peu confus.
git is great because linus did it, mercurial is better because he didn't
Il y a quelques années de cela Leah Rowe avait fait un drama et tout un scandale au sujet d'un probable licenciement d'une personne par la FSF et maintenant… elle défend RMS. On aura tout vu.
git is great because linus did it, mercurial is better because he didn't
Déjà faut savoir qu'un SSD et un m.2 c'est la même chose, c'est juste le format qui change. Pour des serveurs je crois pas que les SSD soient très fréquents déjà parce qu'ils sont onéreux à très grand volume mais forcément ils ne sont pas éternel et s'il y a beaucoup d'écriture il faudra surveiller l'usure.
Si tu souhaites simplement faire un serveur de stockage / sauvegarde ou petite écriture je pense qu'un disque dur sera largement suffisant.
Pourquoi pas un SSD pour le stockage de compilation comme tu l'a indiqué dans ton message aussi. En gros, un espèce de très large /tmp dédié à ce disque dur.
git is great because linus did it, mercurial is better because he didn't
Autant j'aime pas Rust autant cette remarque n'as pas de sens. Il y a beaucoup de modules python qui sont natifs (donc codés en C, C++ ou Rust). Ce n'est pas nouveau et c'est nécessaire pour certaines API (OpenGL, Qt, etc).
git is great because linus did it, mercurial is better because he didn't
Je le connais un peu car il est parmi les anciens contributeurs de la distribution Alpine dont je suis aussi contributeur.
Loin de moi l'idée de vouloir le dénigrer mais j'ai du mal avec sa façon de faire.
Il réinvente la roue pour beaucoup de choses et nous les impose par après. Chez Alpine il a voulu mettre en place son système de mailing list assez mauvais (peu personnalisable et quelques problèmes) et a décidé de partir dès lors qu'on a dit qu'on l'utiliserait plus pour contribuer. Il n'aime pas les manpage alors il a écrit son propre format bien plus minimaliste et largement pas assez flexible pour écrire des pages de qualité. Devinez quoi, il l'a mis en place dans les pages de manuel du gestionnaire de paquet apk. Cela signifie qu'en tant que nouveau contributeur, au lieu de pouvoir contribuer à quelque chose que vous connaissez, vous devez apprendre un nouveau format pour une seule et unique personne à cause du syndrome NIH. Il a aussi des opinions personnelles assez fortes et vous empêches littéralement de faire autrement (essayez d'envoyer un mail HTML sur Alpine ou avec une petite pièce jointe, vous allez être renvoyé vers une de ces pages perso. Il n'aime pas nvidia (oui nvidia c'est mal), mais ce n'est pas non plus obligatoire de faire pression sur ceux qui en ont une. C'est vrai que les deux cas sont à proscrire sur une ML mais bon). Quelques recherches sur HN/Reddit vous en dira un peu plus à son sujet.
Pour moi ce langage n'est qu'un énième syndrome NIH dont il est atteint alors comme il n'aime pas Rust, C++, Go ou autre langage moderne et ben… il en écrit un nouveau. Ainsi, ce dont j'ai à lui reprocher se répercutera sur son énième projet.
git is great because linus did it, mercurial is better because he didn't
Ils ont beaucoup de datacenter. Celui de Strasbourg n'est toujours pas rétabli (ils migrent vers Gravelines si j'ai bien compris). J'ai un dédié à Roubaix (bien accessible) mais mon VPS de Strasbourg est bien mort pour le moment.
En plus depuis hier je me disais qu'il était temps qu'un jour je fasse une copie de mes sauvegardes à la maison (mes laptops et mon NAS) sur un VPS ou un serveur de stockage car je me suis dit que je ne suis pas à l'abri d'un incendie ou cambriolage à la maison…
Comble du sort, bien que je fasse des backups de mon dédié, j'ai jamais encore pris la peine de faire un backup de mon VPS (car c'est juste un petit blog et un shell permanent). Mais bon là je peux m'en prendre qu'à moi même.
git is great because linus did it, mercurial is better because he didn't
Joli bug destructeur en effet. Heureusement avec une portée limitée, plus grand monde n'utilise de fichier de swap aujourd'hui et probablement encore moins une RC du noyau Linux (même si elles ont tendance à être solides comme le rappel également Linus).
Pourtant moi je trouve que c'est la meilleure solution. Au lieu d'avoir une partition swap d'une taille arbitraire, on pourrait créer des fichiers swap à la volée quand le système en a besoin comme macOS fait (et Windows).
Le seul problème, c'est qu'il faudrait que ce soit géré par le kernel lui même sans doute.
git is great because linus did it, mercurial is better because he didn't
J'avoue avoir très envie de savoir ce qui a été utilisé car c'est vraiment de très bonne qualité.
Je fais aussi de la musique et j'ai bien longtemps essayé d'utiliser ardour et quelques plugins comme calf, caps mais j'étais vraiment limité sans compter un nombre incalculable de bugs et crash d'ardour (bon j'avoue je l'utilise sous Alpine dont je suis le mainteneur) et aussi la complexité de mise en place avec Jack et le partage de carte son pour faire tourner ardour et d'autres logiciels (tuxguitar, etc).
Enfin bref, j'ai vendu mon âme au diable et acquis un petit MacBook pour faire de la MAO sous Logic Pro X et je dois avouer que malheureusement la MAO sous Linux est tout de même encore à des kms. J'ose espérer que ça puisse s'améliorer mais avec les éditeurs de plugins comme Native Instruments qui font que des VST (et pas de lv2 ni ladspa) je pense qu'on sera malheureusement toujours en retard. Idem pour ma carte son (une Focusrite 4i4) qui n'est pas configurable sans un logiciel propriétaire uniquement disponible sous macOS/Windows.
À mon avis le “year of the Linux on desktop” est plus proche que “year of the MAO on Linux”.
Mais comme diraient certains ”use the appropriate tool for the job”.
git is great because linus did it, mercurial is better because he didn't
# Je ne comprends pas
Posté par David Demelier (site web personnel) . En réponse au lien Airyx: un OS libre proche macosx basé sur FreeBSD. Évalué à 5.
J'ai jamais vraiment compris l'idée de copier quelque chose qui existe pour en faire une version libre. Le bureau de macOS est beau certes, mais son gestionnaire de fenêtre est une calamité, à l'utiliser presque au quotidien je peux vous dire que je préfère de loin les gestionnaires de fenêtres que j'utilise sous Linux (que ce soit GNOME, dwm ou même KDE).
La barre de menu unifiée est historique et permet probablement de gagner de la place à l'écran mais elle reste contre intuitive aussi, quand votre application se situe en plein milieu de l'écran vous devez vraiment monter les yeux et la souris pour faire parfois des choses simples. Ça peut paraitre anecdotique, mais c'est le quotidien tout de même. En terme d'UX on a connu mieux. Je suis bien content que GNOME ait lâché l'idée pour l'intégrer directement dans la header bar.
Quitte à développer de nouvelles choses, autant faire quelque chose qu'on a jamais vu et de plus convivial.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Un titre pareil...
Posté par David Demelier (site web personnel) . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 0.
Malheureusement les années 2020 et celles à venir sont enrichies par la génération fragile et cancel culture. Il n'y a rien que l'on puisse faire.
git is great because linus did it, mercurial is better because he didn't
# Vraiment ?
Posté par David Demelier (site web personnel) . En réponse au lien FXGL : un moteur de jeu pour Java. Évalué à 0.
Coder un jeu en Java ? Il y a vraiment des gens sensés qui font ça de leur plein gré ?
Exit Android et Minecraft. à part ça j'ai jamais vu de jeu codés en Java sur ordinateurs ou consoles. C'est le dernier langage qui me viendrait à l'idée.
git is great because linus did it, mercurial is better because he didn't
# Il faut être fan
Posté par David Demelier (site web personnel) . En réponse au lien VUEngine : un moteur de jeu libre pour le Virtual Boy de Nintendo. Évalué à 4. Dernière modification le 17 juin 2021 à 08:49.
Et ben.
Autant d'engagement pour le plus gros flop de Nintendo, il faut le faire. J'ai déjà joué à quelques jeux sur VB et à part Wario Land c'est presque que des navets.
Il y a beaucoup de choses que je comprends pas dans le projet.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'est pas un peu la mode du moment ?
Posté par David Demelier (site web personnel) . En réponse au lien Le désenchantement du logiciel. Évalué à 5.
La création dynamique des périphériques dans /dev n'est pas spécialement nécessaire. Ce sont des points d'entrés spéciaux, en espace disque ça pèse rien. Avoir à les créer dynamiquement nécessite de gérer les permissions à la main et donc écrire des règles udev. Chez nous on doit en écrire pour changer les permissions des ports série pour que notre application ne tourne pas en root. Donc on est obligé de faire tourner udev (ou mdev) juste pour ça. Dans un système comme OpenBSD on fait un chmod/chown et ça persiste. Bien sûr udev reste utile pour d'autres choses comme charger des modules à la volée.
Pour ce qui est de l'audio, non ALSA seul est rarement utile. Enfin si sur une machine totalement statique. Mais sur un ordinateur portable où on va pouvoir le docker et donc faire apparaitre une carte son externe, un casque audio USB, une enceinte bluetooth il est primordial de faire tourner PulseAudio pour changer de périphérique à la volée sans éditer un asound.conf à chaque fois. PulseAudio a mis un certain temps à se stabiliser et voilà qu'on le jette pour passer à PipeWire. Il est bien loin le temps du « quand ça marche, ne touche à rien ». Chez OpenBSD il y en a qu'un seul : sndio.
Pourquoi avoir fait /sys alors qu'on a déjà /proc ? Sans parler du de l'architecture monstre qu'ils sont avec si peu de cohérence. Sur le papier l'idée est bonne, dans la pratique elle l'est moins.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'est pas un peu la mode du moment ?
Posté par David Demelier (site web personnel) . En réponse au lien Le désenchantement du logiciel. Évalué à 3.
On peut toujours utiliser ce qu'on veut en WM mais sur certains points on ne peut toujours rien faire :
git is great because linus did it, mercurial is better because he didn't
# Quelques notes
Posté par David Demelier (site web personnel) . En réponse au lien Le désenchantement du logiciel. Évalué à 8.
Un Android oui. Un iPhone 12 mets 5 secondes montre en main. Pour une fois qu'Apple ne fait pas quelque chose de bloat.
Il n'y a pas que les publicités. Il y a les tonnes de polices embarquées, le Javascript de 12 millions de ligne de code à charger. Etc. Là c'est pas un problème de technologie et de performance, juste un problème d'éducation.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par David Demelier (site web personnel) . En réponse au lien Le désenchantement du logiciel. Évalué à 4.
Dans mon ancienne entreprise où on utilise npm/nodejs, slack, vscode le tout sur 8 Go de RAM. La construction du projet enclenchait très souvent l'OOM. Du pur délire.
git is great because linus did it, mercurial is better because he didn't
# Ça sent une incompatibilité binaire
Posté par David Demelier (site web personnel) . En réponse au message erreur de segmentation sur SDL_Init . Évalué à 2.
Ça me parait très bizarre comme problème. Ton système est à jour ? tu es sous quelle distribution ?
Tu utilises bien la SDL 2 fournie par ton système ? pas installée à la main ou autre ?
git is great because linus did it, mercurial is better because he didn't
# Debian ? Un gouvernement distribution
Posté par David Demelier (site web personnel) . En réponse au lien Debian décide de ne pas se prononcer sur le retour de Richard Stallman au sein de direction dela FSF. Évalué à -5. Dernière modification le 20 avril 2021 à 09:12.
Quand je vois les protocoles de gestion Debian, j'ai l'impression d'avoir affaire à un véritable gouvernement. Tant de blablas, de procédures, de votes juste pour savoir si Debian est pour ou contre le retour de RMS. Si tout ce temps était passé à développer à la place on aurait des bureaux encore plus stables, non ?
git is great because linus did it, mercurial is better because he didn't
[^] # Re: J'ai cru que GNU avait une idée sur WASM
Posté par David Demelier (site web personnel) . En réponse au lien We’re excited to kick off the GNU Assembly and its web site!. Évalué à 3.
Non tu n'es pas le seul !
git is great because linus did it, mercurial is better because he didn't
# Quand j'étais jeune...
Posté par David Demelier (site web personnel) . En réponse au journal GAIM, c'est fini. Évalué à 3.
J'utilise gaim (avant de passer à pidgin) sur ma Fedora Core 3, j'avoue que j'aimais beaucoup. C'était principalement pour AIM (enfin je crois, ça remonte, j'ai honte d'oublier) à cette époque j'utilisais aussi IRC (via XChat), un peu de jabber et beaucoup de MSN (via le légendaire amsn, j'y étais !).
Aujourd'hui le seul que j'utilise encore c'est IRC. Pour moi c'est le protocol le plus adapté pour la communication brute instantanée : il a l'avantage de ne pas être gêné par des containers de gif, d'emojis, de “likes”, d'images, de vidéos encastrées, etc. Cet exemple en dit long sur la non-qualité du contenu dont IRC est exempt.
Concernant les autres protocols, j'ai un peu l'impression qu'ils sont morts non ? Qui utilise encore ICQ ? Zephyr et autres ? Malheureusement les plateformes « modernes » comme Slack/Discord ont tendance à faire de l'ombre aux autres.
git is great because linus did it, mercurial is better because he didn't
# Comme dirait Linus
Posté par David Demelier (site web personnel) . En réponse au lien X.Org Server Git lands support for hardware-accelerated XWayland with NVIDIA. Évalué à 2.
« cette fois ci c'est mon pouce que je lève pour nvidia »
En revanche, X.Org c'est bien, mais drm/kms ça serait mieux ou alors c'est déjà le cas ? J'avoue ne plus suivre l'actualité nvidia depuis un moment. Le commit en question ne concerne visiblement que xwayland donc je suis un peu confus.
git is great because linus did it, mercurial is better because he didn't
# Question à propos du clavier
Posté par David Demelier (site web personnel) . En réponse au journal Allez, il fallait bien que ça arrive. Évalué à 10.
Est-ce que ça ne serait tout simplement pas un clavier qui se blo
git is great because linus did it, mercurial is better because he didn't
# Leah Rowe retourne sa veste, son pantalon et probablement son slip
Posté par David Demelier (site web personnel) . En réponse au lien Site dédié à la défense de Stallman . Évalué à 0.
Il y a quelques années de cela Leah Rowe avait fait un drama et tout un scandale au sujet d'un probable licenciement d'une personne par la FSF et maintenant… elle défend RMS. On aura tout vu.
git is great because linus did it, mercurial is better because he didn't
# Trop gros
Posté par David Demelier (site web personnel) . En réponse au lien Mageia 9 va changer radicalement : paquets, CCM etc. . Évalué à 3.
Ça passera pas.
git is great because linus did it, mercurial is better because he didn't
# Ça dépend de l'utilisation
Posté par David Demelier (site web personnel) . En réponse au message Choix disque dur : mécanique, SSD ou SSD M.2 ?. Évalué à 2.
Déjà faut savoir qu'un SSD et un m.2 c'est la même chose, c'est juste le format qui change. Pour des serveurs je crois pas que les SSD soient très fréquents déjà parce qu'ils sont onéreux à très grand volume mais forcément ils ne sont pas éternel et s'il y a beaucoup d'écriture il faudra surveiller l'usure.
Si tu souhaites simplement faire un serveur de stockage / sauvegarde ou petite écriture je pense qu'un disque dur sera largement suffisant.
Pourquoi pas un SSD pour le stockage de compilation comme tu l'a indiqué dans ton message aussi. En gros, un espèce de très large /tmp dédié à ce disque dur.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Drew ? J'ai un peu du mal avec ce type
Posté par David Demelier (site web personnel) . En réponse au journal Appel à contribution pour un nouveau langage !. Évalué à 7.
Non ce n'est pas si simple. Rust est bien moins portable que C et ne tourne pas sur toutes les architectures.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Drew ? J'ai un peu du mal avec ce type
Posté par David Demelier (site web personnel) . En réponse au journal Appel à contribution pour un nouveau langage !. Évalué à 4.
Autant j'aime pas Rust autant cette remarque n'as pas de sens. Il y a beaucoup de modules python qui sont natifs (donc codés en C, C++ ou Rust). Ce n'est pas nouveau et c'est nécessaire pour certaines API (OpenGL, Qt, etc).
git is great because linus did it, mercurial is better because he didn't
# Drew ? J'ai un peu du mal avec ce type
Posté par David Demelier (site web personnel) . En réponse au journal Appel à contribution pour un nouveau langage !. Évalué à 10. Dernière modification le 25 mars 2021 à 11:24.
Je le connais un peu car il est parmi les anciens contributeurs de la distribution Alpine dont je suis aussi contributeur.
Loin de moi l'idée de vouloir le dénigrer mais j'ai du mal avec sa façon de faire.
Il réinvente la roue pour beaucoup de choses et nous les impose par après. Chez Alpine il a voulu mettre en place son système de mailing list assez mauvais (peu personnalisable et quelques problèmes) et a décidé de partir dès lors qu'on a dit qu'on l'utiliserait plus pour contribuer. Il n'aime pas les manpage alors il a écrit son propre format bien plus minimaliste et largement pas assez flexible pour écrire des pages de qualité. Devinez quoi, il l'a mis en place dans les pages de manuel du gestionnaire de paquet apk. Cela signifie qu'en tant que nouveau contributeur, au lieu de pouvoir contribuer à quelque chose que vous connaissez, vous devez apprendre un nouveau format pour une seule et unique personne à cause du syndrome NIH. Il a aussi des opinions personnelles assez fortes et vous empêches littéralement de faire autrement (essayez d'envoyer un mail HTML sur Alpine ou avec une petite pièce jointe, vous allez être renvoyé vers une de ces pages perso. Il n'aime pas nvidia (oui nvidia c'est mal), mais ce n'est pas non plus obligatoire de faire pression sur ceux qui en ont une. C'est vrai que les deux cas sont à proscrire sur une ML mais bon). Quelques recherches sur HN/Reddit vous en dira un peu plus à son sujet.
Pour moi ce langage n'est qu'un énième syndrome NIH dont il est atteint alors comme il n'aime pas Rust, C++, Go ou autre langage moderne et ben… il en écrit un nouveau. Ainsi, ce dont j'ai à lui reprocher se répercutera sur son énième projet.
git is great because linus did it, mercurial is better because he didn't
# Digital
Posté par David Demelier (site web personnel) . En réponse au lien Comment dit-on en français data science, backdoor, digital..? - france inter. Évalué à 6. Dernière modification le 10 mars 2021 à 09:51.
Ça fait des années que je lutte contre digital, mais il est déjà présent dans l'académie française depuis un moment :
http://academie-francaise.fr/digital
Malgré ça, beaucoup de gens de mauvaise foi continuent de m'argumenter que c'est tout à fait tolérable.
git is great because linus did it, mercurial is better because he didn't
# Toujours down à Strasbourg
Posté par David Demelier (site web personnel) . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 8. Dernière modification le 10 mars 2021 à 09:47.
Ils ont beaucoup de datacenter. Celui de Strasbourg n'est toujours pas rétabli (ils migrent vers Gravelines si j'ai bien compris). J'ai un dédié à Roubaix (bien accessible) mais mon VPS de Strasbourg est bien mort pour le moment.
En plus depuis hier je me disais qu'il était temps qu'un jour je fasse une copie de mes sauvegardes à la maison (mes laptops et mon NAS) sur un VPS ou un serveur de stockage car je me suis dit que je ne suis pas à l'abri d'un incendie ou cambriolage à la maison…
Comble du sort, bien que je fasse des backups de mon dédié, j'ai jamais encore pris la peine de faire un backup de mon VPS (car c'est juste un petit blog et un shell permanent). Mais bon là je peux m'en prendre qu'à moi même.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Dans la langue de Jean-Baptiste Poquelin
Posté par David Demelier (site web personnel) . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à 3.
La taille des disques ? Les ultrabooks avec NVMe ont rarement des très grandes tailles (on est plutôt sur du 256Go/512Go).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Dans la langue de Jean-Baptiste Poquelin
Posté par David Demelier (site web personnel) . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à 5.
Pourtant moi je trouve que c'est la meilleure solution. Au lieu d'avoir une partition swap d'une taille arbitraire, on pourrait créer des fichiers swap à la volée quand le système en a besoin comme macOS fait (et Windows).
Le seul problème, c'est qu'il faudrait que ce soit géré par le kernel lui même sans doute.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Puisqu'on est sur linuxfr...
Posté par David Demelier (site web personnel) . En réponse au journal Sortie de mon premier album de musique libre : Flammes. Évalué à 6. Dernière modification le 02 mars 2021 à 14:36.
J'avoue avoir très envie de savoir ce qui a été utilisé car c'est vraiment de très bonne qualité.
Je fais aussi de la musique et j'ai bien longtemps essayé d'utiliser ardour et quelques plugins comme calf, caps mais j'étais vraiment limité sans compter un nombre incalculable de bugs et crash d'ardour (bon j'avoue je l'utilise sous Alpine dont je suis le mainteneur) et aussi la complexité de mise en place avec Jack et le partage de carte son pour faire tourner ardour et d'autres logiciels (tuxguitar, etc).
Enfin bref, j'ai vendu mon âme au diable et acquis un petit MacBook pour faire de la MAO sous Logic Pro X et je dois avouer que malheureusement la MAO sous Linux est tout de même encore à des kms. J'ose espérer que ça puisse s'améliorer mais avec les éditeurs de plugins comme Native Instruments qui font que des VST (et pas de lv2 ni ladspa) je pense qu'on sera malheureusement toujours en retard. Idem pour ma carte son (une Focusrite 4i4) qui n'est pas configurable sans un logiciel propriétaire uniquement disponible sous macOS/Windows.
À mon avis le “year of the Linux on desktop” est plus proche que “year of the MAO on Linux”.
Mais comme diraient certains ”use the appropriate tool for the job”.
git is great because linus did it, mercurial is better because he didn't