Miguel Moquillon a écrit 449 commentaires

Oui je suis d'accord, mais confondre des approches qui t'aident, qui t'orientent à architecturer à peu près correctement du code (KISS par exemple) avec des dogmes me laissent perplexe. Une approche définie un cadre générale, et laisse à chacun de le décliner en fonction de son contexte. Un dogme c'est une route bien concrète à suivre quoiqu'il arrive.
Bon après, ce n'est pas parce que tu suis une certaine approche que tu ne vas pas non plus produire un code pourrave.

Wayland, c'est le merge du composite manager, du window manager et de X. Je ne comprend donc pas ton "heureusement"…

Heu non. Wayland est un protocole et une API C pour la communication entre des clients et un composite manager.
Actuellement, une implémentation simple d'un composite manager est proposée et pour des raisons de compatibilités avec l'existant, un client wayland a été écrit pour prendre en charge X, mais ce n'est qu'un client.

De plus la conception de X lui a permit de tenir 20 ans sans etre reecrit. […]

Oui, 20 ans d'emmerdes sous GNU/Linux et *BSD.
Alors ok, X était peut être pertinent avec les main frames, mais il a été à contre courant des principes même d'Unix à l'époque, ce qui fait, à mon avis, qu'il a vraiment eu du mal à évoluer et à s'adapter avec les changements au fur et à mesure du temps.

Oui finalement, ce qui aurait du être dans X et qui ne l'a pas été, c'était bien le compositeur. J'irais même plus loin : X aurait du être juste un framework doté d'un compositeur.

Non justement et wayland le démontre.
Le problème de X est que tout est dedans … excepté le Window Manager, heureusement. Et c'est pourquoi on a de grand mal à le faire évoluer avec les attentes et le matériel d'aujourd'hui.
Et pourtant, il existait des outils dans les années 80 qui étaient bien mieux pensés : je pense en particulier à Blit

Je suis un développeur expérimenté et quand je lis ton commentaire je hurle parce que je vois ici qu'une justification de continuer à faire de la bouse.
Il est bien plus facile de faire compliquer et bien plus compliquer de faire simple. Et il est encore plus compliquer de faire évoluer la simplicité initiale. Mais il est encore plus difficile de faire simple sur un existant complexe. Et tous les jours nous en faisons les frais de ces maximes.

T'as testé systemd avant de cracher dessus ?

Oui … Et là n'est pas la question. Ici, on parlait de principes architecturaux, pas d'utilisation.

Je prend un autre exemple dans un contexte bien différent : maven. Un système de gestion de build qui apporte une solution élégante aux problèmes de build et de gestion de dépendances dans les projets Java. Pourtant, son implémentation est pourrie. La différence ici, est qu'il ne s'inscrit pas dans un existant architectural.

Ça fait longtemps que les principes UNIX ne sont pas respectés sous GNU/Linux

Ho la bonne excuse à deux francs six sous !

l'informatique des annees 60 n'a plus rien a voir avec celle du 21eme siecle.

Non effectivement … Au 21 siècle, les principes architecturaux ont heureusement évoluées et devines quoi ? Ben ce sont justement celles que l'on retrouve dans Unix dès les années 70 et qui ont fait grandement son succès : modularité de l'espace utilisateur avec communication inter module, tout est fichier (de nos jours : objets, fonctions, ressources WEB, bref il y en a pour tous les goûts), etc. Marrant non ?

Ho bien sûr, ces principes n'ont pas toujours été respecté par les programmes utilisateurs (X, Netscape, StarOffice, …) et ont traînés avec eux maintes problèmes et désagréments aussi bien pour les utilisateurs que pour les développeurs mêmes.

Mais grâce à systemd, retour à 20 ans en arrière, à l'ère du monolithique et du bloatware. L'expérience de X n'a, apparemment, pas suffit comme leçon.

Toi, tu ne sais lire que ce qui t'arrange :

