Sinon je n'ai jamais prétendu que mon système était original, bien au contraire.
Certes. Disons que je me demandais juste pourquoi créer un système alors qu'il en existe déjà tant, notamment le célèbre BaSIC. Ca rejoins un peu l'idée de "pourquoi créer une nouvelle distro" habituelle sur ce site quoi :p
Les points d'expérience se gagnent assez difficilement (6 max en général à la fin d'une séance de jeu),
Avec WarHammer v1, les caractéristiques (celles qui s'exprimaient en %) montaient aussi 10 par 10, pour 100 points d'xp par contre, et l'on gagnait selon les MJ (et comment le joueur jouait) de 200 à 600 xp par partie. Et ça montait trop vite quand on prend ceux qui donnaient beaucoup. Il me semble que la v2 à divisé par 2 les points améliorés (c'est à dire que c'est passé à 5 pour la plupart des caract)
Non, j'avais trouvé ça du temps ou j'utilisais une cochonnerie nommée pearltrees, une sorte de réseau social en flash, sur lequel on indexe des trucs qui nous intéressent et où l'on peut du coup trouver d'autres infos du même sujet que d'autres ont mises. Au début c'était pas encore trop verrouillé, mais quand on deviens obligé de faire des manips à la con pour retrouver l'URL réelle (le site agissant comme un proxy, en plus de nécessiter flash…) ça gave rapidement. Donc j'ai fait comme pour tous les gadgets qui tentent de m'enfermer: suppression de compte et adieu.
Enfin, en faisant quelques recherches sur "google bubble filter" je suis tombé sur wikipedia, et voici la version fr de l'article en question pour les intéressés.
(notamment pour des recherches précises en français)
Bah… google non plus sur ce coup il me semble :)
Enfin, perso DDG me file pas de résultats en anglais, sauf si je le lui demande relativement explicitement (si j'enlève "kl=fr-fr" de mon url, ou si j'écris en anglais en fait).
Tu as raison en soi, mais si les appels ont été enregistrés je me demande s'il y a moyen que ça puisse montrer sa volonté d'être conciliant? Parce que les appels sont de plus en plus souvent enregistrés il me semble non?
Non, parce que bon, je connais pas ce protocole… En plus si c'est nouveau, à tout les coups ça va pas être dans les dépôts Debian et je vais devoir me taper des compilations à n'en plus finir moi!
Ce que je voulais surtout mettre en exergue, mais il fallait lire entre les lignes, c'est que par nature le but du commerce est de faire du bénéfice.
J'ai ensuite cité Dell pour montrer la faille du raisonnement avec lequel j'ai fait semblant d'être d'accord, désolé de ne pas avoir été plus explicite. D'ailleurs, on est tous un peu commerçants à notre niveau, puisqu'on vends nos compétences à nos patrons… la différence étant le statut, bien sûr, et donc aussi le risque pris sur nos biens.
J'ai du mal a voir ce qu'il y a d'original en lisant cette dépêche.
Déjà, un système mêlant "optionnellement" les dés à 6 faces et ceux à 10 s'éloigne de ce fait (de l'option) du principe de simplicité.
Quant aux 4 caractéristiques principales (intéressant, le terme "principal"… y'en a d'autres? Et c'est censé être simple?) c'est loin d'être une invention.
Par exemple, si je prends unknown armies, il s'agit de: corps, vitesse, esprit et âme. On fait très facilement le parallèle avec force, dextérité, volonté et intelligence.
Ça, c'est fait.
Maintenant, divers commentaires.
Dans la fiche de perso, tu as un espace pour le portrait, mais tous les rôlistes ne sont pas des dessinateurs accomplis :) en revanche, on sait en général décrire avec des mots (manquerait plus que ça…) et… il n'y a pas de zone pour décrire l'apparence du perso. On peut toujours coller ça dans les notes avec le background, mais c'est un peu étroit.
Au niveau des règles (principalement en regardant le mémo et très vite le début des règles):
Utiliser les caract mentales pour déterminer les PV me semble assez étrange, mais pourquoi pas. Perso, suis pas fan, mais bon.
16% de chances de réussir une action par défaut… hum… c'est beaucoup quand même.
Le combat est complexe, je pensais que tu voulais le simplifier? Je cite: "CC attaquant + (CC attaquant - CC défenseur) + modificateurs" ça en fait des calculs pour un aspect que l'on ne souhaite pas au coeur du jeu…
les compétences vont évoluer trop vite. 10% par point d'expérience, c'est juste énorme.
En bref, un système qui me paraît plutôt complexe (calculs importants lors des combats), qui risque de générer rapidement des grosbill (xp qui fait évoluer trop vite).
Je te conseilles de regarder UA, je pense que tu risques d'aimer le principe, surtout si tu recherches la simplicité des règles (je parie qu'en enlevant les dessins et les délires le background du jeu ça pourrait tenir sur 10 pages… voire moins, sans pourtant autant qu'il n'y ait de manques: combat, folie, actions, explication de ce que sont les compétences/caractéristiques… y'a tout. Sauf une liste de compétences ou de classes, mais c'est voulu.)
PS: j'ai jeté un oeil à la version jouable en ligne et… bah j'ai pas compris grand chose. Faut dire que j'ai jamais été doué pour deviner ce que les gens ont derrière la tête, alors trouver le bon mot-clé qui a été implémenté par le créateur… arf
La "bulle google" (nom que je me souviens avoir lu pour ce phénomène, mais une recherche ne me fais pas retomber sur les docs en question) est pourtant la seule explication que je trouve au fait que le comportement de google chez toi soit différent de celui qu'il a chez moi.
Quant à changer de moteur, l'autocompletion me propose "moteur de recherche google", le serpent se mort la queue.
Un truc rigolo, cherchez sur google "problème avec le transporteur" , et regardez ce que propose l'autocomplétion :p
Sur google, l'auto-complétion s'arrête quand je tape le 'n' de "problème avec le tran"…
Dis-moi, tu es au courant que google n'est pas un bon moteur de recherche si tu ne veux pas que tes résultats soient biaisés par tes recherches précédentes? XD (perso, je dirais même que c'est l'un des moins bons moteurs de recherche du marché actuel, mais ça n'engage que moi)
Sinon, il me semble que l'alliage d'étain utilisé pour l'électronique contiens du plomb, entres autres (j'ai cherché vite fait sur wikipedia, mais je n'ai rien trouvé de convainquant, je m'en remets donc à mes lointains souvenirs de STI génie électronique).
Wikipedia semble aussi indiquer que la matière étain est classée Xi.
Je pense que ça précise un peu plus le genre de soucis qu'on peut avoir? (pour moi le risque est très faible, mais bon… jouer avec du mercure ne me fais pas spécialement peur non plus et il paraît que c'est dangereux alors je suis pas une bonne référence je pense)
Le rôle de flash ne semble d'ailleurs pas d'afficher des images animées (ne contenant que du texte animé en fait) contrairement à ce qu'on pourrait croire, mais d'envoyer l'utilisateur vers un site dont je n'ai pas compris l'intérêt. Surement de la pub.
En gros: un des pires sites 1.0 que j'aie vu, je lui préfère le site de lynx.
Le but de LXC est de re-implémenter proprement les fonctionnalités d'OpenVZ
On comprend alors pourquoi c'est plus mis en avant. Par contre je dois admettre être étonné que Debian privilégie un successeur beaucoup moins mûr et notamment au niveau sécurité que le prédécesseur. Des infos à ce sujet? Des explications sur ML peut-être? (je suis juste curieux, hein, moi et la virtualisation…)
… et trop nombreuses comparé à la taille du texte.
Personnellement, ça ne me donne pas envie de lire l'ensemble quand je ne vois que des séries d'images prenant toute la hauteur de mon écran et entrecoupées d'une ou deux lignes de texte seulement.
Je conçois qu'il s'agisse d'un logiciel de travail sur des vidéo, donc très lié à une IHM, mais je pense que là, ça fait trop.
Un exemple bête: dans les 5 premières captures, 4 pourraient être réduites drastiquement.
Enfin, ce n'est que mon avis sur la forme de la dépêche. Je n'ai pas lu le fond du coup.
Quand on parle de l'alliage utilisé en électronique, alors, personnellement, je préfère ne pas en respirer trop. Vue l'odeur et les diverses réactions chimiques qui se produisent lorsque l'on soude, je doute que ce soit bénin à forte dose.
Mais bon, ici on parle d'une plaque de taille assez modeste, donc…
Quel est le rapport? Ils vendent un produit et un service, donnent au client le produit, mais pas le service, et ça ne serait pas de leur faute parce qu'en fait ils achètent la machine a quelqu'un d'autre? La blague…
Techniquement parlant, il y a quand même une boucle et 3 conditions, c'est plus compliqué que juste afficher un texte :P
A part ça, y'a pleins de logiciels qui sont encore moins complexes et qui doivent utiliser des bibliothèques. Un exemple bête, imagines un frontend de ls: il exécute ls, il récupère la sortie et l'affiche de façon graphique. L'intérêt? Il ajoute des cases à cocher avec les options genre :
if HumanReadable then command+=" -h "
et permets donc de bâtir des commandes ls a des gens qui ne savent pas se servir du man ni de l'auto-complétion.
Mais, j'admets, c'était juste pour t'embêter :=)
Plus sérieusement, on peut considérer que les bibliothèques elles-même sont des programmes, et certaines doivent bien être basées sur la lib standard. Mais bon, c'est hors-sujet et n'a rien à voir avec le fait que la GPL soit virale (ce qui est un fait, même qu'elle est faite pour)
Que veux-tu, certains aiment ne lire qu'un seul fichier à la fois. Je me demande comment ils font pour fusionner des dépôts rapidement par contre. Avec 2 écrans, un par fichier? Mouarf
Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)
Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut,
Ça dépends.
Ils le sont si tu sélectionnes les outils de bases lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps (cela dis, il semble que j'ai installé anacron sur ma machine, je sais pas pourquoi. J'imagine que je voulais jouer avec et que j'ai omis de le supprimer :) ).
Il semble que leur principal usage soit de compresser les journaux trop vieux, et je dois admettre que vu le peu d'usage que je fais des journaux (je les lis jamais: je sais c'est mal) je me moque un peu de leur présence.
Les logs de cron et d' anacron devraient être lisibles avec :
En gros, j'ai 3 lignes le 26 avril, et pleins le 1er mai. Rien d'autre, et pourtant ce système est bien plus vieux. Aucune info sur ce qui est fait exactement.
Ce lancement de tâches selon des contraintes temporelles, nécessaire au bon fonctionnement du système d'exploitation, peut être fait avec cron, ou avec systemd.
Ces tâches sont loin d'être nécessaires. Cron (et consort) sont des dépendances de logrotate, lui-même n'étant qu'une dépendance recommandée du système (de rsyslog en fait), rien de plus.
De même qu'aptitude recommande apt-xapian-index (dont je ne vois absolument pas l'intérêt et que je n'installe donc jamais), qui ensuite dépend du paquet python-apt n'implique pas que python-apt est un outil nécessaire au bon fonctionnement du système.
Il y a exactement 19 paquets qui dépendent directement d'anacron (flemme de regarder pour cron, mais si ils ont été bien fait, ça devrait être pareil) dont 10 pour lesquels il s'agit d'une dépendance, 4 qui le recommandent, et 5 qui le suggèrent.
Les 10:
checksecurity
fiaif
gnome-schedule
gnumed-server 16
gnumed-server 17 (je précise les versions ici pour montrer qu'en fait, c'est même pas vraiment 10…)
kde-config-cron 4.8
kde-config-cron 4.10 (idem)
logrotate 3.8.3-3
logrotate 3.8.3-4 (encore)
task-laptot 3.14
Les 4:
email-reminder
task-desktop 3.14+nmu2
update-notifier 0.99.3debian11
update-notifier-kde 1.2.4
Les 5:
backup-manager
bcron-run
cron (mouarf)
cronie (hum)
popularity-contest
Dis-moi qu'est-ce qui, dans ces logiciels, est réellement vital au système? Pour moi, rien… D'ailleurs, comme je l'ai dis, je fonctionne habituellement sans (et vais d'ailleurs re-supprimer cet outil dont je n'ai que faire).
J'ai compris ton propos, et je disais juste que la surconsommation de RAM causée par systemd me semble raisonnable, vu le matériel moderne.
Dans l'ensemble, je suis d'accord.
Mais pas sur du matériel bas de gamme, même moderne, comme l'est mon eeepc (par moderne, j'entends pas "tout neuf", mais avec des générations de matos ayant encore cours, comme les proc x64 bi-coeur multi-thread par exemple. La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).
Ce problème ne peut-il pas être réglé avec nice et son copain ionice ?
Probablement, mais je suis encore un débutant sous linux (ça fait que 3 ans que j'ai switché mon OS principal, et j'ai encore pas mal a apprendre pour qu'il fasse de plus en plus uniquement ce que je lui demande, de façon optimale).
Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.
Dans le cas de la compilation, clang++ à juste banni g++ de mes habitudes.
Dans le cas des processus d'init, je trouve encore un intérêt et un rôle utile à sysVinit, bien que je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.
Le principe est le suivant : un service est lancé uniquement lorsqu'on fait appel à lui, pas avant. L'opération est transparente pour l'utilisateur.
J'ai effectivement entendu parler de ça, et c'est d'ailleurs pourquoi mon avis sur systemd est très mitigé:
* d'un côté il crée des dépendances dont je n'ai pas l'usage et à un coût réel d'exécution
* d'un autre côté, il permets d'améliorer pas mal de choses: facilité de maintenance des scripts d'init, parallélisation du démarrage des services, montage des partitions à la demande, arrêt/démarrage des services pour qu'ils ne fonctionnent que si on en a besoin.
La plupart de ces avantages sont très très utiles pour un serveur, je pense (y compris le temps de démarrage réduit: quand un serveur doit redémarrer, autant que ça soit le plus bref possible), mais pour une machine d'utilisateur final, à part quelques services à lancer à la demande comme cups, samba, ou les outils des DEs (sur-?)évolués comme KDE/Gnome, l'intérêt est restreint. Et ces mêmes outils ne sont pas forcément utiles à toutes les machines.
D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.
Reste ssh, que je démarre généralement quand j'en ai besoin (c'est à dire uniquement quand je suis chez moi et que je me sers du PC portable comme d'une télécommande pour la tour). Selon top, au repos, il consomme 1Mo, à peu près…
dans les cas où c'est possible, cela permet d'économiser de la RAM. ;-)
Je suis conscient de cet avantage (comme dit plus haut) mais je me demande si la RAM ainsi économisée compense réellement la surcharge induite par l'usage de systemd sur un poste d'**utilisateur final et normal** genre bureautique (la moyenne des utilisateurs utilisent quoi, à part quelques jeux, un navigateur web, et un logiciel de traitement de texte?).
Sur un serveur, je n'en ai aucune idée. De prime abord je dirais que oui, vue la quantité de services lancés, mais à bien y réfléchir, de nos jours la tendance semble plutôt être a 1 service par serveur virtuel, avec N machines virtuelles installées par serveur physique (voire par grappe de serveur physiques) histoire de réguler la charge. Après, je ne connais pas trop ce domaine donc… je dis sûrement de la merde :D
Sur un poste de développeur web, ça me semble évident que systemd soit intéressant, vu que j'imagine qu'il faut utiliser des serveurs de diverses sortes régulièrement pour tester. Pour un poste de dev "classique" par contre, je ne vois pas l'intérêt.
C'est quand même surprenant ta fixette, je connais pas ou peu de monde à ce point bloqué par cette phase de génération de moc en regard des énormes avantages que présente Qt en échange.
Relis un peu plus haut. La dernière fois que j'ai eu affaire à ce truc, ça a été loin d'être si évident. Bien entendu, ça remonte à plusieurs années et, depuis, mes connaissances et les logiciels que j'utilise on pas mal évolué (j'ai notamment découvert cmake, moi qui ne connaissais que la compilation via les IDE ou en ligne de commande à cette époque).
Je suis conscient qu'ils ont un gros héritage technique, qu'ils ont manifestement (à en lire les réponses) plutôt pas mal réussi à gérer et surtout réduire (modularité du code, notamment).
Je suis aussi conscient que C++11 est bien trop récent pour qu'ils en utilisent les nouveautés dans le coeur (quoique, vu qu'ils se basent sur des outils libres, peut-être qu'ils ont une branche stable ou c'est supporté?) mais il me semble que depuis 2003 (date du standard précédent) il est possible de faire la même chose que ce que Qt fait (au sujet des signaux je parle bien entendu) sans utiliser cet outil.
Pour le coup, oui, je trouve ridicule de conserver cet outil.
Au fait, je me demande ce que donne l'utilisation de cmake sous windows? Avec nos distros linux, cet outil voit sa tâche largement facilitée par le fait que les fichiers de dev soient dans des endroits standards, mais sous windows, ce n'était pas encore le cas la dernière fois que j'ai regardé.
Faudra que je teste, peut-être demain, je dois bien avoir une vieille licence d'xp qui traine…
Si tu utilises grub, il faut rajouter single à la ligne kernel (lien).
LILO :)
Grub2 est devenu pénible à configurer, d'où mon passage à LILO.
Systemd est plus qu'un système d'init
Attention, passage truffé de suppositions ;)
Je crois que c'est justement ce qui bloque pas mal d'opposants.
Quel intérêt de changer pour un composant qui fasse plus de choses si on ne s'en sers que comme d'un système d'init?
Par exemple, tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité: j'éteins mes bécanes (oui je sais, je pourrais utiliser l'hibernation. Mais même dans ce cas, on peut utiliser les scripts j'imagine) quand je m'en sers plus, donc si j'ai besoin de faire quelque chose régulièrement je peux facilement le mettre au moment du boot ou de l'extinction. La plupart du code contenu dans les scripts d'init sers à gérer un service: pour une simple "tâche évènementielle" je pense que ce n'est pas nécessaire de s'encombrer de toute la structure "start/restart/stop/status" si le but est juste de lancer une tâche.
A bien y réfléchir, la mécanique des runlevel est plus puissante que je l'imaginais… j'ai encore trop de réflexes de mes années windows et je n'aurai pas imaginé avant ce message utiliser les runlevels pour planifier une action à l'extinction de ma machine :)
selon des contraintes temporelles
Je pense que là, on met le doigt sur un autre problème, justement. Ce que je vais dire rejoins assez ce commentaire d'une autre autre dépêche: quel intérêt pour un ordinateur de bureau utilisé par quelqu'un de normal?
Lancer une tâche toutes les 20 minutes ou à heure fixe? Je ne vois personne dans mon entourage qui le fasse… Bien sûr, pour faire des mises à jour automatiques sur une machine qui est toujours allumée, c'est utile. C'est aussi super sur un serveur qui doit faire des backup réguliers et n'a comme réelle donnée pour savoir quand que le temps.
Mais voila, tout ça, c'est super pour des serveurs (ou même du matériel embarqué), pour un ordinateur de bureau c'est bien plus contestable.
systemd est une avancée mais surtout pour ceux qui administrent des serveurs ou des machines professionnelles, qui ne s'éteignent jamais. Pour les autres utilisateurs qui ne veulent qu'activer/désactiver des services au lancement de la machine, je n'en suis pas sûr: renommer /etc/rc2.d/S02mpd en /etc/rc2.d/K02mpd n'est pas complexe, et je parie qu'il existe des GUI pour le faire (enfin, non, je parie pas, je sais qu'il y en a au moins une, mais impossible de remettre la synapse sur son nom…).
qui consiste à dire qu'on se fiche de l'occupation mémoire des logiciels qu'on écrit parce que le client bah "il a qu'a acheter de la ram".
Nous parlons d'une surconsommation de RAM (de systemd par rapport à sysvinit) de 30 ou 40 Mo.
Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.
Pour en revenir à systemd et son augmentation de 30Mo, ou mieux, en prenant ton test Debian/ArchLinux, j'ai toujours préféré les données relatives: 30Mo supplémentaires ne veulent rien dire en soit, je préfère parler de 100% d'augmentation.
Ca parle beaucoup plus ainsi.
Par exemple, si on parle d'une augmentation de la consommation de 30Mo de LibreOffice d'une version X à une version Y, si la version X consommait 1000Mo (j'invente hein) alors ce n'est une augmentation que de 3%. Pas loin d'être négligeable donc. Alors que la version X consommait 30Mo, et la version Y passe à 60Mo, il vaut mieux que le gain en fonctionnalités vaille le coup pour moi. (surtout que dans un cas comme dans l'autre, rien ne dis que j'utiliserai ces nouvelles fonctionnalités)
Dans le cas de systemd, ça semble être le cas… même si suis assez sceptique sur la nécessité de certaines dépendances en dur que je n'utilise pas (je pense ici à dbus). Encore une fois, c'est une simple augmentation de 30Mo de la consommation de ma machine (j'invente, encore) mais si je dois rajouter une consommation moyenne de 60Mo, ça peut vouloir dire que ma machine va beaucoup plus swapper quand je compile, et le disque dur est d'une lenteur impressionnante, et quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes (du coup je tournais à mi-régime et ça compilait en +/-4 minutes. J'ai ensuite découvert clang, et je suis passé à +/-2 minutes :) )
Je pourrais acheter de la RAM bien sûr, mais dans ce cas c'est l'autonomie de ma batterie qui va diminuer il me semble.
Enfin, je ne suis pas un expert sur la question… mais je pense que si systemd est bel et bien une avancée sur pas mal de points, il a malgré tout des conséquences négatives qui font qu'il faut qu'un autre système d'init, un qui ne fasse que ça, soit toujours maintenu. Peu m'importe que ce soit sysVinit, openRC ou je ne sais quoi, mais j'adhère assez à la philosophie UNIX qui dit que les programmes efficaces ne font qu'une seule chose mais la font bien (ça ne m'empêche pas de voir qu'il y a plein de contre exemples).
Tu le dis toi-même, certaines libs boost dépendent d'autres lib boost.
J'aurai dû ajouter l'adjectif "rares" :) (et le fait que la seule dépendance que j'aie eu pour le moment est envers la lib "system" qui est devenue partie intégrante du standard. Mais je suis loin de les avoir toutes utilisées…)
Et si on continue sur les points forts de boost, il faut préciser que la plupart de ses lib ne sont que des headers. Niveau simplicité d'usage, on peut difficilement faire mieux (et Qt passe donc hors catégorie sur ce point, voir la suite).
Le principe KISS est justement respecté avec l'interdépendances des libs,
On dirait que ça a bien évolué alors. Tant mieux. Plus que la chaîne de compilation à simplifier, alors?
Parce que ce point à été (et restera encore un certain temps je pense) un vrai point bloquant.
On peut dire ce qu'on veut, mais la mécanique des signaux si chère à Qt possède ce défaut majeur qui est de rendre la compilation bien plus casse-pieds, alors que les autres framework s'en passent très bien.
Dès lors que tu ne veux pas utiliser l'IDE officiel, tu galères. En tout cas, à l'époque de mon BTS KDevelop galérais (y'a 7 ans en gros) lui qui était pourtant écrit avec Qt (je me rappelle qu'il fallait invoquer l'outil à la main… moc, c'est ça?), il y a 3 ans Visual Studio 2008 galérait (je sais pas maintenant si c'est plus simple, mais j'en doute), Code::Blocks galèrait encore y'a 3 ans, utiliser la ligne de commande sous windows imposait d'utiliser une ligne de commande customisée par et pour Qt (mais qui ne connaissais du coup que les modifs faites par et pour l'installateur de Qt, irrecevable pour moi)…
Il n'y a bien que Qt Creator et CMake qui ne galèrent pas. Pour le coup, vu que je n'utilise plus trop d'IDE, je pourrais peut-être m'y remettre, mais l'idée de risquer d'en chier avec la compilation pour une fonctionnalité dont tout les autres framework se passent allègrement me rebute.
J'imagine qu'on va me dire qu'il utiliser l'outil qu'une seule fois et blablabla… mais de mémoire, il faut l'utiliser à chaque modification de l'interface, ce qui peut arriver souvent… Enfin, arrivais, avant l'arrivée des technos ou l'interface n'est plus codée en dur. Mais là encore, les autres le font aussi bien sans ajouter leur outil dans la chaîne.
Ce qui est certain de toute façon, c'est que pour au moins un projet que j'aimais bien (rolisteam), et pour lequel j'avais envie de contribuer et tant pis pour la lib Qt sous-jacente que je ne maîtrisais pas (j'avais des souvenirs du BTS mais ça datait déjà) je n'ai jamais réussi à compiler, sauf à utiliser QtCreator, mais ce truc n'a vraiment jamais été à mon goût, moi qui préfère les interfaces minimalistes.
[^] # Re: Original et simple?
Posté par freem . En réponse au journal ESCAPADES dans La vallée mystérieuse (système de jeu de rôle). Évalué à 3.
Certes. Disons que je me demandais juste pourquoi créer un système alors qu'il en existe déjà tant, notamment le célèbre BaSIC. Ca rejoins un peu l'idée de "pourquoi créer une nouvelle distro" habituelle sur ce site quoi :p
Avec WarHammer v1, les caractéristiques (celles qui s'exprimaient en %) montaient aussi 10 par 10, pour 100 points d'xp par contre, et l'on gagnait selon les MJ (et comment le joueur jouait) de 200 à 600 xp par partie. Et ça montait trop vite quand on prend ceux qui donnaient beaucoup. Il me semble que la v2 à divisé par 2 les points améliorés (c'est à dire que c'est passé à 5 pour la plupart des caract)
[^] # Re: ils passent aujourd'hui (comique de répétition) dixit Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 1.
Non, j'avais trouvé ça du temps ou j'utilisais une cochonnerie nommée pearltrees, une sorte de réseau social en flash, sur lequel on indexe des trucs qui nous intéressent et où l'on peut du coup trouver d'autres infos du même sujet que d'autres ont mises. Au début c'était pas encore trop verrouillé, mais quand on deviens obligé de faire des manips à la con pour retrouver l'URL réelle (le site agissant comme un proxy, en plus de nécessiter flash…) ça gave rapidement. Donc j'ai fait comme pour tous les gadgets qui tentent de m'enfermer: suppression de compte et adieu.
Enfin, en faisant quelques recherches sur "google bubble filter" je suis tombé sur wikipedia, et voici la version fr de l'article en question pour les intéressés.
Bah… google non plus sur ce coup il me semble :)
Enfin, perso DDG me file pas de résultats en anglais, sauf si je le lui demande relativement explicitement (si j'enlève "kl=fr-fr" de mon url, ou si j'écris en anglais en fait).
[^] # Re: ils passent aujourd'hui (comique de répétition) dixit Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 1.
Tu as raison en soi, mais si les appels ont été enregistrés je me demande s'il y a moyen que ça puisse montrer sa volonté d'être conciliant? Parce que les appels sont de plus en plus souvent enregistrés il me semble non?
# Quelqu'un à un client IRL ?
Posté par freem . En réponse à la dépêche Rejoignez LinuxFr.org ! LinuxFr.org c'est vous !. Évalué à 5.
Non, parce que bon, je connais pas ce protocole… En plus si c'est nouveau, à tout les coups ça va pas être dans les dépôts Debian et je vais devoir me taper des compilations à n'en plus finir moi!
[^] # Re: Boutique de quartier ?
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 1.
Ce que je voulais surtout mettre en exergue, mais il fallait lire entre les lignes, c'est que par nature le but du commerce est de faire du bénéfice.
J'ai ensuite cité Dell pour montrer la faille du raisonnement avec lequel j'ai fait semblant d'être d'accord, désolé de ne pas avoir été plus explicite. D'ailleurs, on est tous un peu commerçants à notre niveau, puisqu'on vends nos compétences à nos patrons… la différence étant le statut, bien sûr, et donc aussi le risque pris sur nos biens.
# Original et simple?
Posté par freem . En réponse au journal ESCAPADES dans La vallée mystérieuse (système de jeu de rôle). Évalué à 2. Dernière modification le 02 mai 2013 à 16:41.
J'ai du mal a voir ce qu'il y a d'original en lisant cette dépêche.
Déjà, un système mêlant "optionnellement" les dés à 6 faces et ceux à 10 s'éloigne de ce fait (de l'option) du principe de simplicité.
Quant aux 4 caractéristiques principales (intéressant, le terme "principal"… y'en a d'autres? Et c'est censé être simple?) c'est loin d'être une invention.
Par exemple, si je prends unknown armies, il s'agit de: corps, vitesse, esprit et âme. On fait très facilement le parallèle avec force, dextérité, volonté et intelligence.
Ça, c'est fait.
Maintenant, divers commentaires.
Dans la fiche de perso, tu as un espace pour le portrait, mais tous les rôlistes ne sont pas des dessinateurs accomplis :) en revanche, on sait en général décrire avec des mots (manquerait plus que ça…) et… il n'y a pas de zone pour décrire l'apparence du perso. On peut toujours coller ça dans les notes avec le background, mais c'est un peu étroit.
Au niveau des règles (principalement en regardant le mémo et très vite le début des règles):
En bref, un système qui me paraît plutôt complexe (calculs importants lors des combats), qui risque de générer rapidement des grosbill (xp qui fait évoluer trop vite).
Je te conseilles de regarder UA, je pense que tu risques d'aimer le principe, surtout si tu recherches la simplicité des règles (je parie qu'en enlevant les dessins et
les déliresle background du jeu ça pourrait tenir sur 10 pages… voire moins, sans pourtant autant qu'il n'y ait de manques: combat, folie, actions, explication de ce que sont les compétences/caractéristiques… y'a tout. Sauf une liste de compétences ou de classes, mais c'est voulu.)PS: j'ai jeté un oeil à la version jouable en ligne et… bah j'ai pas compris grand chose. Faut dire que j'ai jamais été doué pour deviner ce que les gens ont derrière la tête, alors trouver le bon mot-clé qui a été implémenté par le créateur… arf
PPS: bonne chance pour la suite.
[^] # Re: ils passent aujourd'hui (comique de répétition) dixit Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 1.
Y'a pas de commande, le produit est déjà acheté.
[^] # Re: ils passent aujourd'hui (comique de répétition) dixit Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 2.
La "bulle google" (nom que je me souviens avoir lu pour ce phénomène, mais une recherche ne me fais pas retomber sur les docs en question) est pourtant la seule explication que je trouve au fait que le comportement de google chez toi soit différent de celui qu'il a chez moi.
XD
[^] # Re: ils passent aujourd'hui (comique de répétition) dixit Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 3.
Sur google, l'auto-complétion s'arrête quand je tape le 'n' de "problème avec le tran"…
Dis-moi, tu es au courant que google n'est pas un bon moteur de recherche si tu ne veux pas que tes résultats soient biaisés par tes recherches précédentes? XD (perso, je dirais même que c'est l'un des moins bons moteurs de recherche du marché actuel, mais ça n'engage que moi)
[^] # Re: Le support Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 1.
Pas faux.
Sinon, il me semble que l'alliage d'étain utilisé pour l'électronique contiens du plomb, entres autres (j'ai cherché vite fait sur wikipedia, mais je n'ai rien trouvé de convainquant, je m'en remets donc à mes lointains souvenirs de STI génie électronique).
Wikipedia semble aussi indiquer que la matière étain est classée Xi.
Je pense que ça précise un peu plus le genre de soucis qu'on peut avoir? (pour moi le risque est très faible, mais bon… jouer avec du mercure ne me fais pas spécialement peur non plus et il paraît que c'est dangereux alors je suis pas une bonne référence je pense)
[^] # Re: Web 1.0
Posté par freem . En réponse au journal Le web à 20 ans. Évalué à 1.
En fait flash est utilisé toutes les 2 sections.
Le rôle de flash ne semble d'ailleurs pas d'afficher des images animées (ne contenant que du texte animé en fait) contrairement à ce qu'on pourrait croire, mais d'envoyer l'utilisateur vers un site dont je n'ai pas compris l'intérêt. Surement de la pub.
En gros: un des pires sites 1.0 que j'aie vu, je lui préfère le site de lynx.
[^] # Re: On peut espérer...
Posté par freem . En réponse au journal OpenVZ sur Debian : Que prévoyez-vous avec Wheezy ?. Évalué à 1.
On comprend alors pourquoi c'est plus mis en avant. Par contre je dois admettre être étonné que Debian privilégie un successeur beaucoup moins mûr et notamment au niveau sécurité que le prédécesseur. Des infos à ce sujet? Des explications sur ML peut-être? (je suis juste curieux, hein, moi et la virtualisation…)
[^] # Re: Une dépêche ou pas dêpeche ??
Posté par freem . En réponse au journal Essai de Lightworks Beta 11.1.h sous GNU/Linux. Évalué à 4.
Non, parce que les images hollydiennes, çapucépalibre.
je suis déjà dehors :)
# Captures trop grosses ...
Posté par freem . En réponse au journal Essai de Lightworks Beta 11.1.h sous GNU/Linux. Évalué à -1.
… et trop nombreuses comparé à la taille du texte.
Personnellement, ça ne me donne pas envie de lire l'ensemble quand je ne vois que des séries d'images prenant toute la hauteur de mon écran et entrecoupées d'une ou deux lignes de texte seulement.
Je conçois qu'il s'agisse d'un logiciel de travail sur des vidéo, donc très lié à une IHM, mais je pense que là, ça fait trop.
Un exemple bête: dans les 5 premières captures, 4 pourraient être réduites drastiquement.
Enfin, ce n'est que mon avis sur la forme de la dépêche. Je n'ai pas lu le fond du coup.
[^] # Re: Boutique de quartier ?
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 3.
C'est vrai… mais c'est vrai de tous les commerçants, si on y pense bien. Y compris de Dell si on lit l'histoire plus haut.
Non. Il y a aussi l'avantage de pouvoir négocier, et celui de la proximité en cas de problème.
[^] # Re: Le support Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 2.
Si tu parles du métal, je pense que non.
Quand on parle de l'alliage utilisé en électronique, alors, personnellement, je préfère ne pas en respirer trop. Vue l'odeur et les diverses réactions chimiques qui se produisent lorsque l'on soude, je doute que ce soit bénin à forte dose.
Mais bon, ici on parle d'une plaque de taille assez modeste, donc…
[^] # Re: Pas le même support
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 7.
Et?
Quel est le rapport? Ils vendent un produit et un service, donnent au client le produit, mais pas le service, et ça ne serait pas de leur faute parce qu'en fait ils achètent la machine a quelqu'un d'autre? La blague…
[^] # Re: Le libre n'est pas viral
Posté par freem . En réponse à la dépêche L'accord cadre « Open Bar » Microsoft/Défense en cours de renégociation. Évalué à 1.
Le pendu alors?
Techniquement parlant, il y a quand même une boucle et 3 conditions, c'est plus compliqué que juste afficher un texte :P
A part ça, y'a pleins de logiciels qui sont encore moins complexes et qui doivent utiliser des bibliothèques. Un exemple bête, imagines un frontend de ls: il exécute ls, il récupère la sortie et l'affiche de façon graphique. L'intérêt? Il ajoute des cases à cocher avec les options genre :
et permets donc de bâtir des commandes ls a des gens qui ne savent pas se servir du man ni de l'auto-complétion.
Mais, j'admets, c'était juste pour t'embêter :=)
Plus sérieusement, on peut considérer que les bibliothèques elles-même sont des programmes, et certaines doivent bien être basées sur la lib standard. Mais bon, c'est hors-sujet et n'a rien à voir avec le fait que la GPL soit virale (ce qui est un fait, même qu'elle est faite pour)
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Que veux-tu, certains aiment ne lire qu'un seul fichier à la fois. Je me demande comment ils font pour fusionner des dépôts rapidement par contre. Avec 2 écrans, un par fichier? Mouarf
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)
Ça dépends.
Ils le sont si tu sélectionnes les outils de bases lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps (cela dis, il semble que j'ai installé anacron sur ma machine, je sais pas pourquoi. J'imagine que je voulais jouer avec et que j'ai omis de le supprimer :) ).
Il semble que leur principal usage soit de compresser les journaux trop vieux, et je dois admettre que vu le peu d'usage que je fais des journaux (je les lis jamais: je sais c'est mal) je me moque un peu de leur présence.
En gros, j'ai 3 lignes le 26 avril, et pleins le 1er mai. Rien d'autre, et pourtant ce système est bien plus vieux. Aucune info sur ce qui est fait exactement.
Ces tâches sont loin d'être nécessaires. Cron (et consort) sont des dépendances de logrotate, lui-même n'étant qu'une dépendance recommandée du système (de rsyslog en fait), rien de plus.
De même qu'aptitude recommande apt-xapian-index (dont je ne vois absolument pas l'intérêt et que je n'installe donc jamais), qui ensuite dépend du paquet python-apt n'implique pas que python-apt est un outil nécessaire au bon fonctionnement du système.
Il y a exactement 19 paquets qui dépendent directement d'anacron (flemme de regarder pour cron, mais si ils ont été bien fait, ça devrait être pareil) dont 10 pour lesquels il s'agit d'une dépendance, 4 qui le recommandent, et 5 qui le suggèrent.
Les 10:
Les 4:
Les 5:
Dis-moi qu'est-ce qui, dans ces logiciels, est réellement vital au système? Pour moi, rien… D'ailleurs, comme je l'ai dis, je fonctionne habituellement sans (et vais d'ailleurs re-supprimer cet outil dont je n'ai que faire).
Dans l'ensemble, je suis d'accord.
Mais pas sur du matériel bas de gamme, même moderne, comme l'est mon eeepc (par moderne, j'entends pas "tout neuf", mais avec des générations de matos ayant encore cours, comme les proc x64 bi-coeur multi-thread par exemple. La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).
Probablement, mais je suis encore un débutant sous linux (ça fait que 3 ans que j'ai switché mon OS principal, et j'ai encore pas mal a apprendre pour qu'il fasse de plus en plus uniquement ce que je lui demande, de façon optimale).
Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.
Dans le cas de la compilation, clang++ à juste banni g++ de mes habitudes.
Dans le cas des processus d'init, je trouve encore un intérêt et un rôle utile à sysVinit, bien que je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.
J'ai effectivement entendu parler de ça, et c'est d'ailleurs pourquoi mon avis sur systemd est très mitigé:
* d'un côté il crée des dépendances dont je n'ai pas l'usage et à un coût réel d'exécution
* d'un autre côté, il permets d'améliorer pas mal de choses: facilité de maintenance des scripts d'init, parallélisation du démarrage des services, montage des partitions à la demande, arrêt/démarrage des services pour qu'ils ne fonctionnent que si on en a besoin.
La plupart de ces avantages sont très très utiles pour un serveur, je pense (y compris le temps de démarrage réduit: quand un serveur doit redémarrer, autant que ça soit le plus bref possible), mais pour une machine d'utilisateur final, à part quelques services à lancer à la demande comme cups, samba, ou les outils des DEs (sur-?)évolués comme KDE/Gnome, l'intérêt est restreint. Et ces mêmes outils ne sont pas forcément utiles à toutes les machines.
D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.
Reste ssh, que je démarre généralement quand j'en ai besoin (c'est à dire uniquement quand je suis chez moi et que je me sers du PC portable comme d'une télécommande pour la tour). Selon top, au repos, il consomme 1Mo, à peu près…
Je suis conscient de cet avantage (comme dit plus haut) mais je me demande si la RAM ainsi économisée compense réellement la surcharge induite par l'usage de systemd sur un poste d'**utilisateur final et normal** genre bureautique (la moyenne des utilisateurs utilisent quoi, à part quelques jeux, un navigateur web, et un logiciel de traitement de texte?).
Sur un serveur, je n'en ai aucune idée. De prime abord je dirais que oui, vue la quantité de services lancés, mais à bien y réfléchir, de nos jours la tendance semble plutôt être a 1 service par serveur virtuel, avec N machines virtuelles installées par serveur physique (voire par grappe de serveur physiques) histoire de réguler la charge. Après, je ne connais pas trop ce domaine donc… je dis sûrement de la merde :D
Sur un poste de développeur web, ça me semble évident que systemd soit intéressant, vu que j'imagine qu'il faut utiliser des serveurs de diverses sortes régulièrement pour tester. Pour un poste de dev "classique" par contre, je ne vois pas l'intérêt.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Relis un peu plus haut. La dernière fois que j'ai eu affaire à ce truc, ça a été loin d'être si évident. Bien entendu, ça remonte à plusieurs années et, depuis, mes connaissances et les logiciels que j'utilise on pas mal évolué (j'ai notamment découvert cmake, moi qui ne connaissais que la compilation via les IDE ou en ligne de commande à cette époque).
Je suis conscient qu'ils ont un gros héritage technique, qu'ils ont manifestement (à en lire les réponses) plutôt pas mal réussi à gérer et surtout réduire (modularité du code, notamment).
Je suis aussi conscient que C++11 est bien trop récent pour qu'ils en utilisent les nouveautés dans le coeur (quoique, vu qu'ils se basent sur des outils libres, peut-être qu'ils ont une branche stable ou c'est supporté?) mais il me semble que depuis 2003 (date du standard précédent) il est possible de faire la même chose que ce que Qt fait (au sujet des signaux je parle bien entendu) sans utiliser cet outil.
Pour le coup, oui, je trouve ridicule de conserver cet outil.
Au fait, je me demande ce que donne l'utilisation de cmake sous windows? Avec nos distros linux, cet outil voit sa tâche largement facilitée par le fait que les fichiers de dev soient dans des endroits standards, mais sous windows, ce n'était pas encore le cas la dernière fois que j'ai regardé.
Faudra que je teste, peut-être demain, je dois bien avoir une vieille licence d'xp qui traine…
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -5.
Il y a aussi des framework qui n'imposent pas de restriction aussi ridicule. J'irai même jusqu'a dire que Qt est le seul à le faire…
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
LILO :)
Grub2 est devenu pénible à configurer, d'où mon passage à LILO.
Attention, passage truffé de suppositions ;)
Je crois que c'est justement ce qui bloque pas mal d'opposants.
Quel intérêt de changer pour un composant qui fasse plus de choses si on ne s'en sers que comme d'un système d'init?
Par exemple, tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité: j'éteins mes bécanes (oui je sais, je pourrais utiliser l'hibernation. Mais même dans ce cas, on peut utiliser les scripts j'imagine) quand je m'en sers plus, donc si j'ai besoin de faire quelque chose régulièrement je peux facilement le mettre au moment du boot ou de l'extinction. La plupart du code contenu dans les scripts d'init sers à gérer un service: pour une simple "tâche évènementielle" je pense que ce n'est pas nécessaire de s'encombrer de toute la structure "start/restart/stop/status" si le but est juste de lancer une tâche.
A bien y réfléchir, la mécanique des runlevel est plus puissante que je l'imaginais… j'ai encore trop de réflexes de mes années windows et je n'aurai pas imaginé avant ce message utiliser les runlevels pour planifier une action à l'extinction de ma machine :)
Je pense que là, on met le doigt sur un autre problème, justement. Ce que je vais dire rejoins assez ce commentaire d'une autre autre dépêche: quel intérêt pour un ordinateur de bureau utilisé par quelqu'un de normal?
Lancer une tâche toutes les 20 minutes ou à heure fixe? Je ne vois personne dans mon entourage qui le fasse… Bien sûr, pour faire des mises à jour automatiques sur une machine qui est toujours allumée, c'est utile. C'est aussi super sur un serveur qui doit faire des backup réguliers et n'a comme réelle donnée pour savoir quand que le temps.
Mais voila, tout ça, c'est super pour des serveurs (ou même du matériel embarqué), pour un ordinateur de bureau c'est bien plus contestable.
systemd est une avancée mais surtout pour ceux qui administrent des serveurs ou des machines professionnelles, qui ne s'éteignent jamais. Pour les autres utilisateurs qui ne veulent qu'activer/désactiver des services au lancement de la machine, je n'en suis pas sûr: renommer /etc/rc2.d/S02mpd en /etc/rc2.d/K02mpd n'est pas complexe, et je parie qu'il existe des GUI pour le faire (enfin, non, je parie pas, je sais qu'il y en a au moins une, mais impossible de remettre la synapse sur son nom…).
Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.
Pour en revenir à systemd et son augmentation de 30Mo, ou mieux, en prenant ton test Debian/ArchLinux, j'ai toujours préféré les données relatives: 30Mo supplémentaires ne veulent rien dire en soit, je préfère parler de 100% d'augmentation.
Ca parle beaucoup plus ainsi.
Par exemple, si on parle d'une augmentation de la consommation de 30Mo de LibreOffice d'une version X à une version Y, si la version X consommait 1000Mo (j'invente hein) alors ce n'est une augmentation que de 3%. Pas loin d'être négligeable donc. Alors que la version X consommait 30Mo, et la version Y passe à 60Mo, il vaut mieux que le gain en fonctionnalités vaille le coup pour moi. (surtout que dans un cas comme dans l'autre, rien ne dis que j'utiliserai ces nouvelles fonctionnalités)
Dans le cas de systemd, ça semble être le cas… même si suis assez sceptique sur la nécessité de certaines dépendances en dur que je n'utilise pas (je pense ici à dbus). Encore une fois, c'est une simple augmentation de 30Mo de la consommation de ma machine (j'invente, encore) mais si je dois rajouter une consommation moyenne de 60Mo, ça peut vouloir dire que ma machine va beaucoup plus swapper quand je compile, et le disque dur est d'une lenteur impressionnante, et quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes (du coup je tournais à mi-régime et ça compilait en +/-4 minutes. J'ai ensuite découvert clang, et je suis passé à +/-2 minutes :) )
Je pourrais acheter de la RAM bien sûr, mais dans ce cas c'est l'autonomie de ma batterie qui va diminuer il me semble.
Enfin, je ne suis pas un expert sur la question… mais je pense que si systemd est bel et bien une avancée sur pas mal de points, il a malgré tout des conséquences négatives qui font qu'il faut qu'un autre système d'init, un qui ne fasse que ça, soit toujours maintenu. Peu m'importe que ce soit sysVinit, openRC ou je ne sais quoi, mais j'adhère assez à la philosophie UNIX qui dit que les programmes efficaces ne font qu'une seule chose mais la font bien (ça ne m'empêche pas de voir qu'il y a plein de contre exemples).
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -3.
J'aurai dû ajouter l'adjectif "rares" :) (et le fait que la seule dépendance que j'aie eu pour le moment est envers la lib "system" qui est devenue partie intégrante du standard. Mais je suis loin de les avoir toutes utilisées…)
Et si on continue sur les points forts de boost, il faut préciser que la plupart de ses lib ne sont que des headers. Niveau simplicité d'usage, on peut difficilement faire mieux (et Qt passe donc hors catégorie sur ce point, voir la suite).
On dirait que ça a bien évolué alors. Tant mieux. Plus que la chaîne de compilation à simplifier, alors?
Parce que ce point à été (et restera encore un certain temps je pense) un vrai point bloquant.
On peut dire ce qu'on veut, mais la mécanique des signaux si chère à Qt possède ce défaut majeur qui est de rendre la compilation bien plus casse-pieds, alors que les autres framework s'en passent très bien.
Dès lors que tu ne veux pas utiliser l'IDE officiel, tu galères. En tout cas, à l'époque de mon BTS KDevelop galérais (y'a 7 ans en gros) lui qui était pourtant écrit avec Qt (je me rappelle qu'il fallait invoquer l'outil à la main… moc, c'est ça?), il y a 3 ans Visual Studio 2008 galérait (je sais pas maintenant si c'est plus simple, mais j'en doute), Code::Blocks galèrait encore y'a 3 ans, utiliser la ligne de commande sous windows imposait d'utiliser une ligne de commande customisée par et pour Qt (mais qui ne connaissais du coup que les modifs faites par et pour l'installateur de Qt, irrecevable pour moi)…
Il n'y a bien que Qt Creator et CMake qui ne galèrent pas. Pour le coup, vu que je n'utilise plus trop d'IDE, je pourrais peut-être m'y remettre, mais l'idée de risquer d'en chier avec la compilation pour une fonctionnalité dont tout les autres framework se passent allègrement me rebute.
J'imagine qu'on va me dire qu'il utiliser l'outil qu'une seule fois et blablabla… mais de mémoire, il faut l'utiliser à chaque modification de l'interface, ce qui peut arriver souvent… Enfin, arrivais, avant l'arrivée des technos ou l'interface n'est plus codée en dur. Mais là encore, les autres le font aussi bien sans ajouter leur outil dans la chaîne.
Ce qui est certain de toute façon, c'est que pour au moins un projet que j'aimais bien (rolisteam), et pour lequel j'avais envie de contribuer et tant pis pour la lib Qt sous-jacente que je ne maîtrisais pas (j'avais des souvenirs du BTS mais ça datait déjà) je n'ai jamais réussi à compiler, sauf à utiliser QtCreator, mais ce truc n'a vraiment jamais été à mon goût, moi qui préfère les interfaces minimalistes.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Pourquoi ne pas laisser au noyau la charge de faire son boulot efficacement, c'est à dire: gérer les processus?