freem a écrit 4948 commentaires

Quand je vois ce qui se dis au sujet de systemd sur la ml debian, je doute que les développeurs n'imposent un tel changement.
De toute façon, ça ne risque pas, puisque, pour rappel, debian supporte aussi un kernel bsd, et comme tout un chacun ne cesse de le rappeler, systemd n'est pas portable.

Je pense juste qu'il y aura le choix à l'installation, quand on prend les questions en mode expert, chose qui n'est pas encore le cas à l'heure actuelle, sysvinit étant un paquet vital, contrairement à systemd.
Au hasard, il vont faire un paquet vital qui dépende sois de l'un, soit de l'autre, histoire que l'on ne sois pas obligé de taper "Oui, je suis parfaitement conscient que je risque de casser le système" quand on installe systemd et supprime sysvinit, à la virgule près? (Enfin, je dis à la virgule près, parce que le moindre caractère force à retaper, mais je n'ai pas cité le message exact :) )

Perso, je suis plutôt favorable à l'utilisation de systemd, surtout intégré par les dev de Debian qui ont tendance à faire des config par défaut très propres et très clairement documentées. Même celle de vim est lisible, à défaut d'être exhaustive dans ses commentaires.
Je me souviens avoir testé, en supprimant sysvinit, rien n'a cassé. Je suis revenu à sysvinit pour la simple raison que ça n'avais rien apporté à mes yeux à ce moment (il faut dire que les scripts d'init étaient toujours utilisés donc…), et que depuis j'ai cassé mon système, alors je n'ai pas refait la bascule.

Il y a des gens qui utilisent nano au quotidien?
Mais comment fais-tu?

Bon, après, j'avoue, je ne connais pas vi, mais vim, et il faut l'admettre: il faut apprendre à s'en servir.
D'un autre côté, je n'ai jamais vu de document prétendant qu'il n'y a pas d'apprentissage pour vim, juste affirmant qu'il est plus puissant que la plupart des autres éditeurs de texte.

Pour cron user-friendly… j'ai bien rigolé, merci.

Le coup des contextes différents, c'est bien ce que je voulais utiliser, même si j'ai peut-être mal formulé.

Les tableaux associatifs sont utiles, et sont la marque des bons langages dans un certain contexte. Pas dans tous.
Le C est un bon langage dans l'embarqué, je crois? Alors que perl ne le sera pas forcément. Pourtant, C n'a pas les tableaux associatifs, alors que perl, si.

Dire d'un langage qu'il est bon ou pas parce qu'il n'a pas telle ou telle fonctionnalité (qui, en l'occurrence, est une fonctionnalité implémentable, en plus) me semble franchement à côté de la plaque.

En espérant que mon message soie plus clair.

Le langage influe certainement sur la performance, mais au vu de certains codes source C que j'ai pu voir dans le libre, et la réplique que je me suis mangé quand j'ai osé suggérer d'améliorer la qualité du code et en soumettant un patch (en gros: pas de refactoring si ça n'apporte pas de fonctionnalité. Ca peut se défendre, en soi…) je ne peux qu'admettre que le développeur compte sûrement pour plus de la moitié des problèmes de performances.

Genre, si un code C fait 3 fois la même opération d'affilée à cause d'un code dégueu et illisible, même si cette opération est 2 fois plus rapide qu'en Java (exemples, exemples, rien d'autre!) si le code java ne fais qu'une fois l'opération, le code java sera plus rapide.
Ca marche aussi avec 2 et 1 ;)

Pour le desktop, ce qui pose le plus problème, à mon avis, c'est plutôt les inter-dépendances qui permettent aux logiciels de faire le café. Et le constat que je fais de ce point de vue la, c'est que le moindre programme python installé sur ma machine à bien plus de dépendances que les autres. Pour perl, c'est moins pire. Il faut dire qu'en général, ça reste des choses qui ne font qu'une seule chose, en perl.
Pour JS, j'en sais rien.