Ils peuvent être lancé par systemd, mais toutes les fonctions de controle, d'altération, de controle fin etc. ne fonctionneront pas. Donc oui, pas de DBus => appli de controle à part en dehors de systemd.

Alors lorsqu'il écrit "Et systemctl ne marche plus", ceci signifie tout simplement que ce pourquoi il a été fait ne marche pas (ou plus comme il se doit).

Non ce n'est pas exactement la même chose. Il ne faut pas confondre la conséquence, la finalité (lancer un processus) avec leur fonctionnalité principale : pour init c'est d'initialiser le système une fois le noyau démarré et parmi celle-ci on trouve le démarrage de services (daemons), pour cron c'est de planifier des tâches dans le temps. En terme de code, ce n'est pas exactement la même chose.

Il y a deux façon de faire pour ne pas dupliquer du code :
- soit tu rassembles le tout dans un seul programme qui fait tout … au risque de réécrire certaine partie avec l'évolution des usages. C'est en général ce que l'on appelle le bloatware,
- soit tu rassembles le code à réutiliser dans une librairie pour que d'autres programmes puissent en profiter. L'avantage de cette solution est qu'elle apporte de la flexibilité.

Et ceci est pareil en terme d'architecture logicielle :
- soit tu rassembles tous tes blocs fonctionnels dans un seul bloc monolithique au risque de réécrire ou tout recompiler au moindre changement,
- soit tu adoptes un socle modulaire (multi-services, multi-process, … les termes ne manquent pas pour désigner la même chose) reposant sur un bus de médiation.

Bah, ça fait depuis plusieurs versions de KDE 4 que je remplace kwin par xmonad et avec succès. (Ce dont je ne peux en dire autant avec GNOME 3.)

Tu as fait la comparaison ?

La comparaison que j'ai n'est pas équitable : d'un côté une Fedora 17 sur un PC portable ultra-moderne et de l'autre un ArchLinux sur un vieux portable : je n'ai pas vu la différence notable au démarrage. A la décharge toutefois de la distrib Fedora, il me semble qu'elle démarre plus de services (faudra que je vérifie).

De plus, avec un SSD qui se démocratise de plus en plus, le démarrage même avec un vieux système d'init UNIX à la system-v est devenu convenable.

Meme pas, c'est deporte sur les developpeurs upstream qui fournissent une unit pour leur projet.

En attendant, ce n'est pas le cas. C'est donc AMHA encore tôt pour intégrer systemd.
De plus, ça risque d'être comme avec les scripts init : ce seront les packageurs qui devront le faire ou les adapter ; l'avenir nous le dira.

Maintenant compare la complexite entre apprendre le shell script et le systeme de demarrage de ton systeme a la complexite d'un fichier unit

D'abord, je parlais de la complexité de l'implémentation (et donc du poids et de son obscurité) du bousin comparé au service rendu. Les questions auxquelles il tente de répondre sont pertinentes.

Ensuite, désolé, mais au vue du profil d'ArchLinux, ses utilisateurs, sans en être des experts, sont capables d'écrire des scripts shells. De plus, si un script shell est effectivement plus complexe que la syntaxe d'un fichier init à la windows, elle n'est pas si dramatique dans l'écriture d'un script de démarrage/d'arrêt de service et elle ne cache pas la complexité qu'il faudra tôt ou tard appréhender avec systemd pour pouvoir jouer avec les dépendances entre services et ressources systèmes.

Et conserver rc.conf c'est ne pas être KISS, du moins en intégrant systemd dans les dépôts

