DP-Tool ça me dit rien je pense que je l'avais acheté à la FNAC (oui, véridique !).
Merci, je vais tenter de chercher la pochette, c'est un souvenir fort, et je voulais retrouver les versions, notamment celle du kernel. Avec l'information version 3 et codename slack, c'est déjà un indice. Merci !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je me souviens que ma première install de Linux sur un PC (pentium 90, je pense vers 1995) était une Slackware. A l'époque le noyau Linux se compilait en modifiant directement le Makefile (1.0 ? 1.2 ?). J'avais un CD avec un livret 4 pages qui décrivait comment faire pour installer (fdisk…).
Sur la pochette, il y avait une grosse molécule, image en raytracing je pense.
Qqu'un saurait me dire de quelle version il s'agissait ?
Merci :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je comprends, mais c'est pas du tout le rôle de Risc-V de spécifier ça.
Mais les standardisations ça existe déjà : UEFI pour bootloader/initialiser le hardware, PCI (pour détecter le hardware c'est bien foutu), device tree (pour décrire le hardware d'une plateforme embarquée) etc. Tout ça ça existe déjà, et c'est pas assez utilisé par les fabricants. Alors je ne suis pas sûr qu'en en rajoutant une ça change les choses.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Spécifier la plateforme serait contraire à leur but : ils veulent juste spécifier une ISA commune cross-cible (ils visent autant un Arduino qu'un data center), et aider les concepteurs de CPU à faire leurs optimisations dans tous les cas.
Pour illustrer, WesterDigital compte fabriquer 1 milliards de controleurs Risc-V pour mettre dans leurs disques durs, inutile de te dire que c'est du très très très "low spec", on est loin d'un kernel Linux.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Est-ce que ça veut dire que chaque fabriquant va faire son propre RISC-V custom?
Oui c'est le but.
j'imagine que demain ce sera encore pire avec RISC-V
Non c'est pas le but.
Attention ensuite, la difficulté de booter une plateforme est rarement dûe au CPU, mais à tout ce qu'il y a autour (à commencer par le bootloader). Avec Risc-V, la partie CPU est définitivement réglée, mais ça ne changera rien au fait que chaque plateforme continuera avec ses spécificités qui feront que booter un kernel Linux n'aura rien d'évident.
Mais c'est une brique de plus dans le bon sens.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Exactement, sachant qu'en plus Risc-V propose un mécanisme précis (exception spécifique du processeur) pour qu'une instruction non implémentée dans ton hardware soit tout de même exécutable en software.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
si t'aimes scripter, awk est une autre bonne idée. pour peu que tu lui donnes à manger des données assez faciles à traiter (par exemple un export CSV), écrire les quelques fonctions dont tu as besoin c'est pas très dur.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Tu pars sur une Debian en mode console seulement : tu mets sur clé USB l'installateur "netboot" qui est tout petit et qui ne télécharge que ce qui est nécessaire. De plus il est toujours très récent et boote à la fois les tous derniers ordis (vital quand tu achètes une carte mère de luxe) ou les vieilles croutes (vécu sur 2 eeePC).
Ensuite tu peux ajouter ton environnement graphique (XFCE est très mignon je trouve) et tes applis.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Pardon j'ai mis cache, je voulais dire swap bien sûr. C'est le seul signe qui dit que ton système "n'a pas assez de RAM". Pour le reste, il se contente de :
- allouer la RAM nécessaire aux nouveaux processus
- allouer de la RAM supplémentaire aux processus qui le demandent (malloc)
- utiliser à volonté du cache disque pour accélérer les transferts futurs
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je suis d'autant plus triste que je l'ai redécouvert il y a quelques années. C'était un super chansonnier, avec des paroles singlantes.
Ecoutez "les règles bleues" (sur la société de consommation), "qui a coulé l'Erika ?" (la pollution c'est la faute à personne), ou le délicieux "Capitaine" où il raconte ses années Dorothée en riant jaune (https://www.youtube.com/watch?v=qVDerBs6z1c)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Mon opinion est que le cycle en V fonctionne bien pour l'informatique embarquée où tout peut et doit être spécifié
Même pas. J'ai utilisé des méthodes agiles dans l'avionique, dans la téléphonie, et maintenant dans l'automobile. Problèmes nouveaux, complexes… les specs sont à la rue dès le premier jour. En utilisant des méthodes agiles, tu rebondis plus facilement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
L'agile en deux mots comme je l'ai vécu précédemment dans une grosse entreprise, au milieu de grosses équipes : si tu innoves, tu écriras nécessairement des specs merdiques parce que tu vas te tromper (personne n'est génial sur commande). Alors écris tes specs merdiques (il en faut, on est d'accord), mais n'y passe pas trop de temps dessus. Confronte rapidement à la réalité (code et tests, tests, tests, tests), et revient sur tes specs.
En faisant des boucles courtes tu :
- écris une spec qui marche
- écris un code qui marche
- teste infiniement plus
bcp plus vite, et de meilleure qualité.
Si tu es capable d'écrire d'emblée des specs d'excellente qualité (peut-etre parce que tu pars d'un existant éprouvé, que tu suis une norme, que tu as un système simple et dont tu peux intellecutellement faire le tour assez facilement), c'est peut-être pas le mieux. Mais si tu pars à l'aventure d'une manière ou d'une autre, c'est pour moi LA méthode de travail indiscutable.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Est-ce que la vague actuelle (pour pas dire mode, mais rien de péjoratif) des méthodes agiles ne serait pas de manière détournée une reconnaissance de ce constat ? Pour être efficace, on ne peut pas partir du principe qu'on va tout planifier à l'avance : laissons les équipes expérimenter, revenir avec une 2e version etc.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: slackounet
Posté par gUI (Mastodon) . En réponse au journal Slackware a un quart de siècle !. Évalué à 4.
L'existence même de l'option
--fix-brokenest quand même un aveu, non ?(attention, j'aime bcp Debian, j'utilise Debian partout, et Ubuntu sinon, donc autant dire que je ne crache pas sur le système de paquets
apt)En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Amener/Apporter
Posté par gUI (Mastodon) . En réponse au message Lowcost et formulations infantilisantes. Évalué à 4.
J'ai bon ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Amener/Apporter
Posté par gUI (Mastodon) . En réponse au message Lowcost et formulations infantilisantes. Évalué à 2.
A y être : emmène vs amène ? J'avoue que…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Appel à témoin
Posté par gUI (Mastodon) . En réponse au journal Slackware a un quart de siècle !. Évalué à 3.
DP-Tool ça me dit rien je pense que je l'avais acheté à la FNAC (oui, véridique !).
Merci, je vais tenter de chercher la pochette, c'est un souvenir fort, et je voulais retrouver les versions, notamment celle du kernel. Avec l'information version 3 et codename slack, c'est déjà un indice. Merci !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Appel à témoin
Posté par gUI (Mastodon) . En réponse au journal Slackware a un quart de siècle !. Évalué à 4.
Tiens j'en profite, pour faire un appel à témoin.
Je me souviens que ma première install de Linux sur un PC (pentium 90, je pense vers 1995) était une Slackware. A l'époque le noyau Linux se compilait en modifiant directement le Makefile (1.0 ? 1.2 ?). J'avais un CD avec un livret 4 pages qui décrivait comment faire pour installer (fdisk…).
Sur la pochette, il y avait une grosse molécule, image en raytracing je pense.
Qqu'un saurait me dire de quelle version il s'agissait ?
Merci :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Indice
Posté par gUI (Mastodon) . En réponse au message Conversion de datetime vers timestamp. Évalué à 6.
Il y a exactement 2 heures d'écart (7200 secondes) entre tes deux valeurs. On se doute que l'une est en UTC, l'autre en heure locale.
Ta première fonction parle clairement d'UTC, alors que la deuxième (ta tentative de reverse) n'indique rien… peut-être est-elle en heure locale ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool
Posté par gUI (Mastodon) . En réponse au journal Guido van Rossum se retire de la direction de Python. Évalué à 2. Dernière modification le 13 juillet 2018 à 11:05.
j'avais vu passer sans comprendre l'intérêt. même si au final je préfère la méthode traditionnelle, au moins j'ai compris :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Point de vue pragmatique mais
Posté par gUI (Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 5.
Je comprends, mais c'est pas du tout le rôle de Risc-V de spécifier ça.
Mais les standardisations ça existe déjà : UEFI pour bootloader/initialiser le hardware, PCI (pour détecter le hardware c'est bien foutu), device tree (pour décrire le hardware d'une plateforme embarquée) etc. Tout ça ça existe déjà, et c'est pas assez utilisé par les fabricants. Alors je ne suis pas sûr qu'en en rajoutant une ça change les choses.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Fragmentation risk
Posté par gUI (Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 2.
Non je ne sais pas, juste que je l'ai lu dans un bouquin d'introduction à Risc-V.
Peut-être vont-ils motiver les implémentations software pour le faire à fond ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Point de vue pragmatique mais
Posté par gUI (Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 8.
Spécifier la plateforme serait contraire à leur but : ils veulent juste spécifier une ISA commune cross-cible (ils visent autant un Arduino qu'un data center), et aider les concepteurs de CPU à faire leurs optimisations dans tous les cas.
Pour illustrer, WesterDigital compte fabriquer 1 milliards de controleurs Risc-V pour mettre dans leurs disques durs, inutile de te dire que c'est du très très très "low spec", on est loin d'un kernel Linux.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Point de vue pragmatique mais
Posté par gUI (Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 10. Dernière modification le 11 juillet 2018 à 08:19.
Oui c'est le but.
Non c'est pas le but.
Attention ensuite, la difficulté de booter une plateforme est rarement dûe au CPU, mais à tout ce qu'il y a autour (à commencer par le bootloader). Avec Risc-V, la partie CPU est définitivement réglée, mais ça ne changera rien au fait que chaque plateforme continuera avec ses spécificités qui feront que booter un kernel Linux n'aura rien d'évident.
Mais c'est une brique de plus dans le bon sens.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Fragmentation risk
Posté par gUI (Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 6. Dernière modification le 11 juillet 2018 à 08:16.
Exactement, sachant qu'en plus Risc-V propose un mécanisme précis (exception spécifique du processeur) pour qu'une instruction non implémentée dans ton hardware soit tout de même exécutable en software.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Com commerciale...
Posté par gUI (Mastodon) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 10.
Moi ce qui me fait marrer c'est que c'est surtout une vraie reconnaissance pour Risc-V.
Merci ARM pour la mise en lumière !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Le bon vieux Awk
Posté par gUI (Mastodon) . En réponse au message quel outil pour traiter une base de données moyenne. Évalué à 3.
si t'aimes scripter, awk est une autre bonne idée. pour peu que tu lui donnes à manger des données assez faciles à traiter (par exemple un export CSV), écrire les quelques fonctions dont tu as besoin c'est pas très dur.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Debian minimale
Posté par gUI (Mastodon) . En réponse au message Distro avec Fluxbox (ou openbox) pour EEEPC. Évalué à 5.
Tu pars sur une Debian en mode console seulement : tu mets sur clé USB l'installateur "netboot" qui est tout petit et qui ne télécharge que ce qui est nécessaire. De plus il est toujours très récent et boote à la fois les tous derniers ordis (vital quand tu achètes une carte mère de luxe) ou les vieilles croutes (vécu sur 2 eeePC).
Ensuite tu peux ajouter ton environnement graphique (XFCE est très mignon je trouve) et tes applis.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Amertume
Posté par gUI (Mastodon) . En réponse au journal SUSE passe sous giron suédois. Évalué à 7.
A la limite coupé au Ricard, mais vraiment c'est trop amer pour moi.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Mon prono au début de la compétition
Posté par gUI (Mastodon) . En réponse au journal Le moment crucial. Évalué à 2.
c'était l'Argentine championne du monde… alors maintenant je m'abstiens :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Imparable
Posté par gUI (Mastodon) . En réponse au message Fuite mémoire. Évalué à 2.
Pardon j'ai mis cache, je voulais dire swap bien sûr. C'est le seul signe qui dit que ton système "n'a pas assez de RAM". Pour le reste, il se contente de :
- allouer la RAM nécessaire aux nouveaux processus
- allouer de la RAM supplémentaire aux processus qui le demandent (malloc)
- utiliser à volonté du cache disque pour accélérer les transferts futurs
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Imparable
Posté par gUI (Mastodon) . En réponse au message Fuite mémoire. Évalué à 3.
Est-ce que ton système utilise le cache ? Si oui, en effet tu as un soucis de mémoire. Si non, alors ça veut dire qu'il est encore en zone de confort.
Envoie un exemple de commande "free" à un moment où tu estimes que c'est anormal.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Euh par contre la quantité…
Posté par gUI (Mastodon) . En réponse au journal Tectonique de la pâte thermique (Linux Pratique). Évalué à 4.
Oui et j'étale pas spécialement : je laisse le CPU le faire sous la compression du socket.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Chansonnier avant tout
Posté par gUI (Mastodon) . En réponse au journal [Rubrique nécrologique] François Corbier bronsonisé. Évalué à 10. Dernière modification le 02 juillet 2018 à 22:21.
Je suis d'autant plus triste que je l'ai redécouvert il y a quelques années. C'était un super chansonnier, avec des paroles singlantes.
Ecoutez "les règles bleues" (sur la société de consommation), "qui a coulé l'Erika ?" (la pollution c'est la faute à personne), ou le délicieux "Capitaine" où il raconte ses années Dorothée en riant jaune (https://www.youtube.com/watch?v=qVDerBs6z1c)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: En dernier recours
Posté par gUI (Mastodon) . En réponse au message Récupération de données sur Lyon. Évalué à 2.
C'est une blague ou ça fait partie des tentatives de dernier recours ?
Four, frigo je connaissais (et je comprends plus ou moins pourquoi). Mais centrifugeuse aussi ? Pour d’éventuels faux-contacts ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Agile... comment casser le charme!
Posté par gUI (Mastodon) . En réponse à la dépêche Formation « Développeur d’applications full stack » à l’INP de Toulouse, épisode 2. Évalué à 4. Dernière modification le 29 juin 2018 à 07:50.
Même pas. J'ai utilisé des méthodes agiles dans l'avionique, dans la téléphonie, et maintenant dans l'automobile. Problèmes nouveaux, complexes… les specs sont à la rue dès le premier jour. En utilisant des méthodes agiles, tu rebondis plus facilement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Agile... comment casser le charme!
Posté par gUI (Mastodon) . En réponse à la dépêche Formation « Développeur d’applications full stack » à l’INP de Toulouse, épisode 2. Évalué à 3. Dernière modification le 28 juin 2018 à 13:32.
L'agile en deux mots comme je l'ai vécu précédemment dans une grosse entreprise, au milieu de grosses équipes : si tu innoves, tu écriras nécessairement des specs merdiques parce que tu vas te tromper (personne n'est génial sur commande). Alors écris tes specs merdiques (il en faut, on est d'accord), mais n'y passe pas trop de temps dessus. Confronte rapidement à la réalité (code et tests, tests, tests, tests), et revient sur tes specs.
En faisant des boucles courtes tu :
- écris une spec qui marche
- écris un code qui marche
- teste infiniement plus
bcp plus vite, et de meilleure qualité.
Si tu es capable d'écrire d'emblée des specs d'excellente qualité (peut-etre parce que tu pars d'un existant éprouvé, que tu suis une norme, que tu as un système simple et dont tu peux intellecutellement faire le tour assez facilement), c'est peut-être pas le mieux. Mais si tu pars à l'aventure d'une manière ou d'une autre, c'est pour moi LA méthode de travail indiscutable.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quelques extraits
Posté par gUI (Mastodon) . En réponse au lien Travail : « Entre profit et pouvoir, le capitalisme préfère le pouvoir ». Évalué à 2.
Excellent article je confirme.
Est-ce que la vague actuelle (pour pas dire mode, mais rien de péjoratif) des méthodes agiles ne serait pas de manière détournée une reconnaissance de ce constat ? Pour être efficace, on ne peut pas partir du principe qu'on va tout planifier à l'avance : laissons les équipes expérimenter, revenir avec une 2e version etc.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.