freem a écrit 5059 commentaires

Pour explication au moins seur é, il y a une FAQ qui indique notamment qu'il est important de préciser la fourchette de salaire proposée, sans quoi une offre tombera quasi systématiquement dans les négatifs.

Edit : toujours réactualiser avant de poster… Nibel a fait mieux que moi.

Ben non, le lien fourni est pas le même. Merci, du coup, vais lire le tien, la technique m'intéresse plus que le people.

N'étant pas assez vieux, je me demandais ce que ce pauvre Zenitram avait a faire ici…

Bon, alors, du coup il existe un jeu au contenu libre, aussi. Sur IRC on m'a même parlé d'un tournoi d'ici peu, avis aux amateurs…

Les langages objets … ne sont pas antinomiques des langages impératifs

C'était mon propos, en fait. À ceci près que je considère l'objet comme un ajout, par-dessus l'impératif, tout en ayant toujours refusé la logique du "tout-objet", ce qui est peut-être la raison pour laquelle j'apprécie le C++: on a plusieurs paradigmes a dispo, mais le langage ne nous force jamais a les utiliser, et en utiliser un n'empêche évidemment pas d'utiliser les autres.
Je pense que c'est vraiment une des forces principales de ce langage (encore que, ça aurait été pas mal d'avoir des conteneurs standards qui n'obligent pas à utiliser les exceptions, mais d'un autre côté coder un tableau dynamique ou une liste chaînée sans exceptions n'est pas si complexe, et <algorithm> peut fonctionner même avec de simples pointeurs, donc ça me va).

au passage ces langages ont été écrit en C dans lequel on pouvait déjà faire de l'objet

Tout comme le compilateur swi-prolog, on peut donc dire qu'on peut faire du déclaratif pur en C… ou peut tout faire en C, après tout, sauf peut-être utiliser des CPU ternaires?

Le problème, c'est qu'en C il faut une attention de tous les instants pour ne pas écrire de bugs, ce qui est moins vrai (donc toujours vrai) dans les langages implémentant des couches plus hautes (et l'impact sur la performance CPU n'est pas toujours favorable au langage que l'on imagine: penser sort (C) vs std::sort (C++)).
Il faut aussi bien plus réfléchir pour faire des choses simples dans d'autres langages (au niveau architecture, j'entend. Est-ce un mal, par contre, je ne sais pas.).

Mais d'un autre côté, exposer une interface publique qui soit écrit dans une sous-partie du C, c'est la seule façon d'avoir une bibliothèque avec une ABI stable, qui soit relativement facile a embarquer dans d'autres langages (presque tous les langages ont au moins un moyen raisonnablement simple d'appeler du code d'une lib C… à condition que ça soit du C très traditionnel, j'imagine qu'utiliser les derniers apports du C peut casser pas mal de choses).

Du coup, c'est juste un moteur, non?

il y a aussi des limites à cette façon de procéder.

Il n'existe pas de panacée, clairement, cependant dans le cas de l'objet vs impératif, je dirais que l'objet est une évolution de l'impératif, et que la plupart des bibliothèques de fonctions C essaient de mimer au maximum (des capacités du C, qui sont très, très limitées) l'objet.

Par exemple, en C il y a typiquement des structures, qui ont chacune un jeu de fonctions dédiées, dont à minima une pour les initialiser, et une autre pour les détruire: il faut juste systématiquement penser à les appeler (aucun mécanisme de création ou destruction automatique), ce qui est une vraie cause de bugs (il est nécessaire d'être plus concentré pour écrire du C correct que pour écrire du C++ correct, et c'est vrai avec bien d'autres langages (que C requiert plus de concentration)). Ça rend l'écriture laborieuse, mais aussi la lecture et, pire, la maintenance.

D'un autre côté, la bibliothèque standard du C++ (langage multi-paradigme dans le sens ou, contrairement à du java par exemple, il n'y a pas besoin de se battre contre la syntaxe pour utiliser du code non-objet) la tendance est à réduire (et unifier) la richesse des interfaces objet de façon a avoir plus de fonctions, qui en fait exploitent implicitement l'interface des objets, de manière uniforme.

Pour essayer de faire plus clair, et en reprenant l'exemple de la DEL plus haut, on pourrait avoir:

class clignotant
{
public:
  virtual void allumer() =0;
  virtual void eteindre() =0;
  virtual bool actif() const =0;
};

class led : public clignotant {
private:
  pin_t m_broche;
  colour_t m_couleur;
  bool m_active;
  void actualiser() { m_broche = m_active ? 0xDEAD : 0xBEEF; }
public:
  void allumer() override { m_active = true; actualiser(); }
  void eteindre() override { m_active = false; actualiser(); }
  bool actif() const override { return m_active; }
};

