Pour ceux que ça intéresse, voici GNU dmd, un système de démarrage universel et de gestion de services conçu pour les systèmes POSIX, qui reprend le meilleur de SysV-init et de systemd :
Maintenant qu'une solution sérieuse est en cours d'élaboration pour remplacer le (très) vieillissant SysV-init et le (très) monolithique systemd, qu'on ne vienne plus me parler des avantages/inconvénients de l'un ou de l'autre. C'est une solution propre, simple, respectueuse des principes de base des *NIX et performante.
A ce moment là pourquoi est-ce qu'on n'intègre pas l'UEFI + le bootloader + l'init + le login ? Histoire d'avoir des machines aussi fermées que les smartphones ? (sinon plus) Parce que bon, il suffit d'ajouter l'UEFI dans 'systemd' est on y est hein…
Des PC où tout serait verrouillé de l'UEFI jusqu'au bureau ? Microsoft l'a rêvé, Red Hat l'a (bientôt) fait.
Je ne suis pas fondamentalement contre le fait d'avoir un logiciel qui nous permette d'intégrer absolument toute la chaîne de démarrage de A à Z dans un logiciel monolithique (on a beau séparer les binaires, ils sont quand même tous dépendants les uns des autres). Ca peut avoir une vraie utilité pour tout un tas de personnes ou d'entreprises.
Mais mettre ce système par défaut dans quasiment toutes les distributions et donc aller à l'encontre des principes de base qui ont fait le succès des *NIX, je trouve ça aberrant. Je suis convaincu que toutes les distributions qui adoptent 'systemd' sont en train de se tirer une balle dans le pied à long terme.
Dire que systemd est pourri, c’est remettre en question les compétences de tous ceux qui ont choisi systemd, à savoir à peu près toutes les distributions sauf Slackware et Gentoo par défaut.
1) Malgré ça, on assiste à des développeurs Debian officiels qui créent un fork ;
2) "Ce n'est pas parce qu'ils sont une majorité à avoir tort qu'ils ont raison", pour reprendre Coluche. Entendre par là : je tiens à me faire ma propre opinion, même si le meilleur programmeur du monde me dit que j'ai tort, car c'est comme ça que je comprendrai pourquoi j'ai tort (ou lui éventuellement, ça arrive…).
Tout comme systemd n'a pas grand chose à voir avec une des règles de base d'UNIX malheureusement, à savoir la séparation de tâches simples en briques logicielles indépendantes.
La stagnation, c'est l'avenir !
J'ai dit "Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures". Pas "Maintenons le statu quo". Parfois, oui, il vaut mieux refuser certaines évolutions qui en réalité amènent autant de problèmes qu'elles n'en résolvent. Ce qui ne veut pas dire qu'il ne faille rien faire pour améliorer par exemple OpenRC.
Change vite d'OS, ça fait plus de vingt ans que Linux (le *NIX majoritaire depuis 15 ans au moins) utilise un gros noyau monolithique.
C'était même tellement bien qu'on a été obligé de créer une v2 de Linux pour y ajouter des modules.
Pas vraiment. D'abord, pour avoir systemd il faut linux. Aussi, systemd aurait été plus difficile avec 16 Kio de mémoire (la taille de la mémoire vive du premier IBM PC), AMHA.
C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.
Lesquelles ?
Ca fait 3 fois que je l'écris dans ce fil mais je vais le redire : séparer des tâches en briques logicielles indépendantes. C'est un des concepts de base de la programmation système sous les *NIX, j'en veux pour référence cet excellent ouvrage : http://www.oreilly.com/openbook/linuxdrive3/book/
Les vielles recettes puent. Quand on copie/colle du code shell mal fichue pendant 40 ans plutôt que d'arrêter de re-faire le même boulot des milliers de fois :
1) soit on a la foi
2) soit on est stupide
Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).
Et c'est parce qu'on sait quand savoir évoluer, qu'on a eu bien d'autres systemd-like avant systemd (qui ne fait que réunir le meilleur des systemd-like qui sont apparus avant lui).
Par évolution, j'entendrais quelque chose comme "contribuer à l'existant pour le rendre vraiment meilleur", plutôt que de prendre plein de fonctionnalités et de les agréger en un ensemble de briques pas indépendantes qu'on aura entièrement recodées. Plutôt que de faire un peu de vérification de système de fichiers + un peu de parefeu + un peu de ceci et un peu de cela, systemd ferait bien de ne faire que l'initialisation. Ou s'il veut tout faire, qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.
Pour le point 2, OpenRC peut être plus rapide au démarrage que systemd.
Pour le point 3, je suis totalement d'accord et je n'ai jamais compris pourquoi on avait conçu des trucs aussi compliqué pour lancer des choses simples.
Je parle de faire tourner les choses proprement pour qu'on puisse continuer à avoir un système fiable et performant. Linus Torvald est du genre à passer une nuit sur une fonction appelée 1 fois par jour pour gagner 5 cycles microprocesseur, son argument étant de dire que 5 cycles CPU x des millions de machines, ça fait beaucoup d'énergie économisée. C'est cette approche que j'aimerais voir dans les distributions.
Lennart Pottering est bien loin de cet état d'esprit selon moi, sinon il aurait contribué à des systèmes de démarrage existants en vue de les améliorer (je pense à OpenRC qui n'est pas parfait mais qui se rapproche de ce que 'systemd' sait faire, et pour le coup de manière propre, intelligente et compatible UNIX).
Tout comme ça serait sûrement très pratique que 'systemd' fasse le café.
Est-ce intelligent pour autant ? Non.
Ce n'est pas parce qu'on peut le faire qu'on doit le faire.
Visiblement certains semblent oublier pourquoi les *NIX ont réussi à devenir des OS de référence et à tenir la distance depuis tant d'années. Une de ces raisons, c'est qu'on a segmenté les tâches simples sous formes de briques assemblables et indépendantes, plutôt que de tout mettre dans un gros ensemble qui ferait tout et sur lequel tout reposerait.
Ca fait 40 ans qu'on aurait pu écrire un 'systemd'. Si ça n'a pas été fait c'était pour de bonnes raisons. Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures.
Est-il possible d'exporter une animation au format SVG + CSS pour l'intégrer dans une page HTML 5 / CSS 3 ? Si c'est le cas je me jette sur ce logiciel !
Je compare quotidiennement la différence entre mon ordi au boulot sous Windows 7 (Windows XP ne s'en sortait pas mieux) et mon ordi perso sous Debian.
Et en l'occurrence je tendrais aussi à surnommer Windows "Windaube" parce que je n'ai pas eu un problème avec, mais j'ai un problème par jour avec, quand j'en ai un par an avec Debian…
J'étais sous Windows 3.1, Windows 3.11, Windows 95, Windows 98, Windows XP, Windows Vista et Windows 7. Puis j'ai testé Linux (Debian en l'occurrence) et là j'ai pleuré en repensant aux centaines d'heures passées à configurer, paramétrer, installer, réinstaller, formatter, reformatter, nettoyer les virus, renettoyer les virus, etc. etc. etc., pour finalement recommencer.
"Windaube" je trouve ça un peu enfantin comme nom c'est vrai, mais à l'usage c'est exactement ça. Je n'arrive toujours pas à lui trouver un avantage sur Linux, si ce n'est peut être qu'il est installé sur 90 % des PC et donc que c'est très pratique quand on veut péter la sécurité d'un système.
Simple exemple : désigner des lecteurs par des lettres comme "C:" au lieu de fichiers, ça rend tout le système complexe à maintenir et incompatible avec plein de trucs, ne serait-ce que pour les liens entre mes fichiers Excel au boulot. Quand un collègue bosse avec un fichier stocké sur R: et que moi il est déclaré en P: et bien c'est le bordel, il faut se taper l'actualisation des liens un par un à chaque fois (bien sûr on ne peut rien changer). C'est quand même très con et ça fait perdre des dizaines de minutes pour rien chaque semaine. Même logique avec les lettres des lecteurs réseaux qui sont remplacées automatiquement sans prévenir par quelque chose comme "//mon/emplacement/réseau". Bref, Windows me gave et ce n'est pas du fanatisme, pour moi c'est une réalité quotidienne que je dois subir.
Là je donne un exemple de quelque chose de relativement bénin, mais j'ai été confronté à des cas d'emmerdement où j'avais juste envie de brûler mon PC sur place. En toute honnêteté, je n'arrive pas à voir en quoi Windows peut être mieux que Linux. Au mieux je peut concéder l'unicité de l'environnement de travail pour une version donnée qui permet à tous les utilisateurs de s'y retrouver lorsqu'ils passent d'un poste de travail à un autre, mais ça s'arrête là.
L'écriture de ceci m'a été inspirée par les annonces récentes réclamant publiquement un fork de Debian, une idée que je trouve idiote et qui ne débouchera probablement pas sur énormément de travail technique.
Par pitié, arrêtez avec ça. Ce fork n'est pas à cause de 'systemd'. Tout comme le départ de plusieurs développeurs Debian ces dernières semaines.
Cette volonté de forker vient du fait que les leaders de Debian ont voté contre l'obligation de maintenir les paquets comme 'gnome' ou 'kde' compatibles avec 'sysvinit'. Cela implique que 'gnome' ne pourra plus être utilisé sans 'systemd', ce qui impose donc de fait un système de démarrage, au détriment de tous ceux qui ont besoin pour une raison ou pour une autre d'utiliser 'sysvinit' (utiliser un noyau UNIX par exemple, et ça me semble être une très bonne raison).
Que 'systemd' soit dans les dépôts de Debian malgré sa philosophie anti UNIX et son code discutable, c'est une chose. Et à vrai dire c'est supportable du moment qu'on nous laisse la liberté de choisir un autre système de démarrage dans les dépôts.
Or c'est précisément cette liberté qui a été refusée aux administrateurs systèmes du monde entier, en dépit de leurs (nombreux) appels de détresse, mais surtout à l'encontre du pacte social qui a fait de Debian sa réputation.
Voilà pourquoi il a été décidé de forker Debian. C'est un problème de liberté et de confiance rompue. Pas de code.
Donc ça confirme d'autant plus l'inutilité de la Testing sur un poste de travail autrement que pour débugguer la future version de Debian =)
Si la Stable avec des backports est capable de faire la même chose que la Testing pour 95 % des logiciels qu'on utilise, pourquoi vouloir utiliser une branche instable et moins sécurisée ? Je ne vois pas de raison objective à cela (si ce n'est, je me répète, pour contribuer au débuggage de la future Debian).
De même, j'ai eu affaire à une machine extrêmement récente et la Stable ne fonctionnait pas (carte mère mal supportée, notamment la partie graphique). J'ai installé le dernier kernel disponible dans les backports et plus aucun problème.
Sur une machine classique, la Testing n'apporte rien de plus que les backports d'un point de vue système (puisque les backports sont généralement alignés sur la Testing !). Pareil pour tout ce qui est bureautique.
Sur une machine plus exotique (avec des périphériques de montage vidéos spéciaux par exemple), c'est autre chose. Tout ce qui touche au multimédia a tendance à nécessiter des logiciels récents, donc dans ce cas je comprends que la Testing puisse être nécessaire.
Une autre raison d'utiliser la Testing, c'est si on a absolument besoin d'un élément mis à jour comme 'wayland' ou 'systemd'. Là on touche au coeur du système et les backports ne peuvent pas faire le boulot. C'est selon moi le seul cas où on pourrait être amené à utiliser une Testing "en production".
Tu parles de personnes qui mettent les mains dans la cambouis pour debugguer Debian là. Donc on est bien d'accord : la Testing est faite pour ceux qui sont suffisamment à l'aise pour remonter les bugs et contribuer au développement de Debian.
Ma phrase est assez radicale et volontairement provoc, je l'admets.
A part un groupe d'ubergeeks prêts à casser du bug, je ne vois pas l'intérêt d'utiliser une Testing sur un poste de travail pour faire du montage vidéo, pour surfer, pour faire de la bureautique,…
J'ai bien compris ce que tu voulais dire, c'est peut être moi qui n'ai pas réussi à exprimer mon idée.
Même si c'est effectivement beaucoup d'efforts pour un nombre restreint d'utilisateurs, je pense que ce sont précisément ces utilisateurs qui changent le monde en faisant des trucs a priori inutiles, farfelus, mais qui façonnent peu à peu nos connaissances et nous donnent envie de créer chaque jour de nouvelles choses, utiles cette fois.
Quel intérêt de porter Linux sur une TI-89 ? On peut franchement se le demander. Sauf que j'ai eu énormément de plaisir à coder en assembleur sur ma TI-83 puis ma TI-89. Et ce que j'ai fait n'a servi à rien concrètement. Mais j'ai appris énormément de choses et la valeur que j'en tire aujourd'hui en valait sacrément la peine. Je pense aux boulots que ça m'a permis d'avoir, mais bien au-delà de ça de tout ce que ça m'a apporté comme connaissances et épanouissement personnel. Pour moi c'est ça le hacking.
Porter Debian sur autant d'architectures différentes nécessite une montagne de boulot incroyable, mais si on calcul le ratio Efforts requis / Nombre d'utilisateurs, alors autant laisser Microsoft faire son boulot et se contenter de ce qu'ils nous fournissent, plutôt que de chercher à économiser 5 cycles processeur sur une interruption appelée 3 fois par jour… Le libre c'est avant tout s'amuser à développer des systèmes pour la beauté de la chose. Si on peut rendre ça rentable, alors c'est carrément mieux, on est d'accord. Mais ce n'est pas ce qui a motivé le développement de Linux ou de Debian, et c'est pour ça que ce sont de si bons systèmes. Si ça amuse des mecs dans leur garage de maintenir des paquets qui ne servent à personne (même pas à eux), et bien le fait qu'ils prennent leur pied à le faire est déjà suffisant selon moi.
C'est sûr que j'aimerais qu'ils passent plus de temps à porter Compiz sous Debian Wheezy plutôt que de faire tourner des logiciels de radioamateur pour des PowerPC, mais les besoins et les motivations de chacun sont différents. Je suis sûr que les geeks barbus qui ne jurent que par la ligne de commandes se demandent bien pourquoi j'ai besoin de Compiz. Et pourtant…
C'est dommage que tu ne saches pas ce que sont les rétroportages (backports en anglais).
Cf. mon commentaire plus bas pour plus d'explications si ça t'intéresse.
Je retourne la chose : ceux qui utilisent Debian en dehors de la branche Stable n'ont rien compris à Debian et feraient mieux d'utiliser Ubuntu (ou de lire la suite de mon commentaire ;-) ).
Je m'explique.
La branche Stable est, ô miracle, stable. C'est celle qui est utilisée partout en production. Elle est sécurisée, fiable, maintenue. Mais les versions des logiciels sont figées (pour avoir une stabilité dans le temps, donc une cohérence de l'ensemble sur une période donnée, en l'occurence environ 2 ans).
Si l'on souhaite mettre à jour des paquets, on utilise les rétroportages (= backports en anglais). Ce sont des paquets qui sont officiellement (depuis le 05 septembre 2010 : https://www.debian.org/News/2010/20100905 ) maintenus par l'équipe Debian et qui permettent d'avoir des versions plus récentes des paquets les plus utilisés sans pour autant déstabiliser le système, que ce soit en termes de sécurité, de stabilité ou de performances. Parmi eux, on peut noter : le kernel, LibreOffice, Firefox (= Iceweasel), Thunderbird (= Icedove), VLC,…
La branche Testing est à destination des développeurs et constitue une sorte de Beta de Debian. On l'utilise si l'on souhaite voir à quoi ressemblera la prochaine version de Debian, ou pour contribuer au développement de la future version, ou parce qu'on souhaite utiliser vite fait et très salement un truc qui ne se trouve pas dans Stable et qu'on ne veut pas casser son système de base (auquel cas on peut l'utiliser via un 'chroot', ou dans une machine virtuelle, ou en dual boot temporaire). C'est une version dont la stabilité et les performances ne sont évidemment pas garanties, mais bien plus important que ça, la sécurité n'est pas garantie (puisqu'elle fait l'objet de tests et d'ajustements constants). C'est donc une branche à proscrire pour toute utilisation sur un réseau (ce qui inclut l'Internet, et même surtout sur l'Internet) ou pour toute machine qui se doit d'être stable et/ou sécurisée.
La branche Unstable (nommée Sid) est également à destination des développeurs, mais là ça ressemble carrément à une version Alpha de Debian. Autant dire que la sécurité laisse à désirer. Quant à la stabilité, n'en parlons pas.
Enfin, le dépôt Experimental n'est même pas une branche, c'est un vaste dépotoir dans lequel on place quelques paquets pour ceux qui souhaitent tester si un truc tout nouveau qui vient de sortir a une chance de ne pas foutre en l'air tout le système complet (genre 'wayland' v0.1 ou 'systemd' v0.1). C'est pour voir comment le système réagit à l'ajout de paquets assez particuliers. Ca correspond à une version prototype de Debian.
Lorsque Debian Testing est en phase de gel, on peut dire qu'elle n'est plus en version Beta mais en version admissible (= Release Candidate). Ce qui, là encore, n'est pas censé être utilisé sur une machine de tous les jours.
J'ai envie de dire que d'une certaine façon seuls ceux qui ne sont pas assez compétents utilisent autre chose qu'une branche Stable sur une machine de tous les jours. Car ceux qui sont suffisamment bons sauront comment compiler un programme et l'adapter si jamais il ne tourne pas d'origine sur la Stable, et comment chrooter une Testing ou une Unstable dans une Stable pour la tester et/ou contribuer au développement. Les seuls cas où l'on devrait utiliser une Testing ou une Unstable directement sur une machine, c'est lorsqu'on souhaite contribuer au code de Debian.
Finalement, Canonical ne fait rien d'autre que de mettre beaucoup de mecs à temps plein sur une Debian Testing pour virer un maximum de bugs le plus vite possible, de proposer vite fait des logiciels additionnels et d'appeler tout ça 'Ubuntu'. A mon sens, ils feraient mieux d'allouer ces ressources directement au développement des backports et des branches Testing et Unstable. Ca permettrait de passer Debian en Stable beaucoup plus vite, d'avoir des backports bien plus nombreux et plus fiables et d'élargir la compatibilité de Debian avec les nouvelles machines.
Néanmoins c'est plus ou moins le cas depuis un petit moment, je sais que les développeurs d'Ubuntu et de Debian travaillent plus en collaboration qu'avant et ça se ressent dans le développement de Debian (pas toujours dans le bon sens malheureusement).
Ce n'est possible que parce que Debian existe déjà pour les architectures ARM. Si l'on veut démocratiser Debian sur d'autres machines que les architectures x86 et x86_64, il faut d'abord que l'OS soit en mesure de tourner sur ces autres architectures. Je me vois mal concevoir un smartphone en disant "il va tourner sous Debian" et ne m'intéresser au portage de l'OS qu'après avoir conçu mon smartphone..! Donc le temps que l'OS soit adopté sur d'autres architectures, il faut attendre un peu.
Donc du gâchis, ça dépend comment on voit les choses. Ceux qui utilisent Debian sur les autres architectures doivent être très heureux de pouvoir le faire, et c'est peut être le seul OS grand public avec autant de paquets qui tourne sur autant d'architectures différentes, ce qui en fait peut être le seul OS réellement utilisable sur des architectures peu utilisées, ce qui a une grande valeur pour ceux qui en ont besoin.
Et puis ce n'est pas forcément le nombre de machines qui compte, l'importance des tâches accomplies par 10 machines peut être supérieure à celle réalisée par 10.000 machines. Exemple : je pense que 10 serveurs Wikipedia sont bien plus utiles que 10.000 serveurs YouTube pour regarder des vidéos de lolcats… Si pour une raison quelconque les serveurs de Wikipedia doivent tourner sous ARM (exemple : pour consommer moins d'énergie ==> développement durable ==> saybon, mangez-en), alors il faut que Debian soit déjà prévu pour cela avant de pouvoir le concrétiser.
Les contrôles d'accès permettent de s'assurer qu'un processus (donc un logiciel) n'accède pas à une information à laquelle il ne devrait normalement jamais accéder. Autrement dit, ça peut permettre d'éviter les attaques 0-day, les buffer overflows, ce genre de choses. Si demain Linux remplace Windows en parts de marché, les virus deviendront légion et les solutions de contrôle d'accès seront absolument indispensables.
Ceci étant dit, j'ai recensé environ 1000 attaques sur le port SSH de mon serveur par jour (80 % en provenance de Chine). Pourtant il ne s'agit que d'une machine très banale, je n'ose pas imaginer sur un serveur critique. Donc je pense que n'importe quelle machine connectée à l'Internet devrait impérativement avoir une solution de contrôle d'accès.
J'illustre à quoi ça peut servir concrètement : imagine qu'on découvre une faille jusque là totalement inconnue dans un logiciel de suivi d'activité de ton PC (faille 0-day) et que cette faille permet de récupérer tout tes fichiers perso. En l'occurrence, ce logiciel n'est pas censé accéder à tes fichiers perso puisqu'il n'en a pas besoin. Il a juste besoin d'accéder aux fichiers de suivi de température, au taux de charge de ta batterie, etc. Avec une solution de contrôle d'accès, tu écris une règle qui dit que ce logiciel ne devra jamais accéder à autre chose qu'aux fichiers système pour le suivi de la température et la charge de ta batterie. S'il essaie d'accéder à tes fichiers perso, il se fait jeter. Et donc la faille sera inefficace. Alors que sans contrôle d'accès, la faille devient utilisable et peut avoir des conséquences catastrophiques.
Un contrôle d'accès permet même de restreindre les droits de root. Pensez-y, ça peut être très intéressant, car je ne vois pas pourquoi je dois accorder les pleins pouvoirs à Microsoft lorsque j'installe Skype sur mon ordi. Je veux juste installer Skype, pas formater mon disque dur, donc je ne vois pas trop pourquoi je donne le même niveau de droits à Microsoft qu'à moi-même. En réalité, root ne devrait quasiment jamais être utilisé, ou en tout cas pas à l'état pur. C'est un niveau de privilèges bien trop important pour ce qu'on souhaite généralement faire.
Il se trouve que de proposer des solutions libres permet à tout le monde d'accéder gratuitement à des solutions informatiques et sur n'importe quelle plateforme.
Perso lorsque je tombe sur un site codé en Silverlight ou avec du Flash bien verrouillé par des DRM, je peste car je ne peux pas consulter le site en question. Et je dois me trouver une machine sous Windows (ce que je n'ai pas) pour pouvoir utiliser le site.
Donc en ce qui me concerne, les solutions libres sont une très bonne chose qui pourrait grandement me simplifier la vie, tout comme ceux qui ne veulent pas forcément acheter ce qu'il faut pour pouvoir aller sur le site de l'administration française.
En résumé, la société GDC a décidé de sortir du projet et de rembourser les dons (hors frais déjà engagés) en les annulant.
De cela est née l'idée de proposer aux donateurs la possibilité de se faire rembourser non pas sur leur compte personnel, mais sur un compte appartenant à une des 2 sociétés qui font partie du projet.
Ainsi, le problème du transfert des dons (problèmes juridiques et fiscaux) a été résolu de la meilleure façon qui soit grâce à ce qui semblait alors être la pire des solutions.
On aura droit à une news pour le faire savoir sur Linuxfr ? ;)
# GNU dmd
Posté par cluxter . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 4.
Pour ceux que ça intéresse, voici GNU dmd, un système de démarrage universel et de gestion de services conçu pour les systèmes POSIX, qui reprend le meilleur de SysV-init et de systemd :
http://www.gnu.org/software/dmd/
Maintenant qu'une solution sérieuse est en cours d'élaboration pour remplacer le (très) vieillissant SysV-init et le (très) monolithique systemd, qu'on ne vienne plus me parler des avantages/inconvénients de l'un ou de l'autre. C'est une solution propre, simple, respectueuse des principes de base des *NIX et performante.
[^] # Re: LibreOffice
Posté par cluxter . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à -7.
A ce moment là pourquoi est-ce qu'on n'intègre pas l'UEFI + le bootloader + l'init + le login ? Histoire d'avoir des machines aussi fermées que les smartphones ? (sinon plus) Parce que bon, il suffit d'ajouter l'UEFI dans 'systemd' est on y est hein…
Des PC où tout serait verrouillé de l'UEFI jusqu'au bureau ? Microsoft l'a rêvé, Red Hat l'a (bientôt) fait.
Je ne suis pas fondamentalement contre le fait d'avoir un logiciel qui nous permette d'intégrer absolument toute la chaîne de démarrage de A à Z dans un logiciel monolithique (on a beau séparer les binaires, ils sont quand même tous dépendants les uns des autres). Ca peut avoir une vraie utilité pour tout un tas de personnes ou d'entreprises.
Mais mettre ce système par défaut dans quasiment toutes les distributions et donc aller à l'encontre des principes de base qui ont fait le succès des *NIX, je trouve ça aberrant. Je suis convaincu que toutes les distributions qui adoptent 'systemd' sont en train de se tirer une balle dans le pied à long terme.
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 3.
1) Malgré ça, on assiste à des développeurs Debian officiels qui créent un fork ;
2) "Ce n'est pas parce qu'ils sont une majorité à avoir tort qu'ils ont raison", pour reprendre Coluche. Entendre par là : je tiens à me faire ma propre opinion, même si le meilleur programmeur du monde me dit que j'ai tort, car c'est comme ça que je comprendrai pourquoi j'ai tort (ou lui éventuellement, ça arrive…).
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 2.
Tout comme systemd n'a pas grand chose à voir avec une des règles de base d'UNIX malheureusement, à savoir la séparation de tâches simples en briques logicielles indépendantes.
J'ai dit "Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures". Pas "Maintenons le statu quo". Parfois, oui, il vaut mieux refuser certaines évolutions qui en réalité amènent autant de problèmes qu'elles n'en résolvent. Ce qui ne veut pas dire qu'il ne faille rien faire pour améliorer par exemple OpenRC.
C'était même tellement bien qu'on a été obligé de créer une v2 de Linux pour y ajouter des modules.
C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.
Ca fait 3 fois que je l'écris dans ce fil mais je vais le redire : séparer des tâches en briques logicielles indépendantes. C'est un des concepts de base de la programmation système sous les *NIX, j'en veux pour référence cet excellent ouvrage : http://www.oreilly.com/openbook/linuxdrive3/book/
Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).
Par évolution, j'entendrais quelque chose comme "contribuer à l'existant pour le rendre vraiment meilleur", plutôt que de prendre plein de fonctionnalités et de les agréger en un ensemble de briques pas indépendantes qu'on aura entièrement recodées. Plutôt que de faire un peu de vérification de système de fichiers + un peu de parefeu + un peu de ceci et un peu de cela, systemd ferait bien de ne faire que l'initialisation. Ou s'il veut tout faire, qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 2.
Pour le point 2, OpenRC peut être plus rapide au démarrage que systemd.
Pour le point 3, je suis totalement d'accord et je n'ai jamais compris pourquoi on avait conçu des trucs aussi compliqué pour lancer des choses simples.
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à -1.
Techniquement, évidemment que ça fonctionne.
Je parle de faire tourner les choses proprement pour qu'on puisse continuer à avoir un système fiable et performant. Linus Torvald est du genre à passer une nuit sur une fonction appelée 1 fois par jour pour gagner 5 cycles microprocesseur, son argument étant de dire que 5 cycles CPU x des millions de machines, ça fait beaucoup d'énergie économisée. C'est cette approche que j'aimerais voir dans les distributions.
Lennart Pottering est bien loin de cet état d'esprit selon moi, sinon il aurait contribué à des systèmes de démarrage existants en vue de les améliorer (je pense à OpenRC qui n'est pas parfait mais qui se rapproche de ce que 'systemd' sait faire, et pour le coup de manière propre, intelligente et compatible UNIX).
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 2.
Tout comme ça serait sûrement très pratique que 'systemd' fasse le café.
Est-ce intelligent pour autant ? Non.
Ce n'est pas parce qu'on peut le faire qu'on doit le faire.
Visiblement certains semblent oublier pourquoi les *NIX ont réussi à devenir des OS de référence et à tenir la distance depuis tant d'années. Une de ces raisons, c'est qu'on a segmenté les tâches simples sous formes de briques assemblables et indépendantes, plutôt que de tout mettre dans un gros ensemble qui ferait tout et sur lequel tout reposerait.
Ca fait 40 ans qu'on aurait pu écrire un 'systemd'. Si ça n'a pas été fait c'était pour de bonnes raisons. Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures.
# HTML 5 ?
Posté par cluxter . En réponse à la dépêche Sortie de SynfigStudio 0.64.3 : BugFix!. Évalué à 4.
Est-il possible d'exporter une animation au format SVG + CSS pour l'intégrer dans une page HTML 5 / CSS 3 ? Si c'est le cas je me jette sur ce logiciel !
[^] # Re: Windaube
Posté par cluxter . En réponse à la dépêche Revue des nouveautés de Glances 2.2. Évalué à 1. Dernière modification le 23 décembre 2014 à 02:39.
Je compare quotidiennement la différence entre mon ordi au boulot sous Windows 7 (Windows XP ne s'en sortait pas mieux) et mon ordi perso sous Debian.
Et en l'occurrence je tendrais aussi à surnommer Windows "Windaube" parce que je n'ai pas eu un problème avec, mais j'ai un problème par jour avec, quand j'en ai un par an avec Debian…
J'étais sous Windows 3.1, Windows 3.11, Windows 95, Windows 98, Windows XP, Windows Vista et Windows 7. Puis j'ai testé Linux (Debian en l'occurrence) et là j'ai pleuré en repensant aux centaines d'heures passées à configurer, paramétrer, installer, réinstaller, formatter, reformatter, nettoyer les virus, renettoyer les virus, etc. etc. etc., pour finalement recommencer.
"Windaube" je trouve ça un peu enfantin comme nom c'est vrai, mais à l'usage c'est exactement ça. Je n'arrive toujours pas à lui trouver un avantage sur Linux, si ce n'est peut être qu'il est installé sur 90 % des PC et donc que c'est très pratique quand on veut péter la sécurité d'un système.
Simple exemple : désigner des lecteurs par des lettres comme "C:" au lieu de fichiers, ça rend tout le système complexe à maintenir et incompatible avec plein de trucs, ne serait-ce que pour les liens entre mes fichiers Excel au boulot. Quand un collègue bosse avec un fichier stocké sur R: et que moi il est déclaré en P: et bien c'est le bordel, il faut se taper l'actualisation des liens un par un à chaque fois (bien sûr on ne peut rien changer). C'est quand même très con et ça fait perdre des dizaines de minutes pour rien chaque semaine. Même logique avec les lettres des lecteurs réseaux qui sont remplacées automatiquement sans prévenir par quelque chose comme "//mon/emplacement/réseau". Bref, Windows me gave et ce n'est pas du fanatisme, pour moi c'est une réalité quotidienne que je dois subir.
Là je donne un exemple de quelque chose de relativement bénin, mais j'ai été confronté à des cas d'emmerdement où j'avais juste envie de brûler mon PC sur place. En toute honnêteté, je n'arrive pas à voir en quoi Windows peut être mieux que Linux. Au mieux je peut concéder l'unicité de l'environnement de travail pour une version donnée qui permet à tous les utilisateurs de s'y retrouver lorsqu'ils passent d'un poste de travail à un autre, mais ça s'arrête là.
[^] # Re: Les raisons du fork
Posté par cluxter . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
Ce qui ne change absolument rien aux raisons du fork. Ma phrase n'est pas plus idiote que celle que j'ai citée.
# Les raisons du fork
Posté par cluxter . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à -2.
Par pitié, arrêtez avec ça. Ce fork n'est pas à cause de 'systemd'. Tout comme le départ de plusieurs développeurs Debian ces dernières semaines.
Cette volonté de forker vient du fait que les leaders de Debian ont voté contre l'obligation de maintenir les paquets comme 'gnome' ou 'kde' compatibles avec 'sysvinit'. Cela implique que 'gnome' ne pourra plus être utilisé sans 'systemd', ce qui impose donc de fait un système de démarrage, au détriment de tous ceux qui ont besoin pour une raison ou pour une autre d'utiliser 'sysvinit' (utiliser un noyau UNIX par exemple, et ça me semble être une très bonne raison).
Que 'systemd' soit dans les dépôts de Debian malgré sa philosophie anti UNIX et son code discutable, c'est une chose. Et à vrai dire c'est supportable du moment qu'on nous laisse la liberté de choisir un autre système de démarrage dans les dépôts.
Or c'est précisément cette liberté qui a été refusée aux administrateurs systèmes du monde entier, en dépit de leurs (nombreux) appels de détresse, mais surtout à l'encontre du pacte social qui a fait de Debian sa réputation.
Voilà pourquoi il a été décidé de forker Debian. C'est un problème de liberté et de confiance rompue. Pas de code.
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 2.
Donc ça confirme d'autant plus l'inutilité de la Testing sur un poste de travail autrement que pour débugguer la future version de Debian =)
Si la Stable avec des backports est capable de faire la même chose que la Testing pour 95 % des logiciels qu'on utilise, pourquoi vouloir utiliser une branche instable et moins sécurisée ? Je ne vois pas de raison objective à cela (si ce n'est, je me répète, pour contribuer au débuggage de la future Debian).
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 1.
De même, j'ai eu affaire à une machine extrêmement récente et la Stable ne fonctionnait pas (carte mère mal supportée, notamment la partie graphique). J'ai installé le dernier kernel disponible dans les backports et plus aucun problème.
Sur une machine classique, la Testing n'apporte rien de plus que les backports d'un point de vue système (puisque les backports sont généralement alignés sur la Testing !). Pareil pour tout ce qui est bureautique.
Sur une machine plus exotique (avec des périphériques de montage vidéos spéciaux par exemple), c'est autre chose. Tout ce qui touche au multimédia a tendance à nécessiter des logiciels récents, donc dans ce cas je comprends que la Testing puisse être nécessaire.
Une autre raison d'utiliser la Testing, c'est si on a absolument besoin d'un élément mis à jour comme 'wayland' ou 'systemd'. Là on touche au coeur du système et les backports ne peuvent pas faire le boulot. C'est selon moi le seul cas où on pourrait être amené à utiliser une Testing "en production".
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 1.
Tu parles de personnes qui mettent les mains dans la cambouis pour debugguer Debian là. Donc on est bien d'accord : la Testing est faite pour ceux qui sont suffisamment à l'aise pour remonter les bugs et contribuer au développement de Debian.
Ma phrase est assez radicale et volontairement provoc, je l'admets.
A part un groupe d'ubergeeks prêts à casser du bug, je ne vois pas l'intérêt d'utiliser une Testing sur un poste de travail pour faire du montage vidéo, pour surfer, pour faire de la bureautique,…
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 8.
J'ai bien compris ce que tu voulais dire, c'est peut être moi qui n'ai pas réussi à exprimer mon idée.
Même si c'est effectivement beaucoup d'efforts pour un nombre restreint d'utilisateurs, je pense que ce sont précisément ces utilisateurs qui changent le monde en faisant des trucs a priori inutiles, farfelus, mais qui façonnent peu à peu nos connaissances et nous donnent envie de créer chaque jour de nouvelles choses, utiles cette fois.
Quel intérêt de porter Linux sur une TI-89 ? On peut franchement se le demander. Sauf que j'ai eu énormément de plaisir à coder en assembleur sur ma TI-83 puis ma TI-89. Et ce que j'ai fait n'a servi à rien concrètement. Mais j'ai appris énormément de choses et la valeur que j'en tire aujourd'hui en valait sacrément la peine. Je pense aux boulots que ça m'a permis d'avoir, mais bien au-delà de ça de tout ce que ça m'a apporté comme connaissances et épanouissement personnel. Pour moi c'est ça le hacking.
Porter Debian sur autant d'architectures différentes nécessite une montagne de boulot incroyable, mais si on calcul le ratio Efforts requis / Nombre d'utilisateurs, alors autant laisser Microsoft faire son boulot et se contenter de ce qu'ils nous fournissent, plutôt que de chercher à économiser 5 cycles processeur sur une interruption appelée 3 fois par jour… Le libre c'est avant tout s'amuser à développer des systèmes pour la beauté de la chose. Si on peut rendre ça rentable, alors c'est carrément mieux, on est d'accord. Mais ce n'est pas ce qui a motivé le développement de Linux ou de Debian, et c'est pour ça que ce sont de si bons systèmes. Si ça amuse des mecs dans leur garage de maintenir des paquets qui ne servent à personne (même pas à eux), et bien le fait qu'ils prennent leur pied à le faire est déjà suffisant selon moi.
C'est sûr que j'aimerais qu'ils passent plus de temps à porter Compiz sous Debian Wheezy plutôt que de faire tourner des logiciels de radioamateur pour des PowerPC, mais les besoins et les motivations de chacun sont différents. Je suis sûr que les geeks barbus qui ne jurent que par la ligne de commandes se demandent bien pourquoi j'ai besoin de Compiz. Et pourtant…
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 1.
Ah oui quand même x-)
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 0.
C'est dommage que tu ne saches pas ce que sont les rétroportages (backports en anglais).
Cf. mon commentaire plus bas pour plus d'explications si ça t'intéresse.
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 0.
Je retourne la chose : ceux qui utilisent Debian en dehors de la branche Stable n'ont rien compris à Debian et feraient mieux d'utiliser Ubuntu (ou de lire la suite de mon commentaire ;-) ).
Je m'explique.
La branche Stable est, ô miracle, stable. C'est celle qui est utilisée partout en production. Elle est sécurisée, fiable, maintenue. Mais les versions des logiciels sont figées (pour avoir une stabilité dans le temps, donc une cohérence de l'ensemble sur une période donnée, en l'occurence environ 2 ans).
Si l'on souhaite mettre à jour des paquets, on utilise les rétroportages (= backports en anglais). Ce sont des paquets qui sont officiellement (depuis le 05 septembre 2010 : https://www.debian.org/News/2010/20100905 ) maintenus par l'équipe Debian et qui permettent d'avoir des versions plus récentes des paquets les plus utilisés sans pour autant déstabiliser le système, que ce soit en termes de sécurité, de stabilité ou de performances. Parmi eux, on peut noter : le kernel, LibreOffice, Firefox (= Iceweasel), Thunderbird (= Icedove), VLC,…
La branche Testing est à destination des développeurs et constitue une sorte de Beta de Debian. On l'utilise si l'on souhaite voir à quoi ressemblera la prochaine version de Debian, ou pour contribuer au développement de la future version, ou parce qu'on souhaite utiliser vite fait et très salement un truc qui ne se trouve pas dans Stable et qu'on ne veut pas casser son système de base (auquel cas on peut l'utiliser via un 'chroot', ou dans une machine virtuelle, ou en dual boot temporaire). C'est une version dont la stabilité et les performances ne sont évidemment pas garanties, mais bien plus important que ça, la sécurité n'est pas garantie (puisqu'elle fait l'objet de tests et d'ajustements constants). C'est donc une branche à proscrire pour toute utilisation sur un réseau (ce qui inclut l'Internet, et même surtout sur l'Internet) ou pour toute machine qui se doit d'être stable et/ou sécurisée.
La branche Unstable (nommée Sid) est également à destination des développeurs, mais là ça ressemble carrément à une version Alpha de Debian. Autant dire que la sécurité laisse à désirer. Quant à la stabilité, n'en parlons pas.
Enfin, le dépôt Experimental n'est même pas une branche, c'est un vaste dépotoir dans lequel on place quelques paquets pour ceux qui souhaitent tester si un truc tout nouveau qui vient de sortir a une chance de ne pas foutre en l'air tout le système complet (genre 'wayland' v0.1 ou 'systemd' v0.1). C'est pour voir comment le système réagit à l'ajout de paquets assez particuliers. Ca correspond à une version prototype de Debian.
Lorsque Debian Testing est en phase de gel, on peut dire qu'elle n'est plus en version Beta mais en version admissible (= Release Candidate). Ce qui, là encore, n'est pas censé être utilisé sur une machine de tous les jours.
J'ai envie de dire que d'une certaine façon seuls ceux qui ne sont pas assez compétents utilisent autre chose qu'une branche Stable sur une machine de tous les jours. Car ceux qui sont suffisamment bons sauront comment compiler un programme et l'adapter si jamais il ne tourne pas d'origine sur la Stable, et comment chrooter une Testing ou une Unstable dans une Stable pour la tester et/ou contribuer au développement. Les seuls cas où l'on devrait utiliser une Testing ou une Unstable directement sur une machine, c'est lorsqu'on souhaite contribuer au code de Debian.
Finalement, Canonical ne fait rien d'autre que de mettre beaucoup de mecs à temps plein sur une Debian Testing pour virer un maximum de bugs le plus vite possible, de proposer vite fait des logiciels additionnels et d'appeler tout ça 'Ubuntu'. A mon sens, ils feraient mieux d'allouer ces ressources directement au développement des backports et des branches Testing et Unstable. Ca permettrait de passer Debian en Stable beaucoup plus vite, d'avoir des backports bien plus nombreux et plus fiables et d'élargir la compatibilité de Debian avec les nouvelles machines.
Néanmoins c'est plus ou moins le cas depuis un petit moment, je sais que les développeurs d'Ubuntu et de Debian travaillent plus en collaboration qu'avant et ça se ressent dans le développement de Debian (pas toujours dans le bon sens malheureusement).
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 3.
Le smartphone 4G Neo900 (architecture ARM) embarquera Debian comme OS par défaut :
http://neo900.org/
Ce n'est possible que parce que Debian existe déjà pour les architectures ARM. Si l'on veut démocratiser Debian sur d'autres machines que les architectures x86 et x86_64, il faut d'abord que l'OS soit en mesure de tourner sur ces autres architectures. Je me vois mal concevoir un smartphone en disant "il va tourner sous Debian" et ne m'intéresser au portage de l'OS qu'après avoir conçu mon smartphone..! Donc le temps que l'OS soit adopté sur d'autres architectures, il faut attendre un peu.
Donc du gâchis, ça dépend comment on voit les choses. Ceux qui utilisent Debian sur les autres architectures doivent être très heureux de pouvoir le faire, et c'est peut être le seul OS grand public avec autant de paquets qui tourne sur autant d'architectures différentes, ce qui en fait peut être le seul OS réellement utilisable sur des architectures peu utilisées, ce qui a une grande valeur pour ceux qui en ont besoin.
Et puis ce n'est pas forcément le nombre de machines qui compte, l'importance des tâches accomplies par 10 machines peut être supérieure à celle réalisée par 10.000 machines. Exemple : je pense que 10 serveurs Wikipedia sont bien plus utiles que 10.000 serveurs YouTube pour regarder des vidéos de lolcats… Si pour une raison quelconque les serveurs de Wikipedia doivent tourner sous ARM (exemple : pour consommer moins d'énergie ==> développement durable ==> saybon, mangez-en), alors il faut que Debian soit déjà prévu pour cela avant de pouvoir le concrétiser.
[^] # Re: Aucun, et, à quoi ça sert
Posté par cluxter . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 8.
Ca peut permettre d'éviter que Skype n'aille regarder ton historique de Firefox, par exemple. Et ne l'envoie sous forme chiffrée à Microsoft.
Une piste à suivre : http://www.debian-fr.org/securiser-skype-t41130.html
Après vous en faites ce que vous voulez…
Les contrôles d'accès permettent de s'assurer qu'un processus (donc un logiciel) n'accède pas à une information à laquelle il ne devrait normalement jamais accéder. Autrement dit, ça peut permettre d'éviter les attaques 0-day, les buffer overflows, ce genre de choses. Si demain Linux remplace Windows en parts de marché, les virus deviendront légion et les solutions de contrôle d'accès seront absolument indispensables.
Ceci étant dit, j'ai recensé environ 1000 attaques sur le port SSH de mon serveur par jour (80 % en provenance de Chine). Pourtant il ne s'agit que d'une machine très banale, je n'ose pas imaginer sur un serveur critique. Donc je pense que n'importe quelle machine connectée à l'Internet devrait impérativement avoir une solution de contrôle d'accès.
J'illustre à quoi ça peut servir concrètement : imagine qu'on découvre une faille jusque là totalement inconnue dans un logiciel de suivi d'activité de ton PC (faille 0-day) et que cette faille permet de récupérer tout tes fichiers perso. En l'occurrence, ce logiciel n'est pas censé accéder à tes fichiers perso puisqu'il n'en a pas besoin. Il a juste besoin d'accéder aux fichiers de suivi de température, au taux de charge de ta batterie, etc. Avec une solution de contrôle d'accès, tu écris une règle qui dit que ce logiciel ne devra jamais accéder à autre chose qu'aux fichiers système pour le suivi de la température et la charge de ta batterie. S'il essaie d'accéder à tes fichiers perso, il se fait jeter. Et donc la faille sera inefficace. Alors que sans contrôle d'accès, la faille devient utilisable et peut avoir des conséquences catastrophiques.
Un contrôle d'accès permet même de restreindre les droits de root. Pensez-y, ça peut être très intéressant, car je ne vois pas pourquoi je dois accorder les pleins pouvoirs à Microsoft lorsque j'installe Skype sur mon ordi. Je veux juste installer Skype, pas formater mon disque dur, donc je ne vois pas trop pourquoi je donne le même niveau de droits à Microsoft qu'à moi-même. En réalité, root ne devrait quasiment jamais être utilisé, ou en tout cas pas à l'état pur. C'est un niveau de privilèges bien trop important pour ce qu'on souhaite généralement faire.
[^] # Re: Le rapport?
Posté par cluxter . En réponse à la dépêche Simplification des démarches administratives. Évalué à 2.
Il se trouve que de proposer des solutions libres permet à tout le monde d'accéder gratuitement à des solutions informatiques et sur n'importe quelle plateforme.
Perso lorsque je tombe sur un site codé en Silverlight ou avec du Flash bien verrouillé par des DRM, je peste car je ne peux pas consulter le site en question. Et je dois me trouver une machine sous Windows (ce que je n'ai pas) pour pouvoir utiliser le site.
Donc en ce qui me concerne, les solutions libres sont une très bonne chose qui pourrait grandement me simplifier la vie, tout comme ceux qui ne veulent pas forcément acheter ce qu'il faut pour pouvoir aller sur le site de l'administration française.
[^] # Re: Petit retour d'expérience
Posté par cluxter . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 6.
Si je comprends bien, tu te plains/tu t'étonnes d'avoir des bugs sur une version Beta (Unstable) ou même carrément Alpha (Experimental) de Debian ?
Etrange…
# Ca continue
Posté par cluxter . En réponse au journal Neo900 en standby. Évalué à 1.
Finalement les choses se déroulent très bien pour le projet, qui continue plus fort que jamais :
http://neo900.org/news-0011-progress-update-may
En résumé, la société GDC a décidé de sortir du projet et de rembourser les dons (hors frais déjà engagés) en les annulant.
De cela est née l'idée de proposer aux donateurs la possibilité de se faire rembourser non pas sur leur compte personnel, mais sur un compte appartenant à une des 2 sociétés qui font partie du projet.
Ainsi, le problème du transfert des dons (problèmes juridiques et fiscaux) a été résolu de la meilleure façon qui soit grâce à ce qui semblait alors être la pire des solutions.
On aura droit à une news pour le faire savoir sur Linuxfr ? ;)
[^] # Re: décidement
Posté par cluxter . En réponse à la dépêche Création de l'association Open Food Facts et assemblée constitutive au NUMA à Paris le 11 avril 2014. Évalué à 2.
[^] # Re: décidement
Posté par cluxter . En réponse à la dépêche Création de l'association Open Food Facts et assemblée constitutive au NUMA à Paris le 11 avril 2014. Évalué à 1.
Je répondais sur la notion du marketing, pas sur le fait de préférer l'anglais au français.