J’avais quelques objectifs en me lançant dans le retrogaming : 1/ Jouer sur la télé 2/ Avec des manettes de qualité, idéalement en Bluetooth 3/ Limiter les coûts 4/ Pouvoir jouer à Mario Kart. Rétrospectivement il fallait aussi que la solution séduise mon fils, qu’elle soit fiable/robuste (pas de bug/lag ni lourdeur niveau configuration ou mise à jour) avec une interface efficace (surtout simple, pilotable par un enfant). Quelque part je cherchais le confort et la qualité d’une « vraie » console. À date je suis très satisfait, débutons cette série Retrogaming par le choix de la distribution.

Distributions retrogaming

4 solutions ressortent : Recalbox (GitLab), Batocera.linux (GitHub), RetroPie (GitHub), Lakka (GitHub). Quelques autres solutions existent, probablement vouées à disparaître, écrasées par ces projets plus anciens/visibles/utilisés/développés/soutenus/documentés.

Si vous débutez dans le monde du retrogaming, prenez Recalbox, la Ubuntu des distribs retrogaming. La version 9 vient de sortir, importante communauté française, la meilleure interface (la plus intuitive/simple, en Français), excellente documentation (nombreuses langues dont Français), beaucoup de tutos/vidéos, bonne visibilité, développement soutenu (une grosse release avec éventuellement des releases correctives chaque année), Kodi préinstallé.

Batocera.linux (fork de Recalbox) est plus technique/pointue/performante et conviendra davantage aux utilisateurs exigeants. De nombreuses releases (plusieurs par an), une documentation passable (en Anglais), activement soutenue/défendue par les connaisseurs, Kodi préinstallé. Mon second choix.

Le positionnement de RetroPie est particulier : Un outil/paquet qui vient AU-DESSUS d’une distribution (typiquement Raspberry Pi OS/Debian/Ubuntu) : « Shell script to set up a Raspberry Pi/Odroid/PC with RetroArch emulator and various cores ». Ils fournissent des images SEULEMENT pour Raspberry Pi (exit PC, Odroid et autres minimachines) permettant de booter directement sur RetroPie. Si vous souhaitez l’utiliser sur un PC il faudra donc installer un système d’exploitation puis lancer le script. De mon point de vue RetroPie est beaucoup utilisée comme une bibliothèque de jeux retro sur PC. Belle visibilité (notamment 9.7k Stars GitHub), releases au ralenti, documentation passable (en Anglais).

Lakka est « the official Linux distribution of RetroArch and the libretro ecosystem », la documentation est passable (en Anglais), nombreuses releases, à connaître/surveiller car elle monte en puissance propulsée par libretro (visibilité/communauté).

Lakka est une distribution légère (basée sur LibreELEC) avec libretro (RetroArch) derrière => écosystème entier. RetroPie permet de tester/jouer directement en quelques minutes depuis son PC, je pense que cet usage est plébiscité davantage que le côté distribution Linux. Batocera.linux gagne en popularité auprès des connaisseurs et des possesseurs de Steam Deck. Recalbox fait un gros travail de démocratisation (communication, vidéos et documentation) pour rendre l’approche du retrogaming simple/accessible au plus grand nombre.

Choix

J’ai à peine regardé Lakka, je la surveille surtout. Je ne voulais pas de RetroPie, trop éloignée d’une vraie/simple distribution Linux installable partout (hors de question pour moi de maintenir un système d’exploitation en-dessous), je l’ai testé sur mon PC fixe. Batocera.linux ne m’a pas convaincu malgré un test, je vous invite à lui donner sa chance. J’ai commencé à creuser Recalbox plus accessible (documentation/forum/vidéos en Français, bonne interface) sur laquelle je suis resté et qui possède de grandes qualités (et de gros défauts que nous verrons dans un prochain article).

Le retrogaming est un sujet complexe et pointu que les solutions présentées dans cet article tentent de rendre plus accessible/simple. Si vous n’êtes pas un passionné de retrogaming, si vous n’êtes pas à l’aise avec l’Anglais, si vous n’avez pas une bonne aisance/connaissance de Linux, je vous invite fortement à débuter par Recalbox au risque de vous dégoûter du retrogaming. La première marche est souvent la plus difficile, il vaut mieux qu’elle soit basse pour ne pas trébucher.

Nous parlerons Machines dans le prochain article, le nerf de la guerre pour profiter des jeux.

Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Original post of Comète.Votez pour ce billet sur Planet Libre.