Alors bcm4313.
Perso, il faut que j'utilise le pilote propriétaire sur ma debian, sur mon 1015pem. Après, c'est sur, j'active "non-free" et "#aptitude install bcm4313" permet de régler le problème.
C'est aussi une expérience purement personnelle.
Peut-être que c'est l'âge du kernel qu'il faut mettre en cause, mais j'ai un doute. Peut-être aussi que ce sont les DFSG le problème, mais j'admets que, de façon totalement personnelle et égoïste, ces définitions collent bien à mes idées personnelles (oui j'insiste lourdement sur le mot personnel, je sais, et, au cas où: c'est totalement personnel ;) ).

Le fait est que sous windows, on trouve tous les pilotes, aucun n'étant libre, mais tous fonctionnent et s'intègrent bien avec l'OS et ses possibilités.
A côté de ça, si tout fonctionne sous linux avec des drivers propriétaires, ceux-ci ne sont pas au même niveau en terme de quantités de fonctionnalités.
J'ai cité l'économie d'énergie du pilote nouveau, qui n'est pas l'officiel (et j'aurai aussi pu citer le fait d'utiliser 2 cartes graphiques au lieu d'une seule), mais pour le privateur, l'officiel, je peux citer xrandr qui n'est pas supporté.

Côté wifi, je sais exactement comment freezer mon système. Il me suffit de changer l'état du wifi (on/off) entre une hibernation et le reboot.
Mis à part ça, ça marche, donc ok. Mais ce n'est pas un pilote libre, encore une fois.

Après, de dire que windows embarque tous les pilotes, ça m'a aussi toujours fait beaucoup rigoler. Le fait est que si "touslesdrivers.com" existe, c'est parce qu'ils en sont très loin. Et même sur ce site, on arrive très facilement à ne pas trouver, ou à trouver un truc qui ne marche pas, lorsque le matos est trop "vieux".

Mais voilà, au détour d'un reddit relayé à point nommé, John Carmack faisait une mise au point honnête sur l'intérêt de plutôt miser sur l'émulation que d'espèrer un portage de jeu natif et il saluait donc l'initiative de CodeWeavers, WineHQ.

Combien de fois faudra-t-il le répéter?
Wine n'est PAS un émulateur!!!

Il s'agit de l'implémentation d'une API, pas de la simulation du fonctionnement d'une machine.

Après, pour la diffusion physique, c'est logique, il n'y a pas grand monde qui aie une machine sous linux, alors ça serait pas mal de quantité de matériel gaspillée. Pour le retard comparé à windows, en revanche… c'est moins logique, sauf si on se dis que les logiciels (jeux ou pas) ne sont pas développés de façon portable, mais bien portés à priori.
D'ailleurs, m'est avis que ça doit coûter la peau des fesses comparé à un dev portable dès le début?

Hum… pas de merde en script, ça implique que tu n'as ni perl, ni python d'installé? Ca m'intéresse assez dans ce cas.

Bon, naturellement, je pense que tu exagères, vu que je suis persuadé (mais pas convaincu, notes bien) que tu as init, et question script… bref, sans shell (que ce soit bash, zsh ou csh ou… peu importe), je ne sais pas si un système peut tourner à l'heure actuelle.

Entièrement d'accord.
Tout le monde sait que le langage C et le langage ASM ne sont pas de vrais langages, l'un n'ayant pas de tableau associatif dans sa lib standard, l'autre n'ayant même pas de lib standard!
Quelle honte!

Bon, d'un autre côté, mieux vaut lire ça que d'être aveugle… C'est pas comme si je suis fan de l'asm ou du C (je ne dirais pas tout le mal bien que je pense de JS non plus), mais les tableaux associatifs ne sont pas aussi vitaux que tu ne sembles le croire, de très, très nombreuses applications s'en passent avec bonheur.
D'ailleurs, tant qu'a troller, un tableau normal, n'est-ce pas un tableau associatif, puisque l'on associe un index avec une donnée?

Si, il y en a une:

