Renault a écrit 7477 commentaires

Hum, aisément est un adverbe et non une préposition comme à, du coup je ne vois pas la pertinence de ta remarque : ma phrase est correcte.

Je suis pas sûr de comprendre l'argument ; tu parles par exemple d'une appli web quelconque qui ne fonctionnerait qu'avec une vieille version de php (probablement trouée donc) ? Si oui, il faut modifier l'appli pour qu'elle fonctionne avec les versions actuelles. Faire autrement me semble suicidaire au niveau de la sécurité. Et si on peut pas modifier l'appli pour une raison de budget ou autre, on se dirige dans tous les cas vers des problèmes. Qui mettrait en prod une application web plus maintenue ?

Tu oublies quatre choses :

• Des versions supportées simultanément, il y en a parfois plusieurs. Les distributions proposent rarement tous les supports d'un coup.

• Il y a parfois des outils, non reliés au réseau, qui sont utiles et dont le portage coût cher par rapport au gain. Car ici les considérations de sécurité sont absentes et donc il faut se coltiner un peu les vieux trucs tant que c'est possible.

• Il y a un temps entre le moment où tu débutes le portage et la fin, et parfois il faut une fonctionnalité ou la correction d'un bogue. Puis il te faut une copie de l'environnement initial pour vérifier que tu n'as pas changé le comportement de l'application dans le portage.

• Pour bien tester et développer, il faut minimiser les différences entre la machine de prod et la machine du développeur. Utiliser Docker ou une VM permet de s'abstraire de tout ceci sans être contraignant (avoir la même distribution sur le serveur et les machines de développement ne me paraît pas judicieux).

Pour tout ça, sans être en systèmes embarqués, Docker et autres sont de bonnes solutions. Ce ne sont pas des solutions universelles, mais les distributions traditionnelles non plus… Au bout d'un moment, il faut accepter de faire cohabiter les solutions suivant les besoins.

"Oh làlà! C'est obsolète tout ce bazar, et pas fiable! Et même pas bien sécurisé!
Monsieur je pense qu'il vaut mieux tout réécrire. Je vous prépare le devis?"

Cela peut être pertinent pour un serveur Web ou un logiciel traditionnel, cela l'est moins quand on parle du support d'une puce précise dont le constructeur de la dite puce a fait un bon gros patch dégueulasse pour le noyau, le chargeur de démarrage et potentiellement d'autres trucs pour des versions précises de ces composants et basta tu te débrouilles avec.

Oui on peut réécrire et adapter l'ensemble, le projet ne prendra pas 1 an mais 5 ans. Demandera des compétences différentes. Ne coûtera pas le même prix non plus et sans garanties de fonctionner mieux (d'autant qu'on n'a pas accès aux documentations ayant servi à concevoir ce gros patch). En plus quand tu auras fini ce travail, tu seras en retard pour les évolutions qui ont eu lieu entre temps. C'est sans fin.

Ou alors tu utilises Docker en 10 minutes et tout le monde est content. Au bout d'un moment il faut être pragmatique et arrêter de croire qu'on peut toujours faire la solution idéale partout. Ça se saurait.

Je ne comprends pas ton idée de cache binaire.
Si je devine ce que tu veux dire, cela implique que le paquet existe déjà pour la distribution. Ce qui n'est pas toujours le cas (je dirais même que ce sont les paquets absents des dépôts qui sont les plus concernés par les dispositifs qu'on décrit).

Tu mets sous le tapis plusieurs problèmes :

• Comment la recette devine le nom de la dépendance qui manque (les noms de paquets diffèrent pour un même paquet) ? Comment il gère le cas où une distribution fournit la dépendance et une autre pas ? Comment il gère le cas où deux distributions ont des options de compilations qui diffèrent fondamentalement ce qui peut induire qu'une dépendance soit inutilisable car avec des trucs en moins ?

• Quid des licences ? Fedora Copr permet par exemple de faire des équivalents de PPA et qui pourraient, d'un point de vue architecture, ressembler à ce que tu proposes. Mais Fedora refuse que ce système soit utilisé par autre chose que des paquets libres non couverts par des brevets.