Courant mars, l’Assemblée nationale va se prononcer sur le projet de loi relatif aux Jeux olympiques et paralympiques, déjà adopté par le Sénat.

En son sein, l’article 7 vise à autoriser la vidéosurveillance automatisée (VSA), cet outil de surveillance biométrique qui, à travers des algorithmes couplés aux caméras de surveillance, détecte, analyse et classe nos corps et comportements dans l’espace public. Il s’agit d’un changement d’échelle sans précédent dans les capacités de surveillance et de répression de l’État et de sa police.

Accès au site

Original post of Simon Vieille.Votez pour ce billet sur Planet Libre.

Sujet récurrent du monde des systèmes d’information (SI), les mises en production impactent fortement l’entreprise et sa capacité à faire évoluer son SI, en particulier ses services en ligne. La révolution d’internet a rendu les mises en production critiques pour tous les services fonctionnant en continu et nécessitant des arrêts de service réduits au minimum . Nous étudierons dans cette série d’articles le cas spécifique des mises en production le vendredi, un débat récurrent chaque semaine sur les réseaux sociaux de la communauté tech.

Nous étudierons trois cas spécifiques de structure de SI et d’entreprise, mais ces trois cas auront tous en commun de concerner des entreprises qui offrent des services en ligne critiques (24×7, services rapportant beaucoup d’argent à l’entreprise et/ou vitales pour son image) pour le fonctionnement de l’entreprise, le cas des structures hébergeant des services non-critiques ne nous intéressant pas.

L’entreprise pas ou peu agile sans CI/CD

Le premier cas étudié sera celui d’une entreprise peu ou pas agile dans le développement, s’étant habituée à délivrer son logiciel à date à peu près fixe dans l’année, par exemple une fois tous les deux mois. Chaque version inclut de nombreux changements. Chaque mise en production nécessite les paramètres suivants :

• une nouvelle version du code prévue pour fonctionner sur la production.
• une infrastructure prête à accueillir les nouveaux paramètres de la nouvelle version déployée (base de données, cache,…).
• un référent capable de comprendre comment va fonctionner le code en production, on l’appellera le développeur.
• un administrateur système qui va déposer le code en production et redémarrer les services concernés.

Il est important de noter que, de par le manque de CI/CD permettant de déployer automatiquement une nouvelle version du code, chaque mise en production est, dans ce type d’entreprise, un processus majoritairement manuel avec les risques inhérents que cela implique, à savoir les erreurs humaines.

Les détails de la mise en production

Dans notre exemple, pour le déploiement du mois d’avril, la date correspond à un vendredi. Une période d’indisponibilité est estimée à une heure. Elle aura lieu tôt le matin, où le pic de trafic est le plus faible. Le jour venu, le développeur et le sysadmin travaillent ensemble afin de créer la base de données manquante et redémarrer les services applicatifs concernés par la nouvelle version du code. Suite à la mise en production, des tests fonctionnels sont effectués manuellement par le développeur.

À 16h, des problèmes sont remontés par les exploitants de l’application. Le développeur et le sysadmin essaient de comprendre, un patch est livré en urgence et réinstallé sur l’infrastructure. Il est 19h, tout le monde est épuisé, dès que les tests manuels basiques passent, tout le monde rentre précipitamment chez soi. Le sysadmin part en vacances à l’étranger pour le week-end et attrape son avion in-extremis.

Le début des ennuis de la mise en production le vendredi

Samedi à 4h du matin, des processus applicatifs sont automatiquement exécutés et retournent des erreurs, des tables ne sont pas mises à jour à cause de ces erreurs et le site web tombe quelques minutes plus tard, car les données générées par les batchs ont un format qui ne correspond plus à celui attendu par la nouvelle base créée vendredi.

À 16h samedi, un manager de l’entreprise tente d’accéder à un des services lors d’une utilisation personnelle. Il se rend compte que le site web est devenu injoignable. Il tente de joindre immédiatement le sysadmin, mais le téléphone portable de ce dernier ne répond pas. En effet ce dernier est en week-end à l’étranger.

Le plus haut niveau est escaladé et le chef de l’entreprise réussit finalement à joindre le développeur sur son téléphone personnel. Ce dernier n’est pas à l’aise avec l’administration système et n’a pas les droits nécessaires lui-même à régler la situation.

Dimanche à 17h, le sysadmin de retour de son week-end, voit les nombreux messages et joint le développeur. Les deux réussissent à relancer l’application dimanche à 19h.