Dans ce cas pourquoi intégrer systemd et pas continuer comme ce qui se faisait avant ?
Et ne me dit pas pour que le démarrage soit plus rapide … Archlinux n'a pas besoin de systemd pour être véloce au démarrage.
Pour ne pas gérer les dépendances entre les services ?
Bof, ce que faisaient eux même les utilisateurs est déporté aux bénévoles de la distribution. A moins que ces derniers laissent les utilisateurs à se palucher la conf systemd pour chacun des services qu'ils veulent utiliser, auquel cas on passe d'un système simple d'utilisation à un système plus sioux (va te taper la doc sur systemd). Jusqu'alors, il suffisait d'indiquer dans le fichier rc.conf les daemons que l'on voulait démarrer et parmi ceux là ceux qui sont à lancer en arrière plan et franchement j'ai trouvé ça super sympa.

Franchement, j'ai du me palucher systemd sur une Fedora 17 pour tester la réalisation d'un paquet RPM et je reste assez dubitatif sur la chose : le compromis entre la complexité du bousin et le service qu'il est censé remplir vaut il vraiment le coup ?

vous connaissez beaucoup de gens qui utilisent thunderbird ou un lecteur de nouvelles

Beaucoup de gens ? Moins depuis que la plupart sont passés à GMail.
Par contre, oui préfère utiliser encore des outils natifs à leurs équivalent sur le WEB ; ainsi je préfère lire mes courriels en provenance de multiples boites email sur thunderbird et utiliser l'agenda de celui ci (lightening) que d'utiliser les WEB calendar.

http://www.blogeee.net/2011/11/le-samsung-nc110-blanc-a-199e/

Je suis assez étonné parce que je n'ai pas la même expérience que toi sur les perf générales avec KDE 4 sur un disque dur.

Ben oui, justement c’est bien ça le problème : ils ont du mal à utiliser leur OS, donc laissé moi modifier le menu pour le ranger de manière à ne pas les perturber !

Ok, si c'est toi qui le paramètre pour eux. Je pensais que c'était pour toi, or tes attentes ne sont pas les leur, d'où ma réponse.

Comme toujours sous GNOME : « l’utilisateur est un con, moi, développeur, je réfléchis à sa place ».

Je ne sais pas si les dév pensent que l'utilisateur est un con, par contre, ce que je sais, c'est que des utilisateurs lambda modifient leur environnement des fois sans le vouloir. Et le résultat est que je dois remettre les choses en place parce qu'ils sont perdus (ils ne retrouvent plus leur petit). Donc, finalement, je me dis que désactiver des fonctionnalités de paramétrage n'est pas plus mal pour ce genre d'utilisateur ; alors bien sûr il y a un monde entre désactiver et enlever.

Il est installé sur le PC de ma copine avec un disque dur de merde à 5400 tr/min

Excuses moi mais là j'ai du mal à te croire ou alors le PC de ta copine est un i7 avec 8Go de RAM et vous êtes du genre tolérant avec votre DE préféré.

sur une Arch

Ok, déjà ce ne peut être effectivement que plus performant que sur une Ubuntu. J'ai un vieux portable (un Toshiba Satellite Pro A40) qui tourne avec une Arch et c'est le jour et la nuit comparé à Ubuntu/kubuntu. Rien que le démarrage surpasse n'importe quel PC moderne sous une Ubuntu/Kubuntu (sans disques SSD). (J'utilise E17 sur ce portable et ma femme XFCE.)

Je suppose que tu n’utilise pas la configuration par fenêtre/application (genre afficher Konqueror sans bordure, en maximisé, sur le bureau 2, tout le temps).

Non, j'utilise un vrai tiling wm qui fait ça pour moi.

… C’est tout l’inverse.

Pas sous Ubuntu et surtout pas pour des utilisateurs lambda qui ont déjà du mal à utiliser un navigateur/gestionnaire de fichiers. La modification de menu est la cadet de leurs soucis.