void clignoter( clignotant& cible )
{
  if( cible.actif() ) { cible.eteindre(); return; }
  cible.allumer();
}

Et avoir clignoter à l'extérieur, comme une fonction générique. L'avantage de la sortir de l'objet, c'est qu'on peut dès lors lui passer des objets d'un type différents, mais qui peuvent aussi clignoter, a condition d'exposer la même interface (je n'ai pas d'exemple en tête pour compléter celui-ci).

Ce type de choses est impossible à faire proprement en C ou en java, puisque ces langages étant mono-paradigmes (enfin, pour java, c'est plus nuancé (templates), et ça a peut-être changé, mais je me souviens qu'il était nécessaire de faire une classe avec une méthode statique pour la fonction main(), obligatoire pour lancer un programme, ce qui montre le ridicule du purisme et n'est pas propre…).
Dans le cas de Java, tout doit être dans un objet, quitte a être déclaré statique.
Dans le cas du C, il n'existe pas de possibilité d'attacher un type utilisateur à une interface, d'une part, et d'autre part, en C, les arguments d'une fonction ne font pas partie de la signature de la-dite fonction, ce qui mène à ce genre de code:

double round(double x);
float roundf(float x);
long double roundl(long double x);

Il faut donc appeler une fonction différente selon le type de variable que l'on passe (c'est particulièrement criant quand on utilise opengl).

Malgré que l'exemple soit particulièrement trivial, on voit déjà plusieurs problèmes, qui sont certes contournables dans les langages cités, plus ou moins proprement, mais qui restent une charge mentale pour le développeur.

Mon point n'est pas de dire que C++ est meilleur, loin de la, juste, je considère que l'objet est une amélioration de l'impératif, qui, selon les langages, peu permettre d'avoir un code plus simple à maintenir sur le long terme, à condition de ne pas en abuser. Ce qui a été fait, encore et encore, et typiquement, les outils que je vois qui sont issus du début des années 2000 ou des 1990, sont bourré de l'idéologie "full-object" ce qui en rend souvent le code lourd, complexe, et ironiquement, peu réutilisable.

D'un autre côté, un langage comme prolog sera radicalement différent, et permets d'écrire certaines parties des programmes bien plus efficacement (en terme de temps passé à écrire le code, en tout cas) puisqu'au lieu de décrire ce que le programme fait, pas par pas, on décrit les règles qu'il doit appliquer à des données.
Je sais que ça a l'air similaire, mais ça ne l'est vraiment pas, je ne sais pas trop comment l'expliquer mais on laisse en fait le programme décider lui-même dans quel ordre il appliquera les règles.

Prolog est "un langage de programmation logique" selon wikipedia, et on peut vraiment parler de paradigme différent, du fait que la façon de réfléchir pour obtenir le programme final est vraiment différente, bien plus que dans la guéguerre impératif vs objet (qui gagnent de toute façon a être utilisés ensemble, et non l'un contre l'autre).

… dont le "shell" soit alsamixer.

Tous les getty que je connais permettent d'ignorer l'étape d'authentification, et de changer la commande utilisée au démarrage.
Configurer cet aspect dépend principalement de ton init, mais devrait être trivial avec la plupart des init (j'ai envie de dire, "sauf systemd" parce qu'en pratique je me souviens avoir voulu avoir le contrôle sur ce type d'opérations, et le faire proprement sur debian 9, c'était vrai foutoir, impossible de trouver un moyen de faire ça proprement… mais c'est peut-être un problème de l'implémentation Debian de systemd, je ne sais pas)…

Dans le cas de sysVinit, il faut aller modifier le fichier /etc/inittab, les lignes listant les TTYs actifs sont faciles à trouver, il suffit de grepper.
Dans le cas de runit, tu as normalement un fichier run par TTY.
Pour les autres, je ne sais pas (pour systemd, la réponse est peut-être dans le fil précédent).

Le dernier cas un peu spécifique que je vois est ngetty, vu qu'il fonctionne comme un daemon, sa configuration est probablement un peu spécifique, mais si tu l'utilises tu dois probablement l'avoir déjà lue.

digne d'un jeu d'il y a 10 ans

Euh… le truc en lien est digne des années 90 hein… ça fait plutôt 30 ans que 20…

libéralo-communisme

Le blanc-noir, ça s'appelle pas le gris?

A ce sujet, j'ai ouï dire que debian/kFreeBSD était pas morte, mais… héhé, il paraît qu'il faut aller le demander sur leur IRC, ce qui est, disons, pas motivant.

Donc, en tout petit, pour que personne le voie.