Bref, tu ne réponds pas vraiment à ces questions. Il ne faut pas se mentir, sur la question de dépôts contre les solutions tout en un, aucun n'est parfait. Suivant le contexte l'un sera plus adapté que l'autre.
Il est selon moi important que les distributions proposent les deux modèles simplement, pour prendre en compte tous les cas de figures. Ensuite à l'utilisateur de choisir ce qui est le mieux pour lui au cas par cas.

Car cela ne répond pas forcément au besoin ?
Je veux dire, quand tu utilises un utilitaire comme buildroot, Yocto ou similaires, pour travailler il va utiliser au départ des éléments de ta machine : ton compilateur, les en-têtes et les bibliothèques.

Et souvent, si tu travailles sur de vieilles versions ce qui est courant, ta distribution ne propose pas ce qu'il faut. Un symbole introuvable, une en-tête manquante, ou un outil qui a changé de comportement ce qui casse tout (GCC en particulier qui a activé par exemple C++11 par défaut).

La compilation statique ne résout que partiellement ce genre de soucis. Et cela reste contraignant pour le déploiement. Avec Docker, le gars débarque, en 10 minutes montre en main il a les outils d'opérationnels. Combien de temps pour s'il doit récupérer et placer au bon endroit les outils ? Sans compter qu'il devra aussi chercher dans sa distribution ce qui marche manuellement dans les dépôts.

Et comment tu gères aussi les différences entre Python, PHP tout ça ? La compilation ne suffit pas, il faut potentiellement récupérer tout l'écosystème en entier. Une distribution offre rarement ce genre de choses nativement, Docker pallie aisément à ce besoin.

En tant que développeur je vais te répondre, parfois on n'a pas le choix et cela simplifie grandement la vie.

Dans mon boulot, il m'arrive de devoir travailler (en systèmes embarqués) sur des programmes antédiluviens, qui nécessitent des programmes ou bibliothèques non maintenues dans les distributions principales. On fait quoi ? On jette tout et on dit merde au client et au fournisseur ?

Docker et assimilés permettent de contourner les limitations de notre système pour développer sur ce projet ce qui économise une VM ou éventuellement un boot dédié pour développer dessus. Cela permet aussi très facilement de s'abstraire des différences entre distributions. Tiens un sous-traitant débarque avec un système différent sur sa machine, pas grave, il va avoir facilement les outils pour développer dessus de manière identique aux autres. La production a un serveur sous Debian X quand les développeurs sont sur Debian Y ? Pas de soucis, tout le monde pourra avoir la même version que la prod localement pour tester.

Bref, n'en veux pas forcément aux dev, pour bien faire notre travail, Docker ou autres peuvent être vraiment indispensables. Je ne dis pas que cela doit être fait pour tout et n'importe quoi, mais cela fait sens dans ce contexte.

Il y a des solutions qui existent depuis longtemps. Dans Debian et toutes les distributions basées dessus, tu as l'outil "alien" qui permet d'installer des RPM. Comme ça, le développeur fournit un RPM, et il peut s'installer partout. Par contre, c'est difficile d'avoir un RPM avec les bonnes dépendances et qu'on arrive quand même à installer.

En fait la question des RPM, DEB ou autres n'est pas réellement pertinente, à part ceux qui font les paquets qui ce sont qui vont subir la difficulté (ou pas) d'en concevoir un proprement. On le voit avec en effet alien qu'il ne suffit pas de convertir de format pour résoudre le soucis.

Car ce qui diffère vraiment entre les distributions, ce sont les conventions de nommages des paquets (httpd pour Fedora et assimilés, apache pour Debian et similaires), les numéros de version (faire fonctionner un RPM de Fedora flambant neuf sur une Debian pourrait échoué à cause des différences de versions) sans compter les options de compilations attribués à chaque paquet ou d'autres choses comme de l'intégration à des composants systèmes comme SELinux qui est fait par la distribution.