• Certaine lenteur au démarrage (après c'est beaucoup mieux, il tourne chez moi sur C60 sans problème)

Heu, de toute façon KDE c'est lent et (trop) gourmand en ressources à mon goût.
Avec un disque SSD, KDE 4 passe bien, mais je doute de son usage sur un disque dur.

• Le tiling buggé jusqu'à l'os

Oui et ça m'a gonflé. Aussi, j'ai remplacé kwin par xmonad et depuis j'en suis hyper content.

Sinon, à côté de ça, je trouve que GNOME 3 pour un utilisateur lambda comme mes parents c'est de la balle ; surtout dans une Ubuntu.
Par contre, pour le boulot ou un usage plus pro, je préfère KDE (qui couplé avec XMonad ça rulez!).

Oui, c'est super … si ce n'est que l'on ne trouve pas de 13" ou encore du 14" et que les résolutions des dalles sont de 1366 x 768 pixels ! Franchement, c'est se foutre du monde de proposer des résolutions aussi pourraves ! Pour utiliser quotidiennement des PC portables, je peux dire que la résolution de l'écran est à mon avis la caractéristique première à considérer.

Bon, Clevo propose tout de même des 15" avec une résolution de 1920×1080 pixels mais ce n'est pas du 13 ou du 14".

Si c'est un framework, en effet, il est destiné à être intégré dans d'autres projets Java nécessitant ses fonctionnalités. Et sur ce point, le choix du Makefile ou du Ant me laisse encore plus perplexe.
En effet, ils ont a un goût prononcé de retour dans le passé.
Il existe maintenant des outils qui permettent de gérer le cycle de vie d'un projet Java, ainsi que ces dépendances, et de le mettre à disposition dans des dépôts sur Internet. Je pense en l'occurrence à Maven pour lequel les dépôts de projets Java sont utilisés même par ses concurrents.
Et Maven est supporté par l'ensemble des IDE pour Java (Netbeans, IntelliJ IDEA, Eclipse) et exécutable aussi en ligne de commande aussi bien sur les Unix que sur le Windows.

Non, une approche ou paradigme est avant tout une façon de penser les choses, les problèmes et les solutions ; les constructions en dérivent donc comme support du paradigme. Et, à l'usage, l'utilisation des constructions du langage vont conditionner aussi la façon de penser. C'est la raison pour laquelle des développeurs qui ont une forte expérience avec les langages dît impératifs vont avoir plus de mal avec les langages fonctionnels.

Ramener l'approche à une simple définition et utilisation de constructions est une erreur qui a malheureusement fait bcp de mal à la POO. Ainsi, par exemple, j'ai vu un grand nombre de développeurs acquérir une connaissance erronée de la POO au travers de langages comme C++.

Pour le déclaratif, un exemple vaut tous les discours (enfin c'est ce que l'on dit) :

applesInCart cart = [ a | a <- filter (== Apples) cart ]

Autrement dit : la fonction applesInCart est déclaré comme étant l'ensemble des pommes dans le caddie.

En C :

Fruit* applesInCart(int size, Fruit* cart)
{
   Fruit* apples = malloc(...);
   int i, j = 0,;
   for(i = 0; i < size; i++)
      if (isApples(cart[i]))
        apples[j++] = cart[i];
   return apples;
}

là tu dis ce qu'il faut faire : parcourir les éléments du caddie un par un, tester que l’élément est bien une pomme et si oui l'ajouter dans le tableau à retourner.

Je distingue constructions impératives ou fonctionnelles de l'approche (impérative ou fonctionnelle). Dans le premier cas, il s'agit d'apport du langage, et dans le second de la manière de penser et d'écrire des programmes. Et donc, c'est sous cette lumière que je reste sceptique quant à proposer un mixte des deux approches parce que par trop différentes (ce qui ne signifie pas que ce n'est pas possible).