Perso, je me suis intéressé un peu a ce type d'écrans, et je pense qu'ils sont hyper intéressants pour ceux qui veulent des appareils simples à longue autonomie. Ils ne sont clairement pas pour le grand public, qui aime le jetable et se contre-branle de tout ce qui est pas lié à la mode et l'esthétique (donc, la mode).
Ils seraient parfaits pour servir de terminaux longue autonomie pour diverses télécommunications, malgré un retour à moins de couleurs. Examples: téléphones, IRC, multimètres, et en gros pas mal d'appareil de mesure.

De ce que j'ai lu il y a 1 ou 2 ans sur les écrans de type encre électronique, il y "trois" couleurs (de plus amples travaux étaient en cours): le blanc, le noir et le rouge, ainsi qu'une flopée de nuances pour le noir ou le rouge (d'où les guillemets autour du mot trois).
Il me semble donc plausible d'avoir des dégradés, mais je ne suis pas convaincu que ça marche pour avoir de "belles polices" au sens des possesseurs d'écrans de type haute résolution (quoique ça veuille dire).
Dans le cas de l'e-ink (pour écrire plus vite) il me semble également qu'il y a un certain nombre de problèmes de fréquence de rafraîchissement, etc, et que donc les micro-billes doivent être réalignées de temps en temps après trop d'«écritures».
Bref, ce ne sont que des trucs que j'ai vaguement compris, je peux me planter, mais l'objectif est surtout lié à la lisibilité en plein soleil et la faible consommation énergétique passive.
L'esthétique me semble largement secondaire et, au final, ça pourrait résulter en un retour a des valeurs un peu plus saines (à cause de contraintes mécaniques) en terme de logiciels moins bloatés (meilleurs pour la planète, d'une part, et surtout, surtout, moins durs à maintenir)

L'un des intérêts majeurs des e-inks c'est l'absence de besoin d'alimentation permanente (et donc la consommation hyper faible en énergie), et la lisibilité nickel en plein soleil… si en plus on ajoute le mot tablette, je ne vois pas ce qu'il te faut de plus comme indice?

attentions aux récursions infinies malheureuse!

Tu attendrais quoi d'un journal sur debian 11,à minima? (non, je me sens pas capable de faire une dépêche)

Donc, pour vivre libres, vivons sans communautés trop faciles d'accès, à défaut de cachées?
De plus en plus, je vois l'amalgame "logiciel libre == communauté qui contribue ensemble sur un projet unique" mais est-ce vraiment la réalité? Et si oui, est-ce que ça doit être le cas de tous les projets libres? Et dans tous les cas, comment filtrer les contributions néfastes, qui sont évidentes dès que ça buzz ou prend de l'ampleur (l'humain est ainsi fait qu'il y aura toujours des ordures prêtes à saccager le travail des autres pour leur profit unique)?

OpenSCAD prétend être un langage fonctionnel, mais il n'est pas possible de créer une fonction qui prend en paramètre un "objet"…

C'est normal, c'est (dys)fonctionnel, pas objet. Oups, pas vendredi… Perso, j'ai testé il y a quelques années divers softs de CAO: brlcad, solvespace, openscad et freecad, dans le but principalement de faire de l'impression 3D.
Le plus simple à utiliser, et de loin, c'est solvespace.
Par contre il n'est pas versionnable dans git ou svn (contrairement à openscad).
Il ne fait pas de RDM alors que brlcad le fait très probablement.
Contrairement à freecad, il ne fait que deux choses: des pièces et des assemblages de pièces fixes, ce qui le rend casse-pied pour de l'architecture dont les pièces peuvent être paramétriques (une poutre, par exemple).

Au final, il reste mon préféré. Parce que:
Comparé à openscad, il est utilisable sans être matheux.
Comparé à brlcad, il est facile à utiliser (brlcad est celui que j'ai le moins creusé).
Comparé à freecad, il est fini.

Je voulais dire GPU mea culpa :)

Je me permets de pointer le fait que solvespace propose sa propre bibliothèque en réponse à ton commentaire.