Une branche stable qui ne fait que des fix de sécurité, 0 modifs de "l'API de configuration" (une conf, c'est un peu comme une API si on y pense, non?), et une branche "dev" qui comprend les ajouts/suppressions/modif de features, avec des changelog qui expliquent que telle ou telle option à vu son comportement modifié.

Pour le coup, séparer les données du code à un intérêt: on peu faire autant de MaJ de sécu qu'on veux, ça ne touche pas à la config.
Pour être honnête, cette manie de mêler le code et des constantes, c'est quelque chose qui m'a valu de nombreuses heure de débogage, et maintenant, quand j'ai une donnée initialisée par une constante qui n'a rien a voir avec le fonctionnement interne de mon appli (genre, par 0 ou 1 en fonction des index de tableau, ou un code/message d'erreur que je mets dans le texte décrivant l'erreur), ça dégage dans un fichier de conf (que la configuration aie lieu à la compilation où à l'exécution ne change pas que ça reste de la configuration) , séparé de la logique du code.

L'autre point sympa, outre la maintenance, c'est que ça génère de facto un logiciel plus souple, avec moins de limites codées en dur et pénibles à faire évoluer (je trouve que "%s/…/…/g" c'est long à taper, et encore pire quand ça contiens des /, . ou autres joyeusetés)

Je souhaiterais au passage rappeler qu'un dossier et une base de données, c'est assez proche, modulo la méthode pour trouver la donnée (par clé/hash/node…).

Le registre windows, c'est: une structure en arbre, contenant des couples clé/valeur.
Un système de fichier, c'est: une structure en arbre (les dossiers étant les noeuds) contenant des couples clé/valeur (les fichiers sont la valeur, leur nom est la clé).

Dans les deux cas, on peut stoker une valeur texte, ou binaire. Niveau base de registre windows, ce que je n'aime pas, c'est:
1) Pas éditable par éditeur de texte simple (et, non, vim n'est pas simple, même s'il à des points qui font que je l'utilise de plus en plus.)
2) Je ne comprend pas l'intérêt d'ajouter une complexité pour une configuration qui n'est censée n'être lue qu'une fois: au début du lancement d'un logiciel.
3) Le foutoir (selon moi, et c'est de toute façon entièrement lié à ce registre précis)

Ce que j'aime avec mon /etc, c'est:
1) Les commandes du bash sont disponibles, sans adaptation. Ca implique que les scripts ne nécessitent pas d'apprendre un nouveau langage. D'ailleurs, la plupart des langages savent se démerder avec des fichiers et dossiers.
2) Je peux utiliser n'importe quel logiciel de versionning. Git, svn, cp.old…

C'est un peu comme le xml (tant qu'a troller, trollons bien) que tout le monde pense être la panacée: dans énormément de cas, il n'a aucune intérêt si ce n'est d'être à la mode.

Ca, c'est ridicule… Un salarié ne fournit pas un travail gratuit, sinon c'est un bénévole.

Après, dire que les salariés sont exploités, c'est un autre sujet… et un autre mot.

Euh… Non. Je gagne mon fric en développement de nouvelles fonctionnalités.

Hum, aussi effectivement, j'avais oublié ce point.

et les informaticiens n'ont pas nécessairement besoin de support, surtout aux débuts du logiciel ou si sa documentation, signe de qualité, est propre et complète

Oui, c'est l'avantage même : tu te fait pas chier à faire des trucs simples.
Par contre, ben si : tout le monde n'a pas envie de faire les trucs compliqués en apprenant trop, et préfèrent déléguer, et qui de mieux que le dév pour?

Le fait est que, si on se fait pas chier pour un truc simple, il y a moins besoin d'assistance, et donc moins de rentrée d'argent potentielle. Je parle d'un point de vue purement économique la, hein.

Mais je pense que le risque d'avoir bossé pour rien et de se ramasser la gueule,

Comme partout.

tu as oublié la fin: "est plus élevé". Il est évident qu'on peut se ramasser partout… je pense juste que le début, avec le libre, me semble bien plus délicat qu'avec un modèle fermé.

voire de se faire piquer son idée par une entreprise peu scrupuleuse,

Ben c'est que quelqu'un est meilleur que toi, à toi de changer!

Un logiciel qui viens de naître, fait par un type seul, n'a aucune chance de pouvoir concurrencer au niveau des compétences une entreprise sur le même marché depuis belle lurette, ne serait-ce qu'en terme de force de travail.
Tu peux être aussi excellent que tu veux, si en face tu as une équipe d'une 10aine de dev ayant entre 5 et 10 d'expérience dans le même domaine, je doute que ce soit possible.
Yakafokon s'améliore, c'est pas toujours si simple que ça, quoi.

