freem a écrit 5019 commentaires

C'est peut-être hors sujet compte tenu du titre, mais vu que le problème semble être "développer des applis graphiques en DotNet sous Winbrol" je me suis dit que, peut-être, il ferait le job: https://www.monodevelop.com

Je connais pas, après, hein.

Ah, ils veulent quitter l'europe? /me ->[]

[supprimé par l'auteur]

Tout est dans le titre. Il me semble bien que ces 2 solutions sont concurrentes. J'ai souvenir d'avoir utilisé libinput, pour lire des évènements, par contre, pas pour les injecter. C'était aussi assez simple, surprenant pour des outils si bas niveau.
Si j'en crois la liste des paquets qui fournissent xorg-driver-input sur ma debian, c'est vraiment très probable qu'ils fassent la même chose.
Je n'émets aucun jugement de valeur, je n'avais pas trop creusé le sujet à l'époque, il fallait que j'implémente la chose rapidement…

Personnellement, je peux parler au moins de ce que linux m'a apporté, même si je ne pratique réellement que depuis moins de 15 ans.

Il m'a fallu beaucoup, beaucoup de temps pour comprendre windows (oui, j'entend comprendre, pas juste ouvrir un fichier… mais connaître la liste des processus, savoir à quoi ils servent, connaître les services, savoir naviguer dans la base de registre, et donc nettoyer les trucs inutiles, etc etc).
Ce n'est même pas une connaissance du code interne, et pourtant c'est, honnêtement, déjà pas mal (bon, j'ai tout perdu, hein…).

Il m'a fallu moins de 3 ans pour atteindre le même niveau sur debian, et a temps égal en tant que système principal, mon niveau a augmenté beaucoup, beaucoup plus vite.
L'accès aux source à pu aider, possible, mais je pense que dans l'ensemble, c'est le fait que, au moins debian, n'essaie pas de décourager l'utilisateur à comprendre comment ça marche.

L'aspect négatif, c'est que du coup, je ne sais probablement plus utiliser les divers outils de cracking que j'utilisais étant ado :D

Je suis surpris de ne pas avoir lu en réponse à mon post que le kernel linux à longtemps nécessité les extensions GNU pour le coup :p

Personnellement, je préfère toujours qualifier mon système par son vrai nom plutôt que "c'est un Linux" ou "c'est un GNU/Linux". Non. C'est Debian, dans mon cas. Qui est différente d'Ubuntu.
Après, je suis d'accord qu'on peut utiliser le terme GNU/Linux pour décrire la famille, en supposant que ça ajoute vraiment une précision utile… mais personnellement je m'en garderais bien.

Questions:

1. void-linux est-elle une GNU/Linux, compte tenu du fait qu'elle fournit un build basé sur musl?
2. Si les expérimentations de Debian sur l'usage d'autres noyaux (kFreeBSD et kHurd, principalement) avaient fonctionné, devrais-t-on malgré tout la considérer comme une distribution GNU/Linux?
3. si mon système (debian) n'intègre bash que par tradition et pour quelques scripts «mineurs» (certains pre/post inst/rm, en fait, et encore) doit-on vraiment la considérer comme une distribution GNU?
4. en fait, moi, j'utilise principalement des logiciels non-GNU, y compris mon compilo préféré, pour des raisons de confort et de performance. Dois-je malgré tout considérer mon système comme GNU?
5. et d'ailleurs, le kernel, je m'en fout un peu. Mon OS, c'est plutôt Debian, non? Que ça tourne sous le capot grâce à GNU ou grâce à linux, on s'en fout pas un peu? Ou alors, il serait probablement pertinent d'appeler ça: «GNU/Systemd/Linux/Gnome» non (sauf que moi, je n'utilise pas gnome ni systemd ni gnu, mais le but n'est-il pas de faire plaisir aux intégristes en manque de reconnaissance, incapables d'admettre qu'ils n'ont jamais réussi à fournir un noyau fonctionnel et donc de faire un OS complet qui marche réellement sur le matériel)?

Ouuups je suis en avance de 2 jours…

les 30 piges de penguin

C'est un manchot.

Au début on n'avait que le Z :)

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!