Le post-mortem de cette mise en production le vendredi

• La mise en production a bien eu lieu le vendredi, mais une partie a été oubliée : les batchs applicatifs du samedi.
• Un premier problème en fin de journée le vendredi a déjà fatigué l’équipe technique.
• L’indisponibilité des personnes à même de régler le problème a engendré une indisponibilité du service pendant 39 heures.
• L’absence d’une astreinte réelle et bien organisée a entraîné la prise en charge tardive du problème.

Conclusion

Ce premier article sur la mise en production du vendredi montre un cas courant d’incident dans une entreprise peu ou pas agile pour laquelle les mises en production représentent toujours aujourd’hui un problème. L’absence de CI/CD rend pénible et épuisante les livraisons logicielles en production. Aucun référent bien identifié n’était disponible et les personnes mobilisées l’ont été de manière informelle, aucune astreinte réelle n’ayant été mise en place.

Il s’agit bien sûr d’un exemple et toutes les variations sont envisageables. Le sysadmin peut ne pas partir en vacances, le développeur aurait pu anticiper les batchs… Et c’est d’ailleurs ce qui arrive le plus souvent, on arrive à mener à bout sans incident une mise en production le vendredi. Mais dans le modèle présenté aujourd’hui, les événements et les circonstances ont entraîné une indisponibilité inacceptable pour l’entreprise. Des mesures de corrections devront être prises pour éviter de le renouveler.

Dans cette situation bien précise qui représente la réalité de l’organisation et de l’état de l’art du SI de l’entreprise, interdire les mises en production le vendredi permettrait d’éviter une rupture de service aussi longue à l’avenir, tant que des améliorations décisives n’ont pas été apportées, le évolutions d’un SI demandant une volonté politique en interne et des investissement qu’il est parfois très difficile d’obtenir.

Dans le prochain article, nous étudierons le cas d’une entreprise agile dans le développement de ses applications sans astreinte.

Me suivre sur les réseaux sociaux

Carl Chenet, architecte infrastructure. N’hésitez pas à me suivre directement sur mes différents sociaux :

• Mastodon : @carlchenet
• Twitter : @carl_chenet

The post Les mises en production le vendredi (1/3) appeared first on Carl Chenet's Blog.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

Bonjour,

Bab, darkjam, d52fr et moi sommes heureux de vous présenter le numéro 189, celui de janvier 2023, en français. Il est, bien entendu, disponible sur notre page NUMÉROS ou vous pouvez le télécharger directement en cliquant sur la photo de couverture ci-dessous.

Comme vous pouvez le constater, Il y a une nouvelle série, écrite par Ronnie lui-même, sur l'utilisation de FreeCAD. En fait, puisque notre rédacteur en chef a une nouvelle imprimante 3D, il veut pouvoir créer ses propres objets et nous fait profiter de ses premiers pas avec cette application. Ce mois-ci, il y a pas mal d'autres tutoriels aussi : Python, LaTeX, et Inkscape. De plus, Alan Ward revient au FCM pour nous démontrer comment installer des disques durs multiples pour pouvoir faire des sauvegardes en miroir ou en striping. Difficile, mais utile aussi.

Outre les tutoriels, il y a des critiques : celle de Lubuntu 22.10 par Alan Ward, qui recommence sa présentation de toutes les Ubuntu dites intermédiaires, et celle de Zorin OS pro 16.1, qui est un système d'exploitation payant que Erik voulait examiner. Ses conclusions sont un peu mitigées, mais il semble qu'il y ait beaucoup de bien dans cet OS pour des débutants sous Linux venant de Windows ou de macOS. Il est également question d'un nouveau livre sur Python : « Python for Kids » de Jason R. Briggs que Greg Walters trouve véritablement formidable. Bien entendu, nous avons droit à la présentation d'un jeu, IXION, qui a beaucoup plu a Erik.

À part tout cela, Erik a écrit C&C, contribué deux dessins, donné son opinion sur les jeux sous Linux et répondu aux questions des lecteurs dans Q. ET R. J'ai l'impression que, sans Erik, il n'y aurait pas de magazine... N'oubliez pas que vous aussi, vous pouvez écrire pour le FCM !

En vous souhaitant à nouveau une excellente 2023,

Bab, scribeur et relecteur, darkjam, traducteur, d52fr, traducteur et relecteur et moi, AE, relectrice.

Original post of Full Circle Magazine FR.Votez pour ce billet sur Planet Libre.