Et ces aspects là sont fondamentaux et insolubles. Pour vraie du vrai cross-distribution il faut donc soit :

• Repartir systématiquement des sources, mais bon on n'est pas chez Gentoo ici ;
• Inclure un maximum de dépendances dans le paquet pour que cela passe partout (modulo un noyau et une base suffisamment compatibles mais c'est assez faisable).

Beaucoup de distributions comme Fedora gèrent les mises à jour par delta nativement (c'est même souvent le mode par défaut). Rien n'empêche donc de le généraliser, notamment à ces applications contenant tout ce qui est nécessaire.

Ils ont poussé des trucs comme PulseAudio à une époque où c'était Rock'n'Roll pourtant et je pense qu'il y a plus de gens qui savent changer de navigateur que de gens qui savent bypasser PA.

Fedora a changé depuis cette époque, la QA a pris énormément d'importance depuis. Cela se voit avec Wayland qui a été maintes fois repoussé et avec conservation de la roue de secours quand cela a été envoyé.

Mais bon c'était une boutade, ils font bien ce qu'ils veulent. Ça m'a surpris parce que je trouve Mozilla assez méticuleux sur le sujet et que c'est une fonctionnalité assez attendue.

Mozilla fait attention, c'est vrai, mais comme indiqué, le calendrier de Mozilla est rarement identique pour tous les systèmes d'une part (Windows a quand même bien plus de testeurs) et les distributions ont leur propre politique (n'oublions pas que c'est cela le but d'une distribution aussi, potentiellement différer sur la source pour avoir un tout cohérent).

Il faut dire que Mozilla et les distributions sont rarement en phases pour ce genre de changements importants. Chaque OS a plus ou moins son propre calendrier. On l'a vu pour GTK+3 où Linux (et Fedora en tête) ont été en avance par rapport à Windows, mais Linux a été en retard sur la question de l'accélération matérielle et pour les bibliothèques multimédias, etc.

Fedora est certes une vitrine technologique mais avec un minimum de QA derrière. Je suppose qu'étant donnée l'importance de Firefox (navigateur principal et par défaut) et les potentiels soucis qui peuvent apparaître le mainteneur a dû être frileux. On verra bien. :)

C'est probablement Fedora qui a décidé de couper par défaut pour tout le monde ce mode, le temps de vérifier son bon fonctionnement.

mais autant que je sache les prix/taxes/remises sont bien toujours locaux.

C'est pire que ça, les prix en France sont libres.
Rien n'empêche à un supermarché de vendre un produit donné à 500€ et que la même enseigne à 30 km le fasse à 600€. En fait c'est hyper courant comme approche.

Sans compter les supermarchés ou fast foods qui sont les rois des réductions ciblées, du genre offre valable sur 1 ou 2 départements.

Bref, cela se passe au sein de la France, aucune raison que cela ne se fasse pas entre frontières politiques.

Ah oui, je n'avais pas fait attention, je n'ai pas suivi cette procédure et chez moi cela marche.

J'ai crée la clé browser.tabs.remote.force-enable que j'ai mis à True puis j’ai relancé. Tu devrais essayer.

Tu as redémarré Firefox après ta manipulation ?

Tous les retours ont été positifs, c’est pourquoi avec Firefox 51, Electrolysis sera activé sauf si présence d’une extension marquée explicitement incompatible.

Ce n'est pas vrai. C'est l'inverse. Cela ne s'active que si toutes les extensions possédées sont déclarées comme compatibles. La différence est que beaucoup d'extensions n'ont pas de status à ce sujet, cela sera donc considéré comme incompatible même si ce n'est pas vrai.

J'en profite pour dire que Mozilla ne peut deviner seules les extensions qui sont compatibles ou non. Cela repose donc sur les développeurs et utilisateurs des extensions de le signaler.

Si vous souhaitez accélérer le déploiement par défaut de Electrolysis dans Firefox vous pouvez consulter la page listant les extensions et leurs status.
Vérifiez que toutes vos extensions soient marquées comme compatibles. Si non, installez l'extension recommandée sur cette page. Forcez Electrolysis sur votre configuration et testez. Faites ensuite un rapport d'activité via l'extension après un usage raisonnable de l'extension et du navigateur (donc quelques jours probablement). Et si ce n'est pas compatible, n'hésitez pas à contacter les développeurs des extensions concernées.

Plus il y aura de retours, plus vite la situation évoluera pour un déploiement total et sans casse.

Le Logiciel Libre, c'est aussi s'impliquer pour que cela avance. ;-)

Cela ne répond pas vraiment à la question, quelle est la température du système ? Il y a-t-il beaucoup de processus qui sollicitent la machine ?

Comprends que généralement, à quelques exceptions près (mais qui sont souvent liés à une dépendance forte au processeur, ce qui n'est pas le cas d'une imprimante), sous Linux un pilote peut fonctionner sur toutes les architectures.

Pour que le pilote fonctionne sur une autre architecture il suffit de le recompiler pour la nouvelle architecture, ce que fait normalement ta distribution pour toi.
Sous Windows, c'est au bon vouloir du fabricant. Ton imprimante étant vieille, le 64 bits n'existait pas à l'époque, ton constructeur n'a jamais compilé le code du pilote pour 64 bits. Et comme tu n'as pas le code source, tu es bloqué. Ce qui est différent sous Linux.

Il est vrai que ton imprimante est assez ancien et que cela est un problème sous Windows. Je ne sais pas si Windows supporte les pilotes 32 bits sur son système 64 bits.

Cependant sous Linux le soucis est différent. Comme tu souhaites y passer, on peut constater que ton modèle est pleinement supporté par le noyau. Du coup cela devrait marcher en 64 bits sans soucis.

L'architecture 32 et 64 bits d'x86 sont compatibles de manière ascendante. Le processeur et le système 64 bits peuvent exécuter des logiciels 32 bits. Que ce soit Windows ou Linux. D'ailleurs, la plupart des distributions Linux sont multilib, ils ont des paquets 32 bits (comme WINE) pour leur système 64 bits.

Bref, installer un système 32 bits pur pour un ordi récent n'a pas d'intérêt autre que de castrer les possibilités de ta machine.

Linux supportera (ou supporte déjà ?) ces architectures. IL faudra peut être attendre un peu que les modèles sortent pour que les distributions puisse les exploiter aussi.

Non, je dis que en général ça ne fonctionne pas

C'est bien parce qu'il n'a jamais dit que cela fonctionnait en général mais que globalement DX9 était bien supporté et que pour DX10/11 cela s'améliorait.

Bref, il n'y a aucun rapport entre DX9/10/11 et les applications .NET, Metro ou même les applications et jeux récents (DX9 ça date quand même).
Du coup c'est bien ce que je dis, tu critiques en étant totalement à côté de la plaque. Tu lui repproches des propos qu'il n'a pas tenu. C'est tout.

Ouais enfin si tu coupes la phrase est milieu, tu perds un peu l'information qui disait exactement ce que tu disais…

Avant 2009 tu avais pleinement raison. La Gendarmerie n'était que sous l'égide du ministère de la Défense.

Je dirais que la situation actuelle est plus logique. Les gendarmes sont des militaires qui ont beaucoup d'activités similaires à ceux de la police mais souvent en campagne. Il semble normal d'essayer d'uniformiser un peu la gestion de la Gendarmerie et de la police.

Tu as déjà pris le TER en PACA ?

Le bus en PACA fonctionne mieux ?

Avant les cars macrons, les cars Marseille-Toulon-Nice ou au sein du départements sont pas mal utilisés pour contrer justement les retards et annulations des TER qui sont très nombreuses (pire région de France sur le sujet d'après les dernière étude).

Il faut comprendre qu'entre Marseille et Nice, tu as sur 200 km de trajet 3 agglomérations dans le top 10 de France en nombre d'habitants. On dépasse les 2.5 millions 500 milles.

Mais sur ce tronçon où tu as énormément de gens qui prennent le train quotidiennement pour aller bosser ou étudier (notamment aller de Toulon à Marseille), tu n'as qu'une voie par sens. Car la ligne de train étant située entre du relief et la mer, il est impossible de faire mieux (actuellement une 3e voie sera ouverte entre Nice et Cannes, mais guère mieux).

Et sur ce tronçon, tu as énormément de TER car le volume est important (et devrait augmenter pour absorber le besoin prévisionnel de la région) mais aussi les TGV bien pratiques pour relier Paris rapidement.

Or, les TGV sont prioritaires (car cela coûte plus cher et que l'utilité du TGV est la rapidité), donc si un TGV déboule, faute de voie, le TER doit patienter en gare ou s'y arrêter si ce n'était pas prévu pour faire la place. Ce qui occasionne bien des retards, mais les TER sont souvent en retard car à cause de la fréquence élevée du bousin le moindre retard fait une cascade de retards. Et bien entendu, le moindre soucis (intempéries, vol de câbles ou accident quelconque), c'est la catastrophe.

La seule solution est d'ouvrir une autre ligne dédiée aux TGV pour alléger le trafic. Voire de le seconder pour y mettre des TER aussi. Mais bon, les agriculteurs et autres écolos de la région trouvent ça pas terrible et cher mais ne proposent pas mieux. Résultat la LGV n'est plus en projet avant 2030 (si elle se fait) et bonne chance pour rénover le tronçon ou améliorer ses conditions en l'état.

En attendant, les cars, prennent l'autoroute et il y a moins de soucis car cela est plutôt bien dimensionné (car il y avait de la place).

EDIT :

Et malgré tout cela, pour parcourir Marseille-Toulon, la voiture malgré les péages coûte moins cher !

les cars Macron ne sont pas à l'heure

Le train et le covoiturage non plus.
Tu as déjà pris le TER en PACA ? Quand c'est à l'heure le champagne saute, quand ce n'est pas annulé on est content.

pas confortables

Tu trouves le train, l'avion ou le covoiturage confortable ?
Alors peut être quand la voiture du gars est bien, ou en TGV, mais en TER…

parfois mal fréquentés

Mal fréquentés dans quel sens ? La racaille ?
Tu as déjà pris le TER ? Tu trouves que c'est un endroit qui respire le civisme ? Et je ne te parle pas des conducteurs en covoiturages super pas agréables pour un sous.

lents (et évidemment moins écologiques et plus dangereux).

Peut être le seul réel inconvénient des cars. Mais certains ont du temps mais pas d'argent donc ce n'est pas un problème. C'est juste un autre publique.

Et je préfère une armée de cars sur les routes que l'équivalent en voiture. Que ce soit écologiquement tout comme d'un point de vue sécurité.

Donc oui si c'est ton unique possibilité financièrement, tu vas les prendre, mais sinon, tu vas les fuire

Et cela concerne pas mal de mondes.
Cela permet aussi d'alléger un peu le train et l'avion pour les trajets de pointe (genre les vacances) où les prix flambent à cause de la demande.

Les gens qui veulent éviter le train préfèrent le co-voiturage

Hum, non.
Il faut comprendre qu'on ne prend pas le car, train, co-voiturage, avion ou voiture pour les mêmes trajets et les mêmes contraintes (économiques comme personnelles, le covoiturage en famille nombreuse c'est plus compliqué que le train).

Une vraie mesure de gauche aurait été de baisser le prix de train (au moins pour les plus modestes), pas de fournir un service dégradé.

Le tout train est une bêtise, de même que le tout train, le tout avion ou le tout voiture. Une bonne offre de transport c'est une offre diversifiée pour répondre à des besoins différents de chacun.

C'est le début d'un marché, cela ne peut pas être rentable dès le début car il faut investir dans le matériel, le personnel et la publicité (et il faut du temps pour que les habitudes s'installent).

Même si les compagnies font une véritable guerre des prix pour imposer leur image et PdM pour l'avenir, les lignes peuvent être rentables avec des prix bien inférieurs au train pour bon nombre de trajets. Même si ce sera supérieur aux tarifs actuels très probablement.