Il n'y a que moi qui trouve inquiétant qu'un langage qui est en développement depuis plusieurs années et qui s'approche de la version finale à grand pas soit aussi instable au niveau de sa syntaxe ? (et pas uniquement sur des détails en plus). Moi, quand on vient me dire qu'on peut commencer à tester, je fuis immédiatement, parce que je me dis que ce langage risque d'évoluer suffisamment pour que tout ce que j'apprends et je fais soit obsolète dans deux mois… Enfin, c'est l'impression que ça me donne.
Je ne pense pas qu'il dise que c'est mauvais comme gameplay, il dit simplement que le game designer n'a pas fait beaucoup d'effort pour imaginer autre chose que le cliché. Maintenant, il pourrait évoquer le pourquoi (c'est-à-dire pourquoi on voit sans cesse les mêmes clichés), et il l'effleure à peine à deux moments dans la suite de la série. Premièrement quand il parle du turnover, deuxièmement quand il parle des FPS qui sont les nouveaux sidescroller.
Son discours est de dire qu'à cause du turnover, il n'y a pas de mémoire et donc, les game designers refont toujours les mêmes bêtises (ce qui est discutable). Et ensuite, il dit que c'est dans les FPS qu'on retrouve la plupart de ce qu'il dénonce et que ce sont les nouveaux sidescroller, sous-entendu il en existe une tétrachiée qui se ressemblent tous comme les sidescrollers dans les années 90. À mon sens, il analyse bien la conséquence mais il ne voit pas la vraie cause qui est l'industrialisation massive du jeu vidéo. Quand il commence sa série, les «gros» studios sont des nains composés de pionniers, avec une technologie très changeante. Aujourd'hui, on a des entreprises énormes, une industrie qui surpasse le cinéma et la musique, des milliards de brouzoufs à engranger ou à perdre. Donc, comme pour le cinéma, on fait ce qui marche et donc, on ne s'écarte pas trop des clichés et de ce qu'il considère comme des mauvaises conceptions. Je pense qu'il n'a pas vu venir l'industrialisation et sa puissance. Alors oui, actuellement, on voit beaucoup de clones et oui, ça se voit dans les FPS, jeux qui s'adressent à la catégorie qui consomme le plus de jeux vidéos : le mâle trentenaire sans enfant avec une profession intermédiaire ou supérieure.
Dans le même ordre d'idée, il parle beaucoup des sauvegardes, de la manière de faire pour que le jeu vieillisse bien, etc. Bref, des trucs de long terme. Mais ça ne peut plus marcher quand on veut sortir une version par an (avec un delta par rapport à l'année d'avant qui va du minimal au négligeable). Dans ce cas là, on s'en fout de bien gérer les sauvegardes, de toute façon, on en ressortira une version l'année suivante. Ça aussi ça vient de l'industrialisation massive : quelques gros titres tirent le reste des jeux qui marcheront moins bien. Mais sans ces gros titres, le reste aurait du mal à survivre. Pareil que dans le cinéma, ou dans la musique.
Donc, quand il dénonce tout ça, il a raison et tort. Raison quand on se place du point de vue d'un fan de jeu vidéo qui aimerait un peu plus de diversité, mais tort quand on examine les raisons économiques qui poussent à l'utilisation de ces clichés. Quand on développe un jeu amateur (et même indie), on doit écouter ces conseils, pour proposer autre chose, parce qu'on ne pourra jamais rivaliser avec un gros studio sur les clichés.
Au contraire, j'ai trouvé ces articles fort pertinents. L'exemple des caisses est vraiment caractéristique. Certes, c'est fondamental au gameplay, mais pourquoi une caisse ? Pourquoi pas un autre objet ? Tout simplement parce que la caisse est l'objet standard qu'on peut mettre partout, tellement standard que ça en devient ridicule parce que ça n'a souvent aucun intérêt dans le contexte d'avoir une caisse. Plutôt que de chercher quelque chose d'identique niveau forme mais avec une vraie raison, les game designers iront au plus vite.
J'ai beaucoup ri sur un des premiers qui décrit comment les RPG transforment souvent le joueur en marchand d'armes d'occasion. Typiquement ce qu'on retrouve dans beaucoup de MMORPG (et pourtant, l'article original date de 1998). Il y a beaucoup d'autres choses qui sont intéressantes quand on programme un jeu, pour éviter les erreurs. Quand on est joueur, effectivement, on ne se rend pas forcément compte de ce que ça peut représenter.
notamment avec cette histoire d'ombre qui m'a réjoui à la lecture (j'ai vu le cowboy marcher au soleil couchant).
pour l'instant, ça tient du rêve, mais ce n'est pas impossible ;) J'y travaillerai quand j'aurai bien avancé sur le reste.
Je voyais les « tuiles » comme des sprites qui une fois posés sur des ancres s'abuttent (s'il n'y a ni angle, ni offset). J'étais naïvement resté sur la composition de paysage pittoresque avec des petits villages de bric et de broc, ou de capitales avec des quartiers huppés construits en dur et tirés au cordeau avec de grandes allées à statues, contrastant avec des faubourgs plus authentiquement bordéliques, voire bidonvillesques.
En fait, si je comprends bien ce que tu dis, tu voudrais construire des cartes uniquement avec des sprites. C'est une idée très intéressante que j'ai déjà vu utilisé pour des sidescroller. L'avantage, c'est qu'on peut avoir des cartes superbes. L'inconvénient, c'est qu'il faut avoir tout un tas de sprite qui se coordonnent bien, qu'on peut redimensionner comme on veut, et que la construction de la carte est moins facilement automatisable.
Je n'avais pas même pensé aux visites d'intérieur, si ce n'est sous l'angle Zelda*, avec une vue « plan d'évacuation ISO machin bien carrée » décorrélée de l'extérieur (décalage de boussole en option ? moyen de faire des tipis ronds quand même… et des cloisons biscornues ? un must pour une bicoque de sorcière…).
Rien n'empêche d'avoir un jeu de tuiles spécifique pour des bâtiments uniques. Mais bon, ça ne compte pas ;)
Je me suis peut-être mal exprimé, je reprends. Tout d'abord, le jeu est en vue de haut (à la verticale), donc on ne voit vraiment que le haut. Ensuite, la carte est basée sur des tuiles, c'est-à-dire un ensemble prédéterminée de petits morceaux de cartes qu'on va assembler pour construire une grande carte. Et le problème il est bien là, c'est que si tu ne peux pas avoir une quantité monstrueuse de tuiles, pour tous les angles possibles, il faut faire des choix sur ce qui est possible, et dans mon cas, ça sera deux ou trois orientations pour le toit (et ça va déjà faire un paquet de tuiles à faire).
L'autre solution, ça aurait été de poser un sprite (une image) de toit, et là, on pouvait le placer comme on voulait, avec l'angle qu'on voulait. Mais d'un autre côté, il fallait faire correspondre exactement le toit et l'intérieur (sur une autre couche), ce qui n'est pas forcément évident à la main. Il y a également d'autres problèmes que je n'évoque pas. Bref, solution plus flexible mais solution plus complexe.
Merci ! C'est exactement le genre d'exemple que je cherchais. Où je vois donc qu'il a adopté Gettext (ouch, le fichier de 10000 lignes de traduction !), et les chaînes de format de Java (ça, plutôt normal).
Du coup, je me réponds à moi-même pour dire ce que je pense de ces articles. Je pense qu'ils sont tout à fait exact, et je pense que dès le début, je savais que je me lançais dans un projet assez grand. Mais comme je le sais, j'ai pris les devants. Premièrement, j'ai dit que je me donnais deux à trois ans pour finir le jeu, ce qui représente un temps considérable. Ce temps sera vraisemblablement partagé pour moitié dans le codage des mécaniques du jeu, et pour l'autre moitié (voire une très grosse moitié) dans la création de contenu (graphisme, quête, dialogue, etc). Deuxièmement, je prévois de générer un maximum de chose de manière aléatoire, notamment le fond de carte, ce qui va me faire gagner un temps considérable. Reste à trouver la bonne taille. Je retiens en tout cas ce conseil : sur chaque écran, il doit y avoir quelque chose d'intéressant.
D'une part parce que comme ça a déjà été souligné à plusieurs reprises, il y a une réduction des choix qui est en train de s'opérer de manière globale dans le monde libre (Linux, BSD) autour de quelques solutions, là où auparavant chacun avait sa solution soit-disant générique mais surtout maison. Ce qui fait qu'un développeur pourra bientôt fournir lui-même deux ou trois fichiers d'init pour les quelques solutions majeures, évitant une partie de ce travail à la distribution. D'autant que Gentoo a visiblement fait le même choix dont l'effort pourra être réparti.
D'autre part parce que c'est une nécessité. Systemd ne fonctionnera jamais sur autre chose que Linux, c'est un fait. Donc, il faut bien trouver une solution à l'échelle de Debian et avoir openrc pour tout le monde, qui pourtant semble être une bonne solution, isolerait Debian durablement des autres distributions. Le choix ne devrait se faire que sur cette base. Debian ne pratique pas le sondage pour décider si un paquet reste ou pas dans l'archive (heureusement !). Donc s'ils font le choix systemd+openrc, ils maintiendront ces deux solutions pour un très long moment.
Là par exemple, quoi que le ctte puisse décider, si quelqu'un maintient un paquet pour un système d'init supplémentaire et qu'il fonctionne, il ne se fera pas virer de Debian.
Je ne suis pas tout à fait d'accord. Le ou les systèmes d'init qui seront marqués comme officiels auront un impact sur tous les DD, en particulier devoir offrir systématiquement un fichier d'init au bon format quand il n'en existe pas. Pour un système d'init supplémentaire, ça ne sera pas le cas et ça relèvera de la bonne volonté des développeurs. C'est une grosse différence tout de même.
On peut le voir à l'heure actuelle avec systemd qui est dans les dépôts Debian, mais pour lequel tous les packages qui en ont besoin n'ont pas de fichier d'init au format systemd.
Donc, pour moi, la décision du ctte est plutôt engageante.
Choisir systemd+openrc me paraît être le choix le plus raisonnable : systemd est partout ailleurs (malheureusement), Gentoo ferait pareil, les variantes non-Linux pourrait avoir un init un peu plus moderne que l'actuel. Mais je crains que les intérêts personnels des membres du comité technique ne viennent jouer les trouble-fêtes.
D'ailleurs, j'ai toujours été étonné par cette instance bizarre au sein de Debian dont personne ne parle jamais mais qui a le réel pouvoir au sein de Debian et qui est tout sauf un truc démocratique. Ses membres sont cooptés, immuables, et en l'occurrence, pas vraiment impartiaux, notamment par rapport à Ubuntu. Bref, on parle souvent du DPL, mais le ctte, c'est le vrai cœur de Debian, c'est là que sont prises les vraies décisions.
Quand tu es programmeur dans le monde réel, l'ISO te semble bien loin.
Tu sais que C, C++, Ada, Fortran, une bonne partie d'Unicode, PDF (1.5), pour ne citer que les plus connus, sont des normes ISO.
En plus pour le coup, ton argument tombe à plat: ajouter l'encodage cp1252, c'est un truc que tu fais une fois dans la vie de la bibliothèque, ça ne bouge plus jamais. Les string C++ ayant déjà de quoi gérer les conversions vers l'UTF8, UTF16, UTF32, UCS2 et UCS4, c'est pas dur de rajouter d'autres encodings.
Non mais je vais le dire plus clairement : cp1252 ne sera jamais dans C++, sois en bien certain. Parce que déjà, il y aurait des encodings à considérer avant (notamment les encodings utilisés en Asie), et que de toute façon, étant un encoding propriétaire et pas ISO, il ne pourra jamais faire partie d'une norme ISO, c'est aussi simple que ça. Donc, il ne sera jamais dans C++. Ce n'est pas le rôle de C++ d'être exhaustif, c'est le rôle de bibliothèques externes. Donc, rien à voir avec Python notamment, qui n'est pas normalisé et où les gens font bien ce qu'ils veulent.
Ha mais oui, mais non ! En fait, je pensais que tu signalais que les en-têtes n'apparaissaient pas mais en fait, ils apparaissent dans la news mais pas dans ton message. Bon, du coup, je crois que je vais sortir.
à l'origine, c'était filesystem et networking mis entre chevrons, comme pour les autres en-têtes C++, mais je crois qu'il a pris ça pour des balises… :/
Est-ce que llvm propose un moyen de mélanger des langages et de faciliter l'usage de code déjà existant codé dans autre chose ?
Pas plus que le C ou la JVM (chacun dans leur style). C'est-à-dire qu'on pourrait imaginer tout un tas de langages qui compilent vers le langage LLVM qui sert de représentation intermédiaire dans le compilateur. Mais comme tu le dis, on aura sans doute des conventions de nommage à gérer et des conventions d'appels (même si LLVM sait gérer les conventions d'appel).
Je pense que si tu voulais ce genre de chose, il faudrait spécifier un peu plus que le langage, il faudrait aller plus loin. Faire un peu ce que MS a essayé de faire avec dotNet.
Oui, et avec l'ajout de make_unique en C++14, on pourra désormais se passer de tous les new et les delete sans aucun souci, tout sera géré automatiquement.
Rien pour cp1252 en natif cependant, ils ont jamais du ouvrir un terminal sur un Windows XP français.
C'est surtout que UTF8 et ses copains sont aussi des normes ISO, donc on peut y faire référence dans une norme ISO. Tandis que cp1252 n'est pas une norme ISO.
Mais bon, tout ça n'aura pas été inutile, j'ai découvert l'opérateur ""(). Je suis sur qu'en plus de me faire loucher, il doit pouvoir faire des tas de trucs désagréables dans un programme.
Il peut aussi faire des trucs très sympas. J'en parlerai dans un prochain épisode de ma série de création d'un jeu vidéo.
Sinon, si tu veux voir ce qu'est une string qui fonctionne pour des applications
Je vois bien ce que c'est, mais c'est aussi du boulot de maintenir une telle bibliothèque, et au delà de ça d'avoir un truc compatible avec tout Unicode.
En fait, en cherchant, j'ai trouvé une piste qui m'a mené sur une liste de discussion sur laquelle on peut lire un des derniers compte-rendu officiel où tout est plutôt bien décrit. Mais les discussions sur la liste sont assez contradictoires, entre ceux qui espèrent une API 2D à la Cairo/Qt/Skia, et ceux qui espèrent une API plutôt simple à la SDL/SFML, avec gestion des inputs (d'ailleurs, apparemment, les responsables voulaient contacter le dev de SFML). Bref, c'est encore flou pour l'instant. Perso, les deux API me plairait en standard, mais je pense qu'il ne faut pas les mélanger.
# Changements de syntaxe
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles sur Rust à l’occasion de la 0.9. Évalué à 9.
Il n'y a que moi qui trouve inquiétant qu'un langage qui est en développement depuis plusieurs années et qui s'approche de la version finale à grand pas soit aussi instable au niveau de sa syntaxe ? (et pas uniquement sur des détails en plus). Moi, quand on vient me dire qu'on peut commencer à tester, je fuis immédiatement, parce que je me dis que ce langage risque d'évoluer suffisamment pour que tout ce que j'apprends et je fais soit obsolète dans deux mois… Enfin, c'est l'impression que ça me donne.
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 2.
Le leveling (dans le bon sens du terme) n'est pas sans intérêt, au contraire, il permet au joueur de mesurer sa progression.
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 7.
Je ne pense pas qu'il dise que c'est mauvais comme gameplay, il dit simplement que le game designer n'a pas fait beaucoup d'effort pour imaginer autre chose que le cliché. Maintenant, il pourrait évoquer le pourquoi (c'est-à-dire pourquoi on voit sans cesse les mêmes clichés), et il l'effleure à peine à deux moments dans la suite de la série. Premièrement quand il parle du turnover, deuxièmement quand il parle des FPS qui sont les nouveaux sidescroller.
Son discours est de dire qu'à cause du turnover, il n'y a pas de mémoire et donc, les game designers refont toujours les mêmes bêtises (ce qui est discutable). Et ensuite, il dit que c'est dans les FPS qu'on retrouve la plupart de ce qu'il dénonce et que ce sont les nouveaux sidescroller, sous-entendu il en existe une tétrachiée qui se ressemblent tous comme les sidescrollers dans les années 90. À mon sens, il analyse bien la conséquence mais il ne voit pas la vraie cause qui est l'industrialisation massive du jeu vidéo. Quand il commence sa série, les «gros» studios sont des nains composés de pionniers, avec une technologie très changeante. Aujourd'hui, on a des entreprises énormes, une industrie qui surpasse le cinéma et la musique, des milliards de brouzoufs à engranger ou à perdre. Donc, comme pour le cinéma, on fait ce qui marche et donc, on ne s'écarte pas trop des clichés et de ce qu'il considère comme des mauvaises conceptions. Je pense qu'il n'a pas vu venir l'industrialisation et sa puissance. Alors oui, actuellement, on voit beaucoup de clones et oui, ça se voit dans les FPS, jeux qui s'adressent à la catégorie qui consomme le plus de jeux vidéos : le mâle trentenaire sans enfant avec une profession intermédiaire ou supérieure.
Dans le même ordre d'idée, il parle beaucoup des sauvegardes, de la manière de faire pour que le jeu vieillisse bien, etc. Bref, des trucs de long terme. Mais ça ne peut plus marcher quand on veut sortir une version par an (avec un delta par rapport à l'année d'avant qui va du minimal au négligeable). Dans ce cas là, on s'en fout de bien gérer les sauvegardes, de toute façon, on en ressortira une version l'année suivante. Ça aussi ça vient de l'industrialisation massive : quelques gros titres tirent le reste des jeux qui marcheront moins bien. Mais sans ces gros titres, le reste aurait du mal à survivre. Pareil que dans le cinéma, ou dans la musique.
Donc, quand il dénonce tout ça, il a raison et tort. Raison quand on se place du point de vue d'un fan de jeu vidéo qui aimerait un peu plus de diversité, mais tort quand on examine les raisons économiques qui poussent à l'utilisation de ces clichés. Quand on développe un jeu amateur (et même indie), on doit écouter ces conseils, pour proposer autre chose, parce qu'on ne pourra jamais rivaliser avec un gros studio sur les clichés.
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 3.
Au contraire, j'ai trouvé ces articles fort pertinents. L'exemple des caisses est vraiment caractéristique. Certes, c'est fondamental au gameplay, mais pourquoi une caisse ? Pourquoi pas un autre objet ? Tout simplement parce que la caisse est l'objet standard qu'on peut mettre partout, tellement standard que ça en devient ridicule parce que ça n'a souvent aucun intérêt dans le contexte d'avoir une caisse. Plutôt que de chercher quelque chose d'identique niveau forme mais avec une vraie raison, les game designers iront au plus vite.
J'ai beaucoup ri sur un des premiers qui décrit comment les RPG transforment souvent le joueur en marchand d'armes d'occasion. Typiquement ce qu'on retrouve dans beaucoup de MMORPG (et pourtant, l'article original date de 1998). Il y a beaucoup d'autres choses qui sont intéressantes quand on programme un jeu, pour éviter les erreurs. Quand on est joueur, effectivement, on ne se rend pas forcément compte de ce que ça peut représenter.
[^] # Re: pour les (toits des) maisons
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 2.
pour l'instant, ça tient du rêve, mais ce n'est pas impossible ;) J'y travaillerai quand j'aurai bien avancé sur le reste.
En fait, si je comprends bien ce que tu dis, tu voudrais construire des cartes uniquement avec des sprites. C'est une idée très intéressante que j'ai déjà vu utilisé pour des sidescroller. L'avantage, c'est qu'on peut avoir des cartes superbes. L'inconvénient, c'est qu'il faut avoir tout un tas de sprite qui se coordonnent bien, qu'on peut redimensionner comme on veut, et que la construction de la carte est moins facilement automatisable.
Rien n'empêche d'avoir un jeu de tuiles spécifique pour des bâtiments uniques. Mais bon, ça ne compte pas ;)
[^] # Re: pour les (toits des) maisons
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 4.
Je me suis peut-être mal exprimé, je reprends. Tout d'abord, le jeu est en vue de haut (à la verticale), donc on ne voit vraiment que le haut. Ensuite, la carte est basée sur des tuiles, c'est-à-dire un ensemble prédéterminée de petits morceaux de cartes qu'on va assembler pour construire une grande carte. Et le problème il est bien là, c'est que si tu ne peux pas avoir une quantité monstrueuse de tuiles, pour tous les angles possibles, il faut faire des choix sur ce qui est possible, et dans mon cas, ça sera deux ou trois orientations pour le toit (et ça va déjà faire un paquet de tuiles à faire).
L'autre solution, ça aurait été de poser un sprite (une image) de toit, et là, on pouvait le placer comme on voulait, avec l'angle qu'on voulait. Mais d'un autre côté, il fallait faire correspondre exactement le toit et l'intérieur (sur une autre couche), ce qui n'est pas forcément évident à la main. Il y a également d'autres problèmes que je n'évoque pas. Bref, solution plus flexible mais solution plus complexe.
[^] # Re: Génération automatique de cartes
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 4.
Sans dévoiler de grands secrets, mes sources actuelles d'inspiration sont :
Je vais aller voir tes références pour ajouter des sources d'inspiration.
[^] # Re: Dialogues
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 3.
Merci ! C'est exactement le genre d'exemple que je cherchais. Où je vois donc qu'il a adopté Gettext (ouch, le fichier de 10000 lignes de traduction !), et les chaînes de format de Java (ça, plutôt normal).
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 2.
Du coup, je me réponds à moi-même pour dire ce que je pense de ces articles. Je pense qu'ils sont tout à fait exact, et je pense que dès le début, je savais que je me lançais dans un projet assez grand. Mais comme je le sais, j'ai pris les devants. Premièrement, j'ai dit que je me donnais deux à trois ans pour finir le jeu, ce qui représente un temps considérable. Ce temps sera vraisemblablement partagé pour moitié dans le codage des mécaniques du jeu, et pour l'autre moitié (voire une très grosse moitié) dans la création de contenu (graphisme, quête, dialogue, etc). Deuxièmement, je prévois de générer un maximum de chose de manière aléatoire, notamment le fond de carte, ce qui va me faire gagner un temps considérable. Reste à trouver la bonne taille. Je retiens en tout cas ce conseil : sur chaque écran, il doit y avoir quelque chose d'intéressant.
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. Évalué à 2.
Merci pour les références, je vais les lire avec attention vu que ça me concerne assez directement ;)
[^] # Re: OpenRC
Posté par rewind (Mastodon) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
Oui et non.
D'une part parce que comme ça a déjà été souligné à plusieurs reprises, il y a une réduction des choix qui est en train de s'opérer de manière globale dans le monde libre (Linux, BSD) autour de quelques solutions, là où auparavant chacun avait sa solution soit-disant générique mais surtout maison. Ce qui fait qu'un développeur pourra bientôt fournir lui-même deux ou trois fichiers d'init pour les quelques solutions majeures, évitant une partie de ce travail à la distribution. D'autant que Gentoo a visiblement fait le même choix dont l'effort pourra être réparti.
D'autre part parce que c'est une nécessité. Systemd ne fonctionnera jamais sur autre chose que Linux, c'est un fait. Donc, il faut bien trouver une solution à l'échelle de Debian et avoir openrc pour tout le monde, qui pourtant semble être une bonne solution, isolerait Debian durablement des autres distributions. Le choix ne devrait se faire que sur cette base. Debian ne pratique pas le sondage pour décider si un paquet reste ou pas dans l'archive (heureusement !). Donc s'ils font le choix systemd+openrc, ils maintiendront ces deux solutions pour un très long moment.
[^] # Re: OpenRC
Posté par rewind (Mastodon) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
Je ne suis pas tout à fait d'accord. Le ou les systèmes d'init qui seront marqués comme officiels auront un impact sur tous les DD, en particulier devoir offrir systématiquement un fichier d'init au bon format quand il n'en existe pas. Pour un système d'init supplémentaire, ça ne sera pas le cas et ça relèvera de la bonne volonté des développeurs. C'est une grosse différence tout de même.
On peut le voir à l'heure actuelle avec systemd qui est dans les dépôts Debian, mais pour lequel tous les packages qui en ont besoin n'ont pas de fichier d'init au format systemd.
Donc, pour moi, la décision du ctte est plutôt engageante.
[^] # Re: Faut pas le prendre mal
Posté par rewind (Mastodon) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 8.
Ce qui est le plus déprimant, c'est un journal technique où tu as passé du temps et où il n'y a aucun commentaire
[^] # Re: OpenRC
Posté par rewind (Mastodon) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
Choisir systemd+openrc me paraît être le choix le plus raisonnable : systemd est partout ailleurs (malheureusement), Gentoo ferait pareil, les variantes non-Linux pourrait avoir un init un peu plus moderne que l'actuel. Mais je crains que les intérêts personnels des membres du comité technique ne viennent jouer les trouble-fêtes.
D'ailleurs, j'ai toujours été étonné par cette instance bizarre au sein de Debian dont personne ne parle jamais mais qui a le réel pouvoir au sein de Debian et qui est tout sauf un truc démocratique. Ses membres sont cooptés, immuables, et en l'occurrence, pas vraiment impartiaux, notamment par rapport à Ubuntu. Bref, on parle souvent du DPL, mais le ctte, c'est le vrai cœur de Debian, c'est là que sont prises les vraies décisions.
[^] # Re: Faut pas le prendre mal
Posté par rewind (Mastodon) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 3.
Tout le monde s'accorde depuis pas mal de temps sur ce qu'on appelle licence MIT… Ceci dit, elle n'a pas 5 paragraphes, seulement 3.
# Restroshare
Posté par rewind (Mastodon) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 3. Dernière modification le 17 janvier 2014 à 11:56.
Comment ça se compare avec Retroshare ?
edit: grillé…
[^] # Re: Qt > Gtk
Posté par rewind (Mastodon) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 1.
Format propriétaire
[^] # Re: Qt > Gtk
Posté par rewind (Mastodon) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 4.
Tu sais que C, C++, Ada, Fortran, une bonne partie d'Unicode, PDF (1.5), pour ne citer que les plus connus, sont des normes ISO.
Non mais je vais le dire plus clairement : cp1252 ne sera jamais dans C++, sois en bien certain. Parce que déjà, il y aurait des encodings à considérer avant (notamment les encodings utilisés en Asie), et que de toute façon, étant un encoding propriétaire et pas ISO, il ne pourra jamais faire partie d'une norme ISO, c'est aussi simple que ça. Donc, il ne sera jamais dans C++. Ce n'est pas le rôle de C++ d'être exhaustif, c'est le rôle de bibliothèques externes. Donc, rien à voir avec Python notamment, qui n'est pas normalisé et où les gens font bien ce qu'ils veulent.
[^] # Re: Autre fôtes
Posté par rewind (Mastodon) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 2.
Ha mais oui, mais non ! En fait, je pensais que tu signalais que les en-têtes n'apparaissaient pas mais en fait, ils apparaissent dans la news mais pas dans ton message. Bon, du coup, je crois que je vais sortir.
[^] # Re: Autre fôtes
Posté par rewind (Mastodon) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 1.
à l'origine, c'était
filesystemetnetworkingmis entre chevrons, comme pour les autres en-têtes C++, mais je crois qu'il a pris ça pour des balises… :/[^] # Re: Simplification d'appel de la lib ?
Posté par rewind (Mastodon) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 7.
Je pense que ça devait être un peu plus subtil que remplacer en bourrin tous les appels à exit en return…
[^] # Re: mélange de langage ?
Posté par rewind (Mastodon) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 5.
Pas plus que le C ou la JVM (chacun dans leur style). C'est-à-dire qu'on pourrait imaginer tout un tas de langages qui compilent vers le langage LLVM qui sert de représentation intermédiaire dans le compilateur. Mais comme tu le dis, on aura sans doute des conventions de nommage à gérer et des conventions d'appels (même si LLVM sait gérer les conventions d'appel).
Je pense que si tu voulais ce genre de chose, il faudrait spécifier un peu plus que le langage, il faudrait aller plus loin. Faire un peu ce que MS a essayé de faire avec dotNet.
[^] # Re: Bindings
Posté par rewind (Mastodon) . En réponse à la dépêche Gtk to Qt - A strange journey. Évalué à 4.
Oui, et avec l'ajout de
make_uniqueen C++14, on pourra désormais se passer de tous lesnewet lesdeletesans aucun souci, tout sera géré automatiquement.[^] # Re: Qt > Gtk
Posté par rewind (Mastodon) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 2.
C'est surtout que UTF8 et ses copains sont aussi des normes ISO, donc on peut y faire référence dans une norme ISO. Tandis que cp1252 n'est pas une norme ISO.
Il peut aussi faire des trucs très sympas. J'en parlerai dans un prochain épisode de ma série de création d'un jeu vidéo.
Je vois bien ce que c'est, mais c'est aussi du boulot de maintenir une telle bibliothèque, et au delà de ça d'avoir un truc compatible avec tout Unicode.
[^] # Re: Qt > Gtk
Posté par rewind (Mastodon) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 2. Dernière modification le 14 janvier 2014 à 00:45.
En fait, en cherchant, j'ai trouvé une piste qui m'a mené sur une liste de discussion sur laquelle on peut lire un des derniers compte-rendu officiel où tout est plutôt bien décrit. Mais les discussions sur la liste sont assez contradictoires, entre ceux qui espèrent une API 2D à la Cairo/Qt/Skia, et ceux qui espèrent une API plutôt simple à la SDL/SFML, avec gestion des inputs (d'ailleurs, apparemment, les responsables voulaient contacter le dev de SFML). Bref, c'est encore flou pour l'instant. Perso, les deux API me plairait en standard, mais je pense qu'il ne faut pas les mélanger.