Aussi, lorsque tu écris que l'on peut mélanger la programmation fonctionnelle et impérative avec des langages fonctionnels, je comprend utiliser des constructions impératives pour exprimer certaines choses (qui ne serait peut être pas possible ou compliquer de faire autrement). Et là dessus oui je suis d'accord. Ainsi, dans Haskell (je ne connais pas Caml pour m'exprimer à son sujet), les constructions dîtes impératives sont utilisées avant tout pour exprimer des effets de bord (via les monades).

Quant à mon expression de "déclaratif", il signifie ni plus ni moins que la manière dont sont écrites les fonctions : en déclarant ce qu'elles font par le biais d'autres fonctions (à opposer à stipuler comment elles doivent le faire).

Tu parles de python là ? Tu vas en froisser quelques uns, fais attention. :) De plus je code en python et ce serait intéressant que tu développes davantage ce point. Merci par avance.

Non, en fait je pensais plus à Scala ; Scala est un langage orienté objet et fonctionnel avec une structure impérative.
Python est différent : c'est un langage impératif doté de constructions fonctionnelles, ce qui n'est pas la même chose.

Je reste mitigé quant au mixe des deux approches, impératives et fonctionnelles, parce qu'elles sont disjointes ; ce sont deux modes de pensée différentes au delà des simples constructions. En fonctionnel, il est plus naturel de penser top-down et de ce que l'on veut faire (pas comment faire) et le résultat est la composition de fonctions qui décrit les relations déclaratives (et sémantiques) entre les fonctions d'un programme.

J'aimerais bien avoir du sous-typage (héritage sans polymorphisme) histoire d'éviter de caster quand on adopte une conception objet.

Déjà, parce que tu as une relation de sous-typage, tu auras de toute façon du polymorphisme via le principe de Liskov.
Le problème de coercicion vient justement que les langages couramment utilisés ne supportent que le typage du second ordre alors que la programmation orientée objet nécessite un typage du second ordre et plus particulièrement le typage F-Bounded (qui résoult le problème des types récursifs).

En revanche, je ne mettrais aucun des trucs à la mode du genre closure, programmation fonctionnelle,

ça par contre c'est bien dommage parce que les closures apportent une force indéniable dans l'écriture et la maintenance de code. (Elles ont montrés leur efficacité dans l'écriture de code orienté-objet avec Smalltalk 80.)
A côté de ceci, la programmation fonctionnelle est une force parce que justement elle permet d'écrire plus simplement du code qui serait bien plus complexe en programmation impérative. Par contre, oui, je suis plus mitigé du mixe forme fonctionnelle et forme impérative que l'on trouve dans certains langages.

Surtout, je ne mettrai pas la concurrence dans le langage, parce qu'on n'a pas encore assez d'expérience

C'est à la fois vrai et faux :
- vrai parce que globalement dans l'industrie du développement logiciel, les codeurs sont pauvres en expériences et en compétences dans ce domaine,
- faux parce que ce domaine existe depuis bien bien longtemps et que de nombreuses techniques et forme de programmation existent et ont fait leur preuve mais dans des métiers particuliers les nécessitant (communication, transaction financière, ...)

J'avais un portable PC qui tournait avec un Core Duo (pas un core 2 Duo mais bien un Core Duo) et qui m'a lâché l'année dernière. Il m'avais fait 4 ans, mais j'étais encore sous le choc de sa mort car jusqu'à présent il tournait bien sous nunux.

En attendant d'en acheter un autre, j'ai ressorti un vieux PC Pentium 4, j'y est placé le disque dur de celui qui m'a lâchement abandonné (un 7200rpm), j'y ai installé ArchLinux et ai monté sa mémoire jusqu'à 2Go (contre les 512Mo d'origine). Ma moitié utilise GNOME (en fallback). Quant à moi, ayant du mal avec les bloatware, et l'utilisation de xmonad n'étant pas idéal avec un écran 15" en 1024x768, je me suis mis à utiliser E17 (en version de dév).
Pour l'instant, j'en suis content. Ça tourne bien et même mieux que certains PC modernes sous Ubuntu.

Bref, ça dépend du vieux et de ce que tu mets dessus finalement.

Il existe des systèmes de fichiers adaptés aux SSD, dont on peut citer NilFS ou LogFS.