Mon cpu:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 158
model name  : Intel(R) Pentium(R) Gold G5500 CPU @ 3.80GHz
stepping    : 11
microcode   : 0x8e
cpu MHz     : 800.148
cache size  : 4096 KB
physical id : 0
siblings    : 4
core id     : 0
cpu cores   : 2
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 22
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms invpcid mpx rdseed smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml ept_mode_based_exec
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips    : 7599.80
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model       : 158
model name  : Intel(R) Pentium(R) Gold G5500 CPU @ 3.80GHz
stepping    : 11
microcode   : 0x8e
cpu MHz     : 799.994
cache size  : 4096 KB
physical id : 0
siblings    : 4
core id     : 1
cpu cores   : 2
apicid      : 2
initial apicid  : 2
fpu     : yes
fpu_exception   : yes
cpuid level : 22
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms invpcid mpx rdseed smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml ept_mode_based_exec
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips    : 7599.80
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model       : 158
model name  : Intel(R) Pentium(R) Gold G5500 CPU @ 3.80GHz
stepping    : 11
microcode   : 0x8e
cpu MHz     : 800.073
cache size  : 4096 KB
physical id : 0
siblings    : 4
core id     : 0
cpu cores   : 2
apicid      : 1
initial apicid  : 1
fpu     : yes
fpu_exception   : yes
cpuid level : 22
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms invpcid mpx rdseed smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml ept_mode_based_exec
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips    : 7599.80
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model       : 158
model name  : Intel(R) Pentium(R) Gold G5500 CPU @ 3.80GHz
stepping    : 11
microcode   : 0x8e
cpu MHz     : 800.000
cache size  : 4096 KB
physical id : 0
siblings    : 4
core id     : 1
cpu cores   : 2
apicid      : 3
initial apicid  : 3
fpu     : yes
fpu_exception   : yes
cpuid level : 22
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms invpcid mpx rdseed smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml ept_mode_based_exec
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips    : 7599.80
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

Je n'ai pas de CPU.

Cette machine est relativement récente, je connais solvespace depuis bien plus longtemps que ça et l'ai testé sur diverses autres machines, plus ou moins puissantes.
Pour des formes simples, sans trop de contraintes, ça passe partout, c'est vraiment un logiciel peu gourmand.

Une autre personne dans ce fil a parlé de solidworks, mais pour info, il existe un outil nommé BRLCAD qui est probablement plus vieux: l'histoire de son code source, disponible en libre, peut être tracé depuis les années 80, et je ne pense pas qu'il y avait des GPU aussi puissants que nos GPUs intégrés :)

Va taper mod+F3 pour lancer firefox quand tu n'y vois rien…

Ou tout simplement devant un pr0n, une main sur la souris, sur la… je plaisante. perso, j'apprécie avoir certains contrôles cliquables, en tout cas, notamment pour la radio (mpd), et donc j'utilise i3blocks, un remplaçant d'i3status.

Dans mon cas perso, j'ai fait de l'ascii art, parce que flemme de trouver une fonte qui supporte les bons glyphes, du coup ça ressemble à ça: 

Le code est ici: https://p.mort.coffee/hwu et s'utilise avec un bloc du type:

[mpcprev]
command=~/.bin/mpi3b.sh prev
interval=once
signal=10

[mpcstop]
command=~/.bin/mpi3b.sh stop
interval=once
signal=10

[mpcplay]
command=~/.bin/mpi3b.sh play
interval=once
signal=10

[mpcnext]
command=~/.bin/mpi3b.sh next
interval=once
signal=10

Dans la conf d'i3blocks.
Ça ne fait peut-être pas ce que tu veux, puisque je ne pense pas qu'il soit possible d'intégrer des icônes, mais, ça me semble proche, non?

Après perso, les touches de fonction je n'ai aucun problème à les trouver dans le noir, idem pour la plupart des touches en fait, mais bon, ça, c'est moi, et je conçois que ça ne soit pas le cas de tous, surtout sur des claviers plus compacts type laptop (j'ai un clavier tout ce qu'il y a de plus traditionnel, avec les écarts entre les bloc des touches de fonction et les marqueurs sur 'f' et 'j', ça aide)

Depuis mon switch, sur une rolling release

Laquelle du coup?

Mais sinon je suis d'accord, essayer Debian, c'est tuer un peu son âme de «distro hopper». À une époque (révolue depuis longtemps), installer debian et avoir un système utilisable sans connaître le shell, c'était compliqué. Mais c'était il y a longtemps (debian Potato je crois…).
L'installateur mériterait un coup de propre, clairement, notamment dans l'ordre des questions et des actions (avoir toutes les questions, puis toutes les actions, au lieu d'un mélange), mais franchement c'est largement utilisable, et on n'est pas censés ré-installer son systèmes tous les 3 mois non plus.

Et le vrai sysadmin, il prend la voiture pour aller rebooter les systèmes distants de plusieurs centaines de kilomètres dès qu'il y a une merde possiblement pas liée au logiciel, mais qui plante quand même les softs?

Dans l'absolu, je suis d'accord, les logiciels devraient être corrigés avant tout. Sauf que bon… ça, c'est la situation idéale, pas le monde que j'ai expérimenté. Mais bon, je ne suis pas sysadmin, juste un dev système qui a bossé sur du "mobilier urbain" (enfin, urbain… ça veut pas dire que ça peut pas être déployé au fin fond d'une forêt, loin de la).