Parce qu'on ne me fera pas croire que toutes les entreprises jouent le jeu quand elles emploient un logiciel libre…

Quel jeu? C'est libre, elles font ce qu'elles veulent, il n'y a aucune règle "tu dois contribuer upstream", ce serait même contre le libre.

Ce que tu vends en tant que dev principal, c'est ta compétence. Et si toi le dev principal tu es moins compétent que d'autres, ça craint! Aucune autre personne ne peut être meilleure et "ne pas jouer le jeu"…

Pas tant que ça… cf ma réponse précédente.

L’intérêt du libre est justement la liberté.

Certes.

Tant pis pour les deb, ça m'aurait bien intéressé. Enfin, je sais en faire, mais ma méthode est un peu trop artisanale à mon goût, et la méthode recommandée de debian, j'ai pas tout compris :D

Pour ce qui est de la réécriture, je comprend vraiment ce que tu veux dire. Je pense que réécrire complètement un logiciel dans le même langage est une erreur, dans l'absolu: ça casse la motivation de repartir sur un truc qui ne marche pas, on perds l'historique des bugs, et on se prend la tête à utiliser des choses pas forcément utiles.
Changer de langage… c'est pas pareil, il n'y a pas forcément le choix de tout refaire d'un bloc (genre delphi à C++) sauf peut-être si l'on connaît l'ancien code.

C'est con à dire, mais… le matos, ça coûte. J'ai toujours eu envie de me faire ce genre d'amis, plus fidèle qu'un chien, moins cher, et plus propre.
Seulement, le prix supposé m'a toujours fait peur!

Pourrais t-on avoir une estimation?

J'ai pourtant ouï dire sur ce même site, de mémoire par un contributeur de nouveau, que ce pilote particulier ne gère pas, ou mal, la gestion de l'énergie.

Je remarque aussi qu'il n'est, à l'heure actuelle, pas possible d'utiliser 2 CG NVidia sur la même machine, toujours avec ce pilote.

Ce ne sont pas des reproches, et, oui, je pourrais contribuer, si j'avais les compétences techniques…
Mais franchement, s'pas avec un bac électronique, 2 ans d'expérience personnelle avec debian, et quelques années de dev C++ que je me penserai assez bon. (Il me suffit de voir à quel point je galère à essayer de compiler un kernel pour gentoo pour avoir la preuve que je ne comprend pas grand chose).

Ensuite, il y a les pilotes de chipset wifi.
Oses me dire que tu en trouves des libres pour chaque carte, qui fonctionne correctement? Le proprio de mon 1015pem marche pas trop mal… mais avec une manip particulière (hibernation, rallumage, et avant que tout ne sois chargé, changement de l'état du wifi: on/off ou off/on), je peux faire freezer la dite machine!

Tout marche sans problème, hein? La blague!

Cela dis, linux gère mieux les vieux matériels que windows, a ce que j'ai pu voir. Niveau pilote, c'est la seule bonne chose.

Bon sang de timing trop court pour l'édition (au moins la bd me fait marrer, c'est déjà ça) !

Quant à l'argument majeur, la possibilité pour les autres de contribuer… hum. Je serais curieux de connaître le ratio contributeurs/utilisateurs pour le libre de façon générale (c'est à dire, le nombre d'utilisateurs de logiciels libres qui ont contribué à l'un d'eux, quel qu'il soit).
Sachant que ce ratio sera fatalement nettement plus élevé que le même ratio appliqué à un logiciel seul si celui-ci est peu encore réputé, je ne crois pas que cet argument soie réellement valable.
Pas au début, en tout cas. Encore une fois.

PS: je n'ai rien trouvé sur wikipedia concernant l'historique d'openERP. Pas envie de chercher 50 ans, non plus, alors si quelqu'un à des infos, je serais assez intéressé.

Mais, et tant pis pour les votes "inutile", je crains que le lancement d'une application libre, par une entreprise qui se compose à son départ d'un seul développeur, ne demande un travail largement plus conséquent qu'un logiciel privateur.
En effet, le dev ne peut alors gagner de l'argent que par la formation, l'assistance. Un dev n'étant pas nécessairement un bon formateur/assistant, il peut y perdre un temps fou.

Si ce temps fou est chiffré trop cher, il n'aura pas de clients.
Sinon, il n'aura pas l'argent pour continuer à améliorer son logiciel, celui-ci stagnera et n'arrivera donc pas à se faire un nom, qui aurait pu lui permettre de financer les embauches qui lui auraient permis d'améliorer le logiciel.
Il y a les dons, c'est vrai… mais franchement, je n'y crois pas trop.

Mis à part ce problème, déjà de taille, je pense qu'il y à un autre point qui fait que ça doit être extrêmement ardu: faire un logiciel pour des informaticiens, ou un jeu.
Ces marchés ont deux problèmes: la majorité des joueurs vont tout faire pour éviter de raquer, et les informaticiens n'ont pas nécessairement besoin de support, surtout aux débuts du logiciel ou si sa documentation, signe de qualité, est propre et complète.

Conclusion:
Oui, c'est vrai, le libre peut être rentable. Mais je pense que le risque d'avoir bossé pour rien et de se ramasser la gueule, voire de se faire piquer son idée par une entreprise peu scrupuleuse, est plus élevé dans le libre que le privateur.
Parce qu'on ne me fera pas croire que toutes les entreprises jouent le jeu quand elles emploient un logiciel libre…

Inutiles, parce que le pékin se dit "il me soule mon antivirus, il veut pas que j'installe l'appli que mon pote m'a garantie géniale! Allez, zou, une exception!".

Antivirus… mouai. Les virus que ça bloque, ce sont ceux que l'on ne chope que si on fait pas gaffe.
En soi, un antivirus est un sacré malware: ça te vide ton compte en banque ou te pourris tes perfs, ça sert à presque rien, et parfois il faut que tu répares les conneries qu'il a faites lors de sa mise à jour automatique (mention spéciale pour kaspersky: 5 problèmes en 1 an sur une 12aine de machines! Ca fait beaucoup quand on sait que c'est payant et que ça détruit les perfs…)

Bref, avant l'OS sécurisé (ce qui inclue un potentiel antivirus et un firewall) il faut se souvenir que le plus gros problème en informatique, c'est l'utilisateur. Y compris quand celui-ci fait de ces nobles sciences son métier, d'ailleurs.

Sauf que… un netbook, où ultra-portables, c'est un laptop, pas un desktop.

L'ultra-portable à un clavier, aussi, et est conçu pour que celui-ci soit utilisé. Les tablettes avec leurs docks se joignent à la danse, ok, mais à quel prix? Et même avec un clavier, ça reste orienté écran tactile, les applications.
Alors résumer la différence à l'architecture du processeur, ça me semble vachement diminutif.
D'ailleurs, est-il possible de modifier aisément le matériel d'une tablette? Sur mon eeepc, ce n'est pas si complexe que ça, pour changer le disque dur ou la ram, par exemple.

Mais ce qui est certain, c'est qu'entre un ultra-portable et une tour, il y a un univers!

Pour moi, le desktop c'est la machine qu'on ne peut pas déplacer, mais dont on peut modifier le matériel sans le moindre problème et avec juste quelques neurones (et des sous).
Le desktop est la machine à moyenne/haute performance, qui peut éventuellement remplacer un serveur dans une TPE, un petite PME non-orientée service, une association ou chez un particulier.
C'est la machine qui permet de faire vivre les gamer, et qui permet aux dev d'avoir le confort de plusieurs écrans sans en mettre un complètement excentré (contrairement aux transportables/portables/ultraportables/whatever).

Et donc, dans le desktop, non, android ne squatte pas, même pas un petit peu. Bon, ok, allez, peut-être chez certains gens qui ont envie de jouer avec des trucs à la con…
C'est windows le chef, et ça va durer encore quelques années, je pense. Pas comme si j'en étais heureux, hein, juste du réalisme.

… avec le screenshot et le passage sur la physique.

En fait, j'ai cru qu'il y avais des obstacles sur le terrain (labyrinthe en l'occurrence), et j'ai pensé "p'tain, ça dois être énorme". Puis j'ai fini de lire et je me suis dis "ah, zut… en même temps, niveau code, ça serait pas nécessairement évident à gérer…".

Enfin, il faudra que je le teste, je connais déjà blobby, mais l'IA est devenue trop dure pour moi et perdre tout le temps fini par lasser :D (je sais qu'il y en a plusieurs, mais impossible de comprendre leurs noms, et donc la difficulté qu'elles représentent)

Courage pour la suite du dev.

PS: par pure curiosité, comment construis-tu les paquet deb?

Hum… sauf que l'utilisateur d'une librairie, c'est un développeur, et celui-ci n'est pas aussi libre de choisir sa licence, du coup.

Bon, c'est jouer sur le troll les mots, je suis d'accord. Mais dans l'absolu, la licence gnu que je préfère je pense que c'est LGPL. Mais je ne développe pas trop pour le réseau, alors peut-être qu'affero me plairait plus. Aucune idée, je l'ai pas lue.

Pour en revenir au jeu lui-même…
A voir les screenshot, on sort de l'austérité des années 80, pour arriver dans les années 90. Ca tombe bien, c'est en général les jeux de cette décennie que j'apprécie: graphismes et interface qui permettent d'utiliser un jeu sans garder le manuel à côté de soi pendant les 12 premières heures de jeu et qui permettent de ne pas avoir trop mal aux yeux.
Parce qu'autant le concept du roguelike est intéressant, autant on peut en faire avec des graphismes. Au final, roguelike, hack'n slash… même chose, avec l'intuitivité pour le second.
J'ai rien contre les barbus hein… moi même laissant ma propre barbe pousser plus que nécessaire trop souvent, mais il faut accepter de sortir du mode réel pour passer au mode protégé, parfois.

Bon, je pratique pas (moi c'est réveil à 3m + PC à 2m dans l'autre direction, sinon ça marche pas), mais j'imagine qu'il dois bien y avoir des gens pour brancher 2 hauts-parleurs sur un arduino, non?

Sauf que toute bonne torture se fait en douceur, justement… pour prolonger le plaisir de l'un, et la douleur de l'autre.

J'ignorais l'existence d'OOM killer.
Ce ne serait pas plutôt que l'appli se mange une exception OOM, ne la traite pas, et donc en meurt? Ah, non, désolé, j'oublie parfois que les exceptions ne semblent exister n'existent qu'en POO…

Pour les plug-in, je ne suis pas sûr de comprendre ce que tu veux dire par mode managé? Tu pourrais détailler (ou balancer un p'tit lien), parce que je suis assez intrigué, je n'ai vu aucune référence à cette méthode quand j'ai fait quelques recherches C++ sur le sujet.
Peut-être que ça fait référence à des langages à VM, style Java ou .NET?

Côté lancement de processus séparé: oui, perte de perf, mais sinon, comment ça marche? Double fork puis chargement du plug-in?
Ca me semble pas portable du tout en plus de la lourdeur…

Je viens de me souvenir, et je vérifierais encore à l'occasion (même que je te prendrais un p'tit screenshot) que sous vista aussi, les fichiers sont indéplaçables (et donc pas défragmentables) quand ils sont en cours d'utilisation.

Et que la défrag auto ressemble à un mythe, voir post précédent.

Evidemment si tu bases tout ce que tu dis sur 2001, il y a 11 ans, on va pas aller loin… le monde a avance depuis.

Ou 2008, selon la façon de voir les choses: http://fr.wikipedia.org/wiki/Windows_XP#Service_Pack_3_.28SP3.29

A moins que les service pack ne soient de la merde inutile, mais, je rappelle qu'ils amènent aussi des fonctionnalités, pas que des mises à jour de sécurité.
Du coup, on passe de 12 ans à 5 ans (en ne prenant pas en compte les mois, j'ai la flemme de chipoter).
Le monde à changé, oui, mais toutes les machines n'ont pas suivi.

Et je n'ai pas l'impression que tant de choses aient changé, quand je manipule un windows. Ce qui m'arrive encore assez souvent, à mon grand dam, je l'avoue.