Ubuntu souhaite créer un nouveau format de paquets pour installer des logiciels. Complémentaire aux .deb, il serait sous la forme d'une archive indépendante des dépôts contenant toutes les bibliothèques nécessaires au fonctionnement du logiciel, à l'instar de ce qui se fait dans d'autres systèmes d'exploitation : voir les .pbi sur PC-BSD, les .dmg sur OS X, les APK sous Android ou même les logiciels pour Windows.
Les raisons de ce nouveau projet sont multiples :
- Dans le cadre des applications pour mobiles, Canonical souhaite faciliter le plus possible le travail de développeurs pour les encourager à créer des applications pour Ubuntu Touch. Dans ce cadre, le travail de maintenance via les .deb et les dépôts n'est pas toujours facile à appréhender et peut demander un travail qui peut s’avérer long dans le cas d'une petite application ;
- Ubuntu Touch devrait inclure également un système de bac à sable pour les applications tierces, visant à isoler ces applications du système et n'autoriser l’accès qu'à certaines ressources. Comme ce qui se fait actuellement sous iOS ou Android ;
- La maintenance des applications sera également plus simple, car elles n'auront pas forcément à suivre l’évolution des bibliothèques présentes dans le système.
Les seules dépendances seront celles liées au cœur d'Ubuntu et aux API fournies via le SDK basé sur Qt. Ce nouveau format sera en quelque sorte une option supplémentaire pour les développeurs, que ce soit pour les applications libres ou propriétaires.
NdM : merci à MTux pour son journal.
Aller plus loin
- Journal à l'origine de la dépêche (217 clics)
- Methods for Portable Applications on Linux (http://hacktolive.org/wiki) (merci à Misc pour le lien) (43 clics)
- App installer design: click packages (Colin Watson) (36 clics)
- ApplicationConfinement (wiki.ubuntu.com) (33 clics)
- GNOME developers plan "Linux apps" (The H Open ) (48 clics)
# Miam
Posté par Etienne RABY (site web personnel) . Évalué à 10.
Miam les failles de sécurité dues aux différentes vieilles version de libs qui vont stagner un peu partout sur l'OS. Les efforts auraient peut être du se porter sur une simplification des procédures pour créer des .deb.
Après ça simplifiera la vie des dev pour pondre des appli rapidement, c'est indéniable…
[^] # Re: Miam
Posté par saltimbanque (site web personnel) . Évalué à 4.
tout dépend de "Ubuntu Touch devrait inclure également un système de bac à sable pour les applications tierces"
[^] # Re: Miam
Posté par seb24 . Évalué à 2.
Non y'a justement le bac a sable pour que l'appli ne fasse rien d'autre que ce qu'on lui a demande.
Perso je vois ce système comme une solution pour les devs qui veulent pas faire une grosses applications. Ca leur permet de gagner du temps.
Ceux qui veulent faire un truc plus complet seront plus a même de prendre un peu de temps sur le packaging propre.
[^] # Re: Miam
Posté par Loïc Ibanez . Évalué à 6.
Voilà, ce type de commentaire c'est ce que je reproche souvent à Linuxfr : une vision totalitaire, conservatrice et archaïque de l'informatique.
Comme si un ordinateur c'était forcément un CPU, un disque dur et un ou plusieurs OS en multiboot forcément installés en R/W sur le disque dur. C'est à dire l'IBM PC AT des origines.
Ce que tu viens d'écrire est une des visions possibles de la sécurité ( qui plus est totalement dépendante des développeurs des libs pour la correction des failles de sécurité - ce qui est absolument inacceptable pour moi ). La sécurité est ici déléguée à des tiers jugés "de confiance" : développeurs de libs et réalisateurs de paquetages logiciels.
Imaginons la situation suivante : 3 CPU en load balancing et un OS en read-only. En permanence 2 sur les 3 fonctionnent et le 3ème est en situation de reboot. Imaginons que l'on cycle le reboot de l'OS sur chacun des CPU toutes les 2 mn ( si 2 mn est le temps de reboot de l'OS sur le CPU ): dans le pire des cas une faille de sécurité ne peut être exploitée que pendant 6 mn. Et un Hacker ne fait pas grand chose en 6 mn. Sauf s'il sait PRECISEMENT ce qu'il cherche. Et toutes les 6 mn il va devoir réitérer son exploit de 0. A mon avis il va être vite dégoûté…
C'est une autre vision de la sécurité qui ne repose pas sur la rapidité de correction des failles de sécurité mais sur l'impossibilité de les exploiter efficacement.
Celui qui mise uniquement sur les patchs et correctifs de sécurité n'a pas vraiment besoin de sécurité…
[^] # Re: Miam
Posté par dyno partouzeur de drouate . Évalué à 8.
Je pense que rapidement le
hackerpirate va comprendre ce qui se passe et empêchera le reboot.A moins que ton OS tourne dans un container type hyperviseur qui contrôle le reboot, une fois que le méchant est passé root il est le roi du monde.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9. Dernière modification le 28 juin 2013 à 11:37.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Miam
Posté par Loïc Ibanez . Évalué à 1.
C'était un exemple rapide et non développé, un peu comme le commentaire que j'ai critiqué, assez - et avec du recul trop - vertement j'avoue.
L'architecture proposée n'est valable que pour des applications très particulières - multithreadées, sans état, etc etc… c'est sûr qu'il ne s'agit pas de faire tourner Libreoffice !
Mon objectif était avant tout de sortir de la pensée unique qui consiste à dire sécurité = mises à jour.
Petite piqure de rappel.
[^] # Re: Miam
Posté par wismerhill . Évalué à 3.
Ça doit être marrant d'avoir les programmes qui s'arrêtent toutes les 6 minutes.
Une sorte de twitter du temps de travail.
[^] # Re: Miam
Posté par Misc (site web personnel) . Évalué à 4.
Pas vraiment. quand tu sais que pour exploiter une race condition, il faut faire parfois des tas d'essais, ou parfois pour contourner les canries, pour deviner une adresse, etc, les attaquants ont appris à faire ce qu'il faut, à savoir, des boucles. Si tu rebootes tout les 6 minutes, ç'est pas forcément grave. Sur un téléphone, il faut sans doute moins de 6 minutes pour te faire appeler un numero surtaxé à l'étranger, rendant rentable la chose. Et sur un pc, bah, 6 minutes et ensuite, il reste plus de trace, ça me semble être un bon deal. Voir pire, utiliser chaque cpu pour attaquer les 2 autres pour rester en permanence.
Donc le schema n'a de sécurisé que le fait qu'il soit inhabituel et non courant. Et on peut dire autant de "mettre ton repertoire windows sur D:/win32", qui arrète (ou du moins à l'époque, il y a 10 ans) une bonne part des malwares qui hardcodent des chemins.
[^] # Re: Miam
Posté par Loïc Ibanez . Évalué à 0.
Merci d'avoir compris ce que j'ai voulu décrire assez rapidement. Le "D:/Win32" m'a aussi rappelé de vieux souvenirs ;-)
C'est aussi une des raisons pour laquelle je suis très défavorable à la LSB : si tout le monde range ses bijoux dans la boîte à bijoux de la salle de bain les cambriolages durent moins de 10 mn - et les chances de se faire prendre sont faibles. Si chacun range ses bijoux dans un endroit différent c'est beaucoup plus difficile… et le risque pour le cambrioleur augmente à chaque minute, ce qui a de bonnes chances de le faire renoncer.
Donc et pour revenir au sujet de l'article je suis très favorable à ce nouveau format de paquet.
# C'est plus facile de travailler salement…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 27 juin 2013 à 10:55.
Ah ben oui, forcément : travailler proprement, avec des bibliothèques partagées et tout les avantages que cela implique (économie de place, de mémoire, mises à jour de sécurité), c'est contraignant. Il est bien plus facile de travailler salement…
Accessoirement, ce point-là n'est pas du tout une justification pour un nouveau format de paquet, on peut très bien faire des paquets Debian crados avec toutes les bibliothèques et données incluses et tout mis dans un répertoire de
/opt.[^] # Re: C'est plus facile de travailler salement…
Posté par Artefact2 (site web personnel) . Évalué à 7.
N'oublions pas qu'on parle de Canonical, où on préfère refaire des roues carrées juste parce qu'au moins, elles n'auront pas été inventées ailleurs. (Je te pointe du doigt, Mir.)
[^] # Re: C'est plus facile de travailler salement…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ah, mais des roues carrées ça marche très bien, sur un sol correctement ondulé !
[^] # Re: C'est plus facile de travailler salement…
Posté par NilugeKiWi . Évalué à 6.
Ça complexifie quand même sacrément les virages cette histoire…
[^] # Re: C'est plus facile de travailler salement…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Mmmh, on doit pouvoir concevoir une piste adaptée pour les virages : en fait il suffit de faire une piste pour chaque côté de la voiture, puis d'assembler le tout.
Mais bon, quelle idée d'utiliser des engins à quatre roues aussi ? Passez donc au vélo, on n'a pas ces problèmes-là !
[^] # Re: C'est plus facile de travailler salement…
Posté par Benjamin Verhaeghe (site web personnel) . Évalué à 2.
En fait si, Il y a les même problèmes pour le vélos: Au moment du virage, il faudra diminuer la périodicité (ou la taille dans le sens horizontal) car l'axe de la roue avant ne sera plus perpendiculaire au sens de la route…
Maintenant reste à imaginer si la roue arrière va suivre et comment: Suit-elle le même rayon de courbure de la trajectoire au même endroit?
[^] # Re: C'est plus facile de travailler salement…
Posté par Spyhawk . Évalué à 5.
On pourrait utiliser des routes avec virage à angle droit pour résoudre tous ces menus problèmes! :)
[^] # Re: C'est plus facile de travailler salement…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Et imaginer des roues appropriées pour tourner souplement à angle droit ?
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à -7. Dernière modification le 27 juin 2013 à 18:11.
2 poids, 2 mesures … On rale après Ubuntu lorsqu'ils font un truc nouveau, et ces mêmes personnes encensent Redhat et ses employés pour une bouse immonde comme systemd.
[^] # Re: C'est plus facile de travailler salement…
Posté par 태 (site web personnel) . Évalué à 6.
Quoi ? Il existe des gens qui encensent Redhat pour systemd ? Non, pas sur linuxfr !
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à -2.
oui, et qui moinssent lorsqu'on leur fait la remarque …
[^] # Re: C'est plus facile de travailler salement…
Posté par cedric . Évalué à 5.
Peut etre parce que Mir, c'est Ubuntu only (Va falloir compte le nombre de contribution externe non paye par Ubuntu) alors que Systemd a reussi a avoir le soutien de plusieurs distro et de beaucoup de developpeurs… Apres que tu sois grincheux et que tu n'aimes pas systemd ne va pas en faire une mauvaise solution technique, contrairement a Mir qui est juste une enorme betise (Protocol pas stable, pas de reflexion sur les inputs, la securite et un paquet d'optimisation necessaire pour baisser la conso).
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Vous voulez dire que si une distribution veut se passer de systemd il le pourra sans soucis ? :D
Sur le court terme, oui, sur le long terme permettez moi d'en douter.
Prenons un exemple:
PulseAudio est une application importante, et est du même auteur que systemd.
Qui nous dit que dans le futur, la dépendance pour PulseAudio ne sera pas systemd uniquement ?
En d'autres terme, si on veut réussir, il vaut mieux se préparer maintenant à systemd, et RH a été assez intelligent pour le comprendre.
Et je n'ai pris que l'exemple de PulseAudio, mais il suffit de réfléchir un peu pour comprendre que l'impact est énorme.
Comme je l'ai dit, ce n'est pas l'idée sous-jacent de systemd qui est mauvais, mais bien le fait qu'une seule entreprise la contrôle entièrement et je pense que l'erreur d'ubuntu c'est de suivre ce même schéma avec mir entre autre.
Quand je dis contrôle entièrement, cela veut dire que même si les développeurs sont nombreux au final, la décision est faite par un seule personne (ou quelques uns) mais qui sont avec RH.
De toutes les façons, un nouveau "init" linux-centré est toujours mauvais pour l'image de linux…
(Ca ne peut pas marcher avec du BSD, notamment parce que la licence est problématique à ce que j'ai compris)
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 1.
Je te rejoins sur les autres points mais pas sur celui-là. Le problème majeur de systemd pour moi est que contrairement à un init qui se suffit à lui-même, systemd dépend de plein d'autres trucs, et tente de réunir en un seul éléments des choses qu'il vaut mieux gérer séparément. Le second problème est que systemd est intrusif vis à vis des applis qu'il controle. Aujourd'hui, ce n'est pas obligatoire, mas à terme est-ce que ça sera toujours le cas ? Je n'y crois pas. En tout cas j'espère que les développeurs feront les choses intelligemment, et qu'ils laisseont les distribs géer l'intrusion de systemd danns leurs applis.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -9.
Ah pardon, j'avais oublié qu'il tente de tout contrôler à la windows avec son système de registre.
Sur ce point là, oui c'est très mauvais.
Le cours de sécurité informatique que j'avais eu disait entre autre qu'il fallait séparer au maximum, surtout les services.
Et en regardant ce qui se passe, la séparation est vraiment justifié. Merci au prof.
Par contre, je ne savais pas que systemd dépendait d'autre chose… c'est une colle là.
A part, cgroup, les dépendances sont-elles nombreuses ? Et lesquelles s'il vous plaît ?
(Je pose la question parce que justement je voudrais savoir dans quoi on entre d'avance)
Merci de m'avoir rappelé ce que j'avais oublié. (bourde)
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 3.
Par exemple : http://packages.debian.org/wheezy/systemd
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 8.
2 poids, 2 mesures… Moi qui croyais que les amateurs de Linux préféraient la réutilisation plutôt que de réinventer!
Si tu as une meilleure solution pour répondre au besoin tout en respectant cette phrase, n'hésite pas, propose!
En attendant, c'est du FUD, d'autres pensent justement le contraire et eux ont quelque choses à proposer, contrairement à de la super-théorie inexistante en pratique.
J'ai l'impression que ce que tu critiques, c'est que systemd réponde au besoin.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 0.
Je suis loin d'être un amateur aveugle de linux : d'ailleurs, techniquement parlant, je préfère les xBSD.
Sinon, on en revient à la base même de ce journal : ceux qui pense qu'l faut tout mutualiser et tout factoriser, et ceux qui pensent au contraire que tout doit être séparé. Pour ma part je pense me situer un peu entre deux : je suis favorable à la réutilisation, mais pour un truc de bas niveau comme l'init, je préfère qu'il ne dépende pas des bugs des autres …
Sysemd m'aurait convenu à au moins 1 condition : comme surcouche à l'init classique en laissant l'init de base démarer les couches vitales de l'OS. Ensuite côté userland il peut faire ce qu'il veut, je m'en moque. La deuxième condition pour moi serait d'être un peu plus modulaire et de ne pas vouloir faire tout ce que font les autres composantes du système, et ne se contenter que de démarrer et arrêter des composants. Mais qui sait, peut-être que systemd évoluera dans ce sens à l'avenir ?
C'est à dire ? je ne te suis plus là.
Quel besoin ? Je pense que justement tout est dans la définition du besoin …
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 7.
Ouais mais bon si tu adores faire des scripts illisibles et difficiles à maintenir pour avoir ton init chéri qui a du mal à gérer nombre de situations, c'est ton choix mais pas tout le monde n'a envie d'avoir ça.
Systemd permet d'avoir pour toutes les distributions le même mécanisme de démarrage sans refaire els mêmes bidouilles mais différemment. La main d’œuvre manque cruellement pour qu'on puisse éviter ce surplus de travail.
systemd peut lancer des scripts init si tu veux…
Peut être aussi que simplement démarrer ou arrêter des services ne répond plus au besoin d'aujourd'hui ?
Je suppose qu'il voulait dire que bizarrement il y a des gens techniquement bons qui ont décidé de l'inclure par défaut dans leurs distributions (oui je suppose que le gars qui a inclus systemd dans OpenSuse et compagnie n'est pas un incompétent) alors que c'est une "bouse".
C'est bizarre quand même, comment des gens aussi bons techniquement (et sans doute plus d'expérience que nous dans ce domaine) peuvent se planter à ce point sur ce qui est puissant et intéressant ou pas ?
C'est bien qu'il y a des problèmes quelque part (que tu ne rencontres peut être pas mais que d'autres peuvent rencontrer et qui sont réellement embêtants).
Et beaucoup de distributions ont abandonné init ou sont en voie de le faire faute de maintenance, pourquoi un truc si bon a du mal à trouver des personnes pour réaliser cet effort ?
Tout le monde a des besoins différents.
Le problème c'est que nombre de personnes sont persuadés que son besoin propre est supérieur à ceux des autres. Ici systemd répond à des besoins de nombreuses personnes et entreprises car l'init d'il y a 30 ans n'était pas adapté à la conception de l'informatique moderne.
Peut être qu'il ne répond pas à ton besoin mais qui peut le plus peut le moins et systemd peut rendre le comportement précédent identique si tu le souhaites (il supporte les scripts init).
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 2.
Je vais te faire un procès pour violation de copyright sur cette forme de réponse ;-)
Merci d'avoir écrit ma réponse, je gagne tu temps.
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 0.
Ceci n’est pas un argument. Je résume ce que tu as écrit : « c’est vieux donc c’est nul ».
On attend toujours les besoins « modernes » auxquels FreeBSD ne peut pas répondre (puisque ces abrutis de devs FreeBSD n’ont pas vu La Lumière et s’obstinent à utiliser un truc pas adapté à l’informatique moderne, les cons)
[^] # Re: C'est plus facile de travailler salement…
Posté par claudex . Évalué à 6.
L'argument qu'il donne, c'est « Les besoins de certains ont changé », l'init traditionnel répond toujours à plein de besoin mais pas tous.
Mettre les processus d'un service dans un cgroup pour limiter les ressources auxquels ils ont accès et être sûr de bien tuer tous les processus lors d'un arrêt du service. Démarrer des conteneur LXC à la demande pour éviter le gaspillage de ressource.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 6.
LXC et les cgroup il y a l’équivalent avec les jails sous FreeBSD, ils ont pas eu besoin de jeter leur système d’init « complètement dépassé ».
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -8.
En effet, Jails est grossomodo le LXC de freeBSD il me semble
Je suis toujours surpris lorsqu'on parle de linux et que l'on veuille comparer à freeBSD.
Il est évident qu'à part quelques exceptions, freeBSD a tout ce qui existe sous linux.
Je pense même qu'ils ont l'équivalent d'un CGroup mais c'est juste qu'on ne sait pas.
Par hasard pourriez vous nous en parler ?
Au moins, le système d'espace de nom du noyau c'est comment ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Les philosophies sont différentes, et il n’y a pas forcément d'équivalence 1 pour 1 à tout.
Par ex., il y n’a pas de clone de cgroup, mais pour répondre au même besoin on a rctl.
P.S.: on écrit FreeBSD, avec un grand F.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
Mais ça ne réponds que au besoin de "cgroups" pour les ressources, pas à cgroups pour grouper les processus ( ce qui est qur quoi systemd s'appuie ).
Et les jails ne sont pas non plus un équivalent comme lu plus tot, vu qu'un jail, c'est un container ( ie, linux namespace, lxc ).
Ceci dit, rctl a l'air très bien, je pense que ça mériterais un article dans GLMF pour que les gens connaissent un peu plus.
[^] # Re: C'est plus facile de travailler salement…
Posté par claudex . Évalué à 4.
Je n'ai pas dis que systemd permettait lxc et les cgroups mais qu'il tirait partie des fonctionnalités offertes pour fournir de nouvelles fonctionnalités.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 5.
Ou meme juste démarrer les services dans le bon ordre quand certains services dependent d'un autre. En theorie ca peut etre geré par les scripts d'init, mais en pratique ca marche souvent pas, avec plein de race conditions.
Ou pouvoir démarrer ou stopper de facon fiable un service. En theorie les scripts d'init sont censés gérer des fichiers de lock, enregistrer le pid du processus démarré, etc … En pratique la plupars des scripts d'init sont buggués. Et c'est pas étonnant, par ce que gérer ce genre de chose de facon correcte n'est pas simple.
Donc il n'y a meme pas besoin d'avoir des besoins « modernes » pour trouver un interet à systemd.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 8.
Si tu parles de façon général, et sans vouloir dire du mal de FreeBSD, je pense que la pile de virtualisation de l'OS est pas encore mature. Soit tu prends bhyve ( toujours en dev ), soit tu prends VirtualBox ( donc un module externe ).
Pareil, niveau module de sécurité MAC, je pense que FreeBSD est un chouia en retard sur une distribution comme RHEL en terme d'architecutre proche de FLASK, malgré la présence de nombreux modules des plus intéressants (http://www.freebsd.org/doc/en/books/handbook/mac.html) et d'une architecture correct pour ça. Mais c'est pas un besoin "moderne", c'est vrai.
FreeBSD note que son module Fuse n'est pas production ready, (https://wiki.freebsd.org/FuseFilesystem), donc si c'est encore vrai, ça exclue globalement le déploiement de choses comme Ceph ou Glusterfs, qui sont utilisés pour notamment des déploiement d'openstack et ou du big data.
Ensuite, parmi les besoins modernes, je pense qu'il y a des choses comme le fait d'augmenter la densité des containers, en lançant tout à la demande (http://0pointer.de/blog/projects/socket-activated-containers.html). Je ne pense pas que les jails permettent ça pour le moment.
(et ce besoin est directement corrélé avec des outils de PaaS comme Openshift, et le besoin croissant de faire du "self-service" et d'offrir des services aux départements de ta société.
Et je pense pas que les devs de FreeBSD soit des abrutis de pas avoir ça, c'est juste une question de ressources. On voit bien qu'il y a chaque fois des gens qui bossent sur des projets, on sait aussi qu'on peut pas être partout à la foi. Il y a une différence entre dire "je pense que j'ai pas besoin" ou "je pense que la complexité induite ne vaut pas le coup" et "je pense que personne n'a besoin de ça".
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 3.
Si tu es admin de métier et que n'es pas capable de lire/écrire des scripts, change de métier.
Justement, c'est ça qui ne me plait pas : je préfère que chaque distrib fasse comme elle l'entend, et je choisis ma distrib en fonction de mes besoins et de mes préférences.
Ce n'est pas le problème de base. Ma vision des choses : tout ce qui est couche basse du système (montage réseau, filesystems / /usr, /var, et autre trucs nécvessaires à un système minimal) devrait être géré par un truc simple comme init. Pour tout ce qui est process applicatif, je m'en moque. Systemd ne m'aurait pas gêné" plus que ça s'il s'était contenté de se lancer en init 3 avec gestion des dépendances, etc … pour tout ce qui est couche applicative. En fait systemd m'aurait intéresé s'il avait fait un truc de ce genre :
- ne pas toucher à init (ou très peu) pour les composants de base
- prendre la main en init 3 et démarrer les services comme le fait par exemple RedHat Cluster (en travaillant un peu sur la parallélisation des services et en virant le fichier de conf xml).
Ces gens sont peut-être de très bons développeurs, mais ce ne sont pas des gens qui ont a gérer des serveurs de prod tous les jours.
Tu veux maintenir quoi sur init ? C'est un pauvre process qui a fait ses preuves et qui fait son travail correctement depuis des années. Pourquoi le changer, au moins pour les couches basses ?
Non, nombre de personnes est persuadé que son besoin est le besoin des autres. Les besoins d'un serveur de prod ne sont pas les mêmes que ceux d'un desktop. Et autant systemd ne me dérange pas plus que ça sur un desktop, autant ça me gène sur un serveur. L'exemple tout bête est cette manie des distribs de vouloir cacher les message de démarrages du noyau et des services au boot. Sur un desktop, poutrquoi pas mais sur un serveur ça n'a pas de sens :a chaque fois que je dois redémarrer une redhat ou une CentOS et que quelque chose se passe mal, je dois rebooter, interrompre le boot du grub, et modifier les options quiet et rhgb. Perte de temps, et surtout c'est le genre de manip que je ne peux pas demander à faire à un opérateur à distance dans le cas ou je n'ai pas d'accès à une console distante.
Je ne supporte pas la phrase que j'ai mis en gras et qui ne veut rien dire.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
Non je suis développeur mais je m'intéresse aux problématiques des distributions également.
Mais bon, si tes scripts font des trucs bidons, c'est facile de les relire, je te signale que certains ont peut être des problématiques plus complexes à gérer…
Donc tu veux que les distributions soient incompatibles entre elles et passe un temps fou à gérer ces scripts, les déboguer tout ça ? Elles ont peut être d'autres préoccupations.
Peut être que eux reçoivent des rapports de bogues ou des demandes de personnes qui ont à gérer des serveurs dans des cas où init est impuissant ?
Peut être que tu n'es pas le centre du monde et que tu pourrais admettre que d'autres personnes ont des besoins différents même pour un serveur ?
Ce n'est pas init qui est chiant en lui même, ce sont ses scripts associés ce qui en soit revient au même car c'est lié.
Avec systemd tu simplifie ce travail énormément et les distributions apprécient ce gain de temps.
Peut être sur tes machines mais sur d'autres serveurs c'est super utile.
Moi quand systemd plante j'ai accès aux logs directement sans rebooter via journalctl et je peux y avoir accès après si jamais le boot est allé au bout malgré les problèmes.
/var/log/messages et compagnie sont toujours accessibles aussi.
Au final c'est quoi ton problème ?
En tant qu'admins systèmes tu es censé connaitre les outils que tu as à ta disposition pour les utiliser au mieux et tu ne sembles même pas savoir lire un journal d'erreurs avec systemd…
Bah si, systemd pouvant lire tes scripts init tu peux repartir sur le fonctionnement précédent avec tes scripts d'amour.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 6.
Donc tu n'auras aucun problème à le maintenir, c'est quoi donc la critique sur systemd puisque ça ne va pas te déranger de maintenir en parallèle un truc qui a fait ces preuves?
A moins que…
Aucun problème si c'est toi qui gère toute cette merde. Tu ne te proposes pas? Pourquoi les autres se feraient chier pour toi?
et RedHat ne fait pas de serveur de prod, mais bien sûr… non, ton besoin est juste "bizarre", je serai tenté de parler de résistance au changement…
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 3. Dernière modification le 28 juin 2013 à 16:22.
Tu veux dire quoi là ? Que je n'ai qu'à écrire mes scripts de démarrage ? C'est ce que je fais pour mes scripts applicatifs et je n'ai pas de problème.
Ah, c'est bien une réponse de développeur ça. Mon besoin n'est pas bizarre : quand tu as un serveur en vrac tu dois pouvoir accéder rapidement à celui-ci pour le remettre en branle. Sous Linux avant systemd, avec un init qui ne dépend de personne, rien de plus simple. Avec systemd qui est un gros bloatware qui gère les couches basses et qui dépend d'autres trucs, , je n'ai plus cette garantie.
Et moi je gère des servuers de prod depuis plus de 10 ans, et des serveurs qui ne redémarraient pas, j'en ai eu à la pelle, et bien heureux de pouvoir suivre pas à pas les services démarrés pour voir ce qui cloche.
Comme dit plus haut, je n'aurais rien contre systemd s'il gérait que la partie userland. Mais on en reparlera dans quleques temps.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 4.
Non, c'est que les développeurs n'ont pas envie d'écrire les scripts de base pour init pour toutes les applications et limiter au maximum les bogues avec tout en étant fonctionnel pour la plupart des situations.
Comme tu dis que c'est facile de le faire, tu te présentes quand pour le faire au niveau de ta distribution ?
Mais je te rassure que les rares cas où j'ai du le faire avec systemd j'ai pu le faire sans difficulté.
J'ai pu analyser l'erreur, lancer un bash minimal pour faire les modifications et reprendre le cours.
Tu as des exemples réels ou c'est de la pure supposition ?
Bah oui mais d'autres ont peut être d'autres besoins que les tiens depuis 10 ans aussi…
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 28 juin 2013 à 16:32.
Si il faut traduire : que ce que tu préfères n'est pas aussi simple que tu le dis, mais bon, tu veux que les autres gèrent le bordel pour toi, et les autres ne veulent plus.
TU dis que c'est simple, tu n'auras aucun problème donc à maintenir l'ensemble. Si tu ne peux pas, c'est que tu as dit une connerie.
L'argument d'autorité! Mais je dirai : c'est peut-être le problème. Il y a des gens qui voient que ça merde, et corrigent la merde. alors forcément, les "anciens" doivent apprendre de nouveaux, évoluer, et se retrouve au même niveau de compétence technique que les nouveaux (la haine…)
Sérieux, faut arrêter ce genre d'argument : c'est le genre de truc à énerver plus qu'autre chose, et à faire conclure que le problème est la sénilité. Heureusement pour l'évolution de l'humanité que des gens ont dit "merde" à des gens disant que ça fait 10 ans qu'ils font comme ça, que ça merde mais ils connaissent comment corriger (les nouveaux font ce qu'il faut pour que ça merde moins :-D ).
Les usages, même serveur, sont différents entre il y a 10 ans et aujourd'hui, un admin qui n'évolue pas en fonction de la demande utilisateur est voué à dégager…
Je ne pense pas qu'on en reparle, du simple fait que preque tout le monde aura adopté systemd, que ça marchera très bien, et que les "anti" éviteront de se la ramener pour ne pas avoir la honte (ou auront changé de métier).
Rien de nouveau, des tonnes de livres ont étés écrits sur la résistance au changement.
(je n'avais pas voulu enfoncer le clou tout de suite, mais tu l'as cherché avec ton argument d'autorité "moi je depuis 10 ans")
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -3.
Et pourquoi on devrait se faire chier parce qu'un dev (lennart) est persuadé d'avoir la réponse à tout mais refuse d'écouter tout ceux qui font de la prod ?
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 3.
LOL, systemd est loin d'être le seul fait de Lennart.
C'est RedHat, qui doit avoir, oh je sais pas, 2/3 serveurs de prod, qui est le premier client de systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 5.
RH utilise RHEL 6 pour ses serveurs et que je sache, RHEL6 n'utilise pas systemd, et ne l'utiliseras pas. Il faut attendre RHEL7
Par contre, moi, je fais de la prod, et je pense que lennart a au contraire écouté les admins. Plus besoin de me taper bash pour lancer un truc, y a des directives simples à configurer via un fichier .ini, ce qui est beaucoup plus script friendly les variables bash ( avec tout les cas tordus pour la gestion des guillemets et doubles guillemets, sans compter les usages créatifs de la syntaxe bash pour faire des $() et autre trucs qu'on retrouve parfois), y a des réglages unifiés qui font qu'on peut utiliser les fonctions de Linux sans se prendre la tête ( genre isoler un service du réseau, comme clamav ou spamassassin, le fait de pouvoir faire des instances d'un même service proprement ( genre openvpn, ça règle le souci des softs qui font des trucs dans stderr et dans les logs en mettant tout à un seul endroit.
Et ça aide à régler aussi le fait que tu peux donner à un admin junior la tache d'écrire une unité sans à refaire une imitation du cri d'Edward Munch en lisant le code qu'il a écrit.
Ça pose les bases pour avoir des containers efficaces (virt-sanbox-service), ce qui résous le problème de "je doit faire héberger des tas de trucs en masse, mais j'ai pas le budget pour des tas de machines".
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 28 juin 2013 à 21:51.
Ne pas t'écouter != ne pas écouter tout ceux qui font de la prod
Ah oui, zut, d'autres ont d'autres avis, et pas de pot leur avis compte aussi.
C'est un peu comme les gens qui hurlent qu'on n'est pas en démocratie quand le peuple décide autrement que la personne qui parle (on ne change pas les façons de dire "horreur on est en dictature").
T'es pas content? Fork et montre qu'il y a du monde qui veut autre chose. Oups, raté, personne ne s'y colle… (quelques projets par ci par la qui lâcheront bien vite, on le voit déjà maintenant qu'il n'y a pas foule qui adhère)
Parce que les mecs qui se faisaient chier à ta place n'ont plus envie (et surtout, ils ont mieux à proposer). Ce ne sont pas tes esclaves.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -1.
Ah ça me manquait tes ad hominem etc…
Je n'ai jamais écrit à lennart ni rien donc il risque pas de m'écouter :P
Mais je constate que nombre de voix se sont élévés contre systemd auparavant, par des gens bien plus "en vue" que moi (c'est pas très dur tu me diras).
Et que sur certaines critiques avec lesquelles j'étais d'accord (sur cette partie "prod") , aucune réponse satisfaisante n'a été apporté.
Et pour ton info, je travaille avec des pros-redhat et il y a de super produits sous redhat (spacewalk par ex).
Systemd a des intérêts. Mais si il y a des points criticables, pourquoi n'auront pas le droit de les critiquer ?
Il y a déjà un truc qui marche très bien. Pourquoi forker un truc qui existe déjà et fonctionne très bien?
AHAHAHA.
"Il n'y a personne qui s'y colle" .. "ah mais en fait si, mais c'est qu'ils sont trop nul c'est tout".
Comment dire tout et son contraire, ça me manquait ta prose
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 28 juin 2013 à 22:21.
C'est la rançon du succès : dès que tu as du succès, tu auras toujours des emmerdeurs pour dire que c'est horrible tout ça (et ça tue les bébé phoques).
On mesure alors le nombre de "contre" par rapport au nombre de "pour".
Et la…
Tu travestis ce que je dis. Personne oui, si il faut être explicite : personne qui laisse entrevoir un truc à long terme passé la résistance au changement, sur les distros pros "majeures" (même Debian risque de s'y mettre, ça craint!)
Et non les xBSD ne comptent pas du fait de leur faible utilisation, pour des trucs très précis (mais qui pourraient peut-être te convenir)
maintenant, je t'en prie, prouve-moi le contraire…
En attendant, je constate que systemd continue sa route en convainquant ceux qui doivent se taper la merde.
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 8.
Et pourquoi tu penses que tout un tas de distributions l'adoptent si c'est si mauvais et que tout le monde soit disant n'en veut pas ?
On peut avoir ces critiques ?
Les critiques de systemd que je lis sont toujours les memes, en general de la part de gens qui n'ont meme pas pris la peine d'essaier de comprendre le principe de systemd et se contentent de répeter les idioties qu'ils ont lu ailleurs.
Et sinon les mainteneurs de systemd sur debian on fait un sondage et répondu aux principales critiques :
http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html
Personne n'a dit qu'il ne fallait pas critiquer systemd.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -2.
Où j'ai dis "tout le monde" ?
Pour ta question, un peu comme PA, non ?
Sauf qu'il ne suffit pas de faire un remove de PA dans ce cas /o\
Le lien que tu as fournis est très intéressant.
Entre autre lorsqu'il dit "non mais les dépendances c'est pas grave il n'y en a que 10, et puis c'est bon (mangez en) les dépendances).
Il oublie juste un ou deux trucs dans le problèmes des dépendances :
- plus tu as de dépendances , plus tu as des risques qu'une merde à un moment ou à un autre.
- plus tu as de dépendances, plus tu as un risque dans la fiabilité du code.
(Tu as plus de chance de trouver au moins un bug dans 15 librairies, que dans une seule. Le dernier MISC avait un article très interessant sur du fuzzing sur adobe reader à partie d'une librairie qu'il utilisait).
Une des principales critiques que j'avais était le fait justement du bloatware.
Je n'avais pas vu qu'il y a bien de multiples binaires.
(fait une recherche systemd multiple binaries tu verras que l'information ne semble pas si répandu).
Maintenant est ce qu'il y a une véritable séparation ou est ce que les autres binaires peuvent faire ce qu'ils veulent avec PID 1 ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 8.
Je suppose que pour gerer tes serveurs à distance tu utilises telnetd plutot que sshd par ce qu'il y a moins de dépendances ?
L'argument du nombre de dependences pour mesurer la fiabilité du code est tellement stupide que je vois pas trop ce qu'il est possible de repondre à part que c'est débile.
T'as des exemples concrets de problemes de fiabilité du code de systemd ?
Avec systemd c'est un seul code qui gere le demarrage de tous les services, ecrit proprement une bonne fois pour toute, et testé intensivement puisque c'est utilisé par tous les services. Avec sysv init c'est chaque service qui réimplemente le code pour gérer le démarrage / arret du service, et generalement c'est mal fait. Si il y a un problème de fiabilité de code, c'est dans les scripts init à mon avis.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à -2.
On verra quand ton systeme ne redémarrera pas parce qu'une dépendance foireuse a tout pêté. Ah mais c'est vrai, Linux et le libre sont tellement fiable que ça n'arriv jamais.
Encore un argument débile : ce n'est pas parce que ce n'est pas encor arrivé ou parce que l'on a pas encore de remontées que ça n'arrivera pas. Systemd etat jeune, tu ne trouveras pas encore beaucoup de cas problématique.
Et quand ça ne marche pas tu isoles le problème sur un seul service, alors qu'avec systemd, en cas de bug, ce sont tous tes services qui se vautrent; Ah oui, j'oubliais. Systemd est si bien qu'il ne buggera jamais. L.P est trop génial et ne fait que du code qui ne plante pas.
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 7.
T'as une vraie raison de penser qu'une dépendance foireuse puisse tout peter, ou tout dit juste ca au hasard ? Bon en fait je pose la question mais je connais la réponse.
En gros "j'ai pas de problème concret à signaler, mais ca veut pas dire que ca n'existe pas !". Effectivement, on ne peut rien répondre à ca.
Ah oui, ne surtout jamais faire de libs, ou de fonctions dans le code: si il y a un problème ca affecte tout ce qui l'utilise. Dans le cas de systemd il parait evident qu'un bug va s'introduire du jour au lendemain et empecher tous les services de démarrer. La bonne solution, le copier coller de code ! Par ce que quand le code est copié collé, les bugs ne peuvent s'introduire qu'a un endroit à la fois, c'est evident. Mais pourquoi entend on generalement les gens critiquer le copier coller de code ? Pourquoi tous ces gens qui créent des librairies et parlent de réutilisation de code ? Incroyable ce que les gens sont ignorants et ne connaissent pas la vraie methode pour faire des programmes fiables !
Donc résumé des arguments anti systemd :
- aucun exemple concret de problemes, mais ce n'est pas parce que ce n'est pas encore arrivé que ça n'arrivera pas
- systemd fait de la réutilisation de code et c'est pas bien
Magnifique.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à -3.
Comme je le disais, c'est bien connu : une dépendance foireuse n'arrive jamais.
Entre autre, les dépendances foireuses ou un problème lors d'une mise à jour, ça arrive, et pas spécifiquement à systemd. C'est pas parce que ça n'est pas encore arrivé que ça n'arrivera jamais. Mais bon, linux et sstemd sont si bien faits que ça n'arrive pas. Continue à faire l'autruche si tu veux.
Come si ça n'arrivait jamais qu'une mise à jour d'une lib X empêche un logiciel Y de fonctionner parce qu'il tombe dans un cas de figure qui n'a pas été testé.
C'est sur qu'il vaut mieux utiliser 500 librairies différentes parce que j'ai 500 fonctions à utiliser qui sont implémentées dans ces 500 librairies. Brav l'arbre de dépendances.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 5.
On dirait le gars qui est en instance de divorce, et charge l'autre avec tout ce qu'il peut, quoique ce soit.
Etiez--vous très liés "avant"? Qu'est-ce que t'a fait systemd pour être aussi subjectif et haineux envers lui sans raison qui tienne l'analyse?
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à -2.
Ca ne tient pas ton analyse de développeur. Mais j'ai l'habitude de ce genre de conflits avec les développeurs qui veulent à tout prix passer en prod un code qui ne tiendra pas la route. Et dans 95% des cas (pour ne pas dire 99%), quan je dis que ça va planter, ça ne rate pas. Mais bon, j'espère quand même être dans le 5% des cas ou je me plante …
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 6.
En tout cas tu n'as pas prouvé par exemple que les scripts bash étaient invincibles non plus.
Gérer les dépendances de services, les contraintes de temps, etc. C'est la merde et ça peut planter et chacun va de sa petite méthode foireuse pour gérer le cas.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -3.
ahahaha
on explique ce qui pourrait être un problème potentiel à notre avis.
Au début on se fait insulter
ensuite on nous explique qu'on est trop con et qu'on comprend à rien.
Et maintenant c'est à nous d'expliquer par A+B pourquoi l'ancien système, qui n'avait pas cette contrainte, … ben n'a pas cette contrainte.
(ah en fait, sauf erreur de ma part, tu n'es pas limité à du bash, et de base on est même plutôt en sh, mais tu peux même faire un binaire statique).
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 4.
Généralement, quand on veut démontrer que l'un craint plus que l'autre, on a une démonstration que l'autre est "super-méga-génial".
Enfin, ça c'est quand on veut être objectif et non pas balancer du FUD genre "cette nuit, j'ai rêvé que systemd était plus pourri que SysV alors que je n'ai aucune démonstration sur la stabilité de SysV et que je ne compte pas en donner"
C'est beau ces "arguments" non démontrés juste pour FUDer… en tous cas, ça démontre que les "antis" non rien de sérieux à reprocher à systemd, juste des peurs de la nouveauté. Depuis la nuit des temps, l'être humain a dû se battre contre les gens qui sortent "c'est assez bien comme ça, ne risquons pas".
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -2.
euh non, on a une démonstration des avantages et inconvénients de chacun.
Pas une démonstration avec les meilleurs coté de l'un et les mauvais de l'autre.
(ce qu'on a actuellement).
Ce genre de "démonstration", ça c'est du FUD.
le genre de truc que tu raconte, c'est des divagations.
Oeil, paille, poutre.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 01 juillet 2013 à 14:21.
J'ai eu d'autres vies que le développement… Et d'autres sont des non développeurs et t'ont répondu. Mais bon passons.
Le code ne tiendra pas la route? tu ne cherches même pas à comprendre les autres, qui t'ont expliqué que ce que tu utilises actuellement ne tient pas la route (non, mais sérieux, oser affirmer que des scripts bash c'est super stable, il faut oser)! ca merde de partout, c'est lourd, la maintenance est très chiante, et il y en a qui en ont marre de toute cette merde.
Mais admettons, les autres admins et les autres mainteneurs de distros sont stupides à vouloir systemd, et quelques personnes éclairées ont le savoir ultime et savent que l'existant est meilleur, à coup d'exemples qui se font démonter mais ce n'est pas grave. On appelle ça plutôt ça la résistance au changement. ca arrive souvent, très classique, quand les compétences des gens deviennent moins utiles et que des petits nouveaux savent faire mieux pour "moins cher".
Bref, tu n'as aucun argument qui tient, et hors de question d'essayer de comprendre ce qu'on te répond.
C'était mieux avant
Essaye déjà de comprendre les réponses apportées.
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 2.
Un script bash qui plante ça finit rarement en kernel panic. Contrairement à un systemd qui plante.
C’est pour ça qu’on se tue à dire que c’est une mauvaise idée de déporter des fonctionnalités vers le PID 1. Un PID 1 qui démarre pas (à cause d’une lib pas trouvée) c’est tout simplement un OS qui démarre pas. Un script bash qui démarre pas son service à cause d’une lib manquante ? OSEF. Un PID 1 qui plante c’est un plantage de la machine complète. Un script bash plante ? OSEF.
Le problème n’est pas d’introduire des fonctionnalités et donc potentiellement des bugs, ça c’est une évolution normale à laquelle personne n’a rien à dire. Le problème est d’introduire des fonctionnalités et donc potentiellement des bugs dans le PID 1.
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 7. Dernière modification le 01 juillet 2013 à 16:29.
Un script d'init qui plante, c'est à comparer à une unité systemd qui plante, et ça ne provoque pas un kernel panic.
Systemd qui plante, c'est le même résultat que SysV qui plante : pas de boot.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -1.
oui c'est exactement ce qu'il a dit.
init -> peu de dépendances
systemd -> plus de dépendances.
On parle bien de systemd.
Ceux qui ont rajouté les scripts bash (et donc les unité systemd) c'est les aficionados systemd, pas l'inverse.
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 5.
Certes. Mais il n'y a pas que ça qui rentre dans la balance. Surtout que les dépendances peuvent se choisir lors de la compilation, et que toutes ne sont pas obligatoires.
SysV -> pas de standard entre les distributions. Langage de script qui est difficile à maitriser (notamment au niveau de la sécurité), bavard, et qui est inadapté. Inefficace : pour chaque script d'init, une instance de sh est lancée. N'est pas compatible BSD mais ne tire pour autant pas partie des fonctionnalités du kernel linux (cgroups, notamment). On est jamais sûr de tuer un service proprement (processus zombie, fichier PID à effacer à la main parce que le service n'a pas pu le faire, etc…). Pas de parallélisation. Pas moyen de lancer/arrêter un service à la demande (exemple : pas besoin de CUPS lorsque l'imprimante a été débranchée)…
systemd -> un seul fichier unit par service pour toutes les distributions. Moins de code, moins de chances d'erreurs, moins d'usage mémoire, meilleure maintenabilité. Utilisation mémoire comparable à celle de SysV. Fichier à-la-ini standardisé et documenté et facile à remplir. API entièrement documentée, aussi. Tire partie des capacités du kernel qui sont présentes depuis des années. On est sûr de tuer un service quand il y a besoin sans devoir redémarrer la machine. Le PID 1 n'est pas plus bloated que celui de SysV, vu que systemd est livré avec une soixantaine de binaires, remplaçables, indépendant les uns des autres (penser aux base-utils GNU : on est loin de toutes les utiliser, c'est pas pour autant que c'est bloated). Est compatible avec les shell scripts (et les quelques incompatibilités sont documentées). Est scriptable via DBus (qui a des bindings avec beaucoup de langages). Offre un journal centralisé, standardisé (par exemple au niveau des dates). Tout est fichier (cgroupfs). On peut réduire les fonctionnalités de systemd à la compilation (on peut faire en sorte que ce soit juste un système d'init et rien de plus : c'est prévu)…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 6.
N'importe quoi. Il n'y a pas de raison que systemd provoque plus de kernel panic que initscript.
Toujours le meme lien :
http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html
"Also note that systemd’s features are NOT all implemented in the binary which is PID 1. As explained in the dependency list, systemd consists of many cleanly separated binaries. So if a new version of systemd gathers an additional feature, this does not mean that your PID 1 will be bigger."
Et avec un lien vers la liste présise des dépendances :
http://people.debian.org/~stapelberg/docs/systemd-dependencies.html
Le kernel c'est encore plus critique que le systeme de boot, et pourtant chaque nouvelle version introduit des milliers de changements qui introduisent plein de nouvelles fonctionnalités, et personne ne rale pour ca…
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 6.
Je suis impressionné par tant de mauvaise foi dans le seul but de cracher sur un truc sans s’intéresser à la réalité et aux explications, juste par difficulté de s'adapter à la nouveauté.
Maintenant, on en est à comparer des choux et des carottes (deux niveaux différents, pourquoi n'as-tu pas comparé SysV à systemd et bash aux unités? Mystère…).
tu compares deux choses complètement différentes, tu nous prends pour des idiots qui goberaient une telle grossièreté? j'espère au moins que toi tu ne te fais pas avoir par de tels "arguments" et que c'est que pour essayer d'entuber les autres…
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
J'ajouterais, quand on est administrateur système d'expérience, n'est-il pas nécessaire de faire de la veille technologique sur l'ensemble des technologies de ce type pour au moins savoir comment cela fonctionne et évaluer l'intérêt de ces solutions ?
Car là il y a du monde pour traiter les développeurs d'incompétents pour parler de l'administration système et de ses outils mais il y a apparemment peu d'entre eux qui savent faire leur propre métier correctement.
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 5.
Et j'ajouterais egalement que si on a pas pris le temps de se renseigner un minimum sur le fonctionnement d'un outil, on est pas obligé de donner un avis dessus.
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 3.
Je me répète mais…
C’est ce que je fais. Sur certaines machines j’ai d’ailleurs adopté systemd bien avant qu’il devienne le système d’init officiel de la distrib, et j’étais sur d’autres systèmes d’init avant systemd (initng).
Mais bien entendu, dans le royaume des fanboys toute critique vient nécessairement des haters irrationnels, n’est-ce pas ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
Désolé mais quelqu'un qui nous fait croire que si systemd plante, tout le système va planter alors que l'essentiel du code est dans les unités de systemd qui n'ont pour la plupart aucune conséquence sur le système, c'est fort le café.
C'est le principe de base de systemd, ne pas comprendre ça c'est limite n'avoir rien compris au logiciel et on peut émettre de gros doutes sur la compréhension du reste…
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 1.
Bon, je vais m’arrêter là, ça sert à rien d’essayer de discuter avec des fanboys pour qui leur chouchou est parfait.
Pourquoi je compare les deux ? Il te suffit de relire le fil deux secondes avec ton cerveau allumé (autrement qu’en mode automatique « il critique certains aspects de systemd donc c’est un con »)
ps, merci pour moi) => questionnements sur la fiabilitéEt pour ceux plus haut qui disent « si sysvinit plante c’est KP aussi », je le sais merci, le truc c’est que le PID 1 dans sysvinit a moins de fonctionnalités (pas d’IPC via dbus par exemple), moins d’interactions utilisateur (on compare systemctl et telinit ?). Ça a nécessairement un coût en terme de fiabilité. Moi, tout ce que je dis, c’est que pour certains (type totof) les coûts surpassent les avantages, pour d’autres les avantages surpassent les coûts. Si ça c’est de la mauvaise foi, tant pis pour vous, je vais pas aller mentir et prétendre que les fonctionnalités supplémentaires viennent « gratuitement » juste pour vous faire plaisir.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 01 juillet 2013 à 18:31.
C'est rigolo de transformer "une personne pas d'accord avec toi" en "un fanboy".
Je ne fais que constater la volonté de ne pas changer son "argument" quand il se fait pourrir.
J'ai perso rien à foutre de systemd, je constate juste les commentaires non pris en compte…
Si c'était vrai, il y aura bien plus de monde à refuser systemd, surtout dans les distros "sensibles".
Non, la, on l'a vu, les coûts donnés sont archi-faux, donc la conclusion est fausse, normal.
Euh… OK, je te laisse avec tes fantasmes sur le sujet.
Je resterai toujours aussi impressionné sur cette mauvaise foi.
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 3.
Je suis d’accord.
Tout autant que transformer "une personne pas d’accord avec toi" en "réactionnaire qui déteste le changement"
Pour me dire que ma proposition est fausse, tu vas devoir me prouver qu’au moins une de ces deux propositions est fausse :
Bonne chance.
Juste une question : tu as déjà mis les yeux dans le code d’un de ces deux projets ?
[^] # La chasse aux bugs est mutualisée.
Posté par Sylvain Blandel . Évalué à 3. Dernière modification le 01 juillet 2013 à 19:17.
Comme systemd est utilisé (par défaut) par plusieurs distributions, la chasse aux bugs est mutualisée.
Je suis d'accord qu'un logiciel ayant plus de lignes de code a, potentiellement, des bugs plus nombreux, et je suis également d'accord que systemd est jeune. Mais il a un avantage : c'est un système d'init identique qui est utilisé par plusieurs distributions. Il y a ainsi plus d'utilisateurs susceptibles de découvrir ses bugs (par rapport à l'époque où chacune de ces distributions avait ses propres scripts d'init).
Sur redhat.com, on apprend que la version 7 de Red Hat Enterprise Linux utilisera systemd. L'entreprise Red Hat estime donc que systemd est suffisamment stable pour être lancé en production.
[^] # Re: La chasse aux bugs est mutualisée.
Posté par Moonz . Évalué à 1.
C’est aussi le cas du PID 1 de sysvinit (même s’il est vrai que tout ce qui est script bash genre rc.sysinit a tendance à changer d’une distrib à l’æutre).
[^] # Re: La chasse aux bugs est mutualisée.
Posté par Renault (site web personnel) . Évalué à 5.
Mais on arrête pas de dire que le problème de init n'est pas init lui même mais les scripts casses gueule à côté ?
C'est pareil pour systemd, la partie pour gérer uniquement le PID 1 est petit, ce qui est gros ce sont les unités et s'il y a un problème ce n'est pas dramatique. Et s'il y a un soucis avec la partie qui gère le PID1, ça se corrige rapidement aussi…
[^] # Re: La chasse aux bugs est mutualisée.
Posté par Zenitram (site web personnel) . Évalué à 4.
Avec une telle façon de voir, on ne changerai jamais rien.
sympa… Désolé, c'est une façon de voir qui fige, et ça donne pas envie. Tu es déjà si vieux pour vouloir tout figer?
Il y en d'autres qui ont envie d'évoluer… Et le font, ça tombe bien personne ne t'oblige à changer, tu peux garder ton ancien truc si tu as envie (c'est beau le libre).
Par contre, tu ne peux pas forcer les gens à faire le sale boulot pour toi, mais ça, c'est ton problème.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 1.
et le type qui plutot que de répondre sur tes arguments (entre autre augmentation de la surface d'attaque, etc…) ou de t'opposer un quelconque raisonnement cohérent t'explique que tes arguments sont "complètements stupides"
tu le classe où dans l'instance de divorce ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 6.
Tout comme il est bien connu que le systeme de scripts init n'a aucune dependance.
$ rpm -qp --requires initscripts-9.21-12.mga1.x86_64.rpm | wc -l
54
Donc initscripts a 54 dependances sur une Mageia 1. Ca doit vraiment manquer de fiabilité !
Ben oui, ca peut arriver, tout comme ca peut arriver pour les initscripts ou n'importe quel composant du systeme, rien de spécifique à systemd.
C'est generalement pas un problème pour les autres composants d'utiliser des dependances, je vois pas pourquoi ca le serait pour systemd plus que pour le reste. J'ai jamais vu personne critiquer openssh par ce qu'il a des dependances et que meme si il n'y a pas de probleme "c'est pas parce que ça n'est pas encore arrivé que ça n'arrivera jamais".
Toujours n'importe quoi, systemd est loin d'utiliser 500 librairies, ni une librairie par fonction …
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -1.
et si tu nous faisais un ldd sur init plutôt ?
Parce qu'on parle que du PID-1, pas des "unité systemd"
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 1.
ca fait toujours plaisir de parler avec toi.
Au moins j'aurais essayé, de mon coté, de ne pas être insultant.
Ce n'est pas le cas de tout le monde dans cette discussion.
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 9.
Voila, c'est donc ca les fameuses critiques ou "aucune réponse satisfaisante n'a été apporté". Des critiques de gens tellement bien informés sur systemd qu'ils n'ont meme pas vu qu'il y avait plusieurs binaires, ni lu l'une des 30 000 discussions precedentes ou ca a été expliqué.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 0.
heureusement que je t'ai dis de faire une petite recherche google.
Et on constate que tu n'en est pas capable, mais que tu est bien trop occupé a vouloir absolument "vanner" quelqu'un, sans chercher à comprendre quoi que ce soit.
Ouep, le level de linuxfr a bien diminué /o\
[^] # Re: C'est plus facile de travailler salement…
Posté par Sylvain Blandel . Évalué à 6.
Sur les machines que tu administres, pourquoi ne pas supprimer définitivement les options
quietetrhgbdans le fichier de configuration de ton chargeur de démarrage ?Concernant systemd : en cas de problème au démarrage, systemd peut ne démarrer que le strict minimum de services (c'est équivalent au runlevel 1 de SysV). Il suffit pour cela d'ajouter l'option
systemd.unit=rescue.targetà la ligne du noyau (pour être compatible avec l'existant, les aliassingleet1sont utilisables).[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 0.
C'est sur, tu ne feras plus de scripts de démarrage.
Mais bon ça sera toujours pas plus lisible, et en plus moins modulaire (ie tu auras des scripts de démarrage quand systemd ne sait pas faire un truc, et un démarrage à la systemd quand il sait gérer).
Tout comme system V ou l'init BSD.
https://xkcd.com/927/
Euhhh on parle de quel besoin là ? On parle toujours de l'init où on parle d'autre chose?
Si c'est l'init, on lui demande juste de démarrer ce qu'il faut, et d'arrêter ce qu'il faut.
Si j'ai besoin d'un watchdog parce que mon service se casse la geule "mais que je sais pourquoi" ce n'est pas censé être le problème de l'init (ton service est pas fiable, il est pas fiable : dans ce cas tu corrige ton service, ou tu établis un watchdog qui va vérifer des conditions qui font planter ton service (log par exemple)).
Si c'est du réseau … ben c'est le role du réseau, et d'un point de vue cybersécurité c'est une hérésie de mettre en place le système central de l'ordi (qui a donc TOUTE autorisation pour lancer des process sous n'importe quel utilisateur et avoir tout accès au matériel etc… (héritage des droits et transitions des rôles) une ouverture sur le réseau!
Ca me fait penser aux automates SCADA que l'on peut trouver ouvert sur le net.
Et les gens qui font ces systèmes ont exactement les mêmes propos que toi "on demande maintenant bien plus à un automate que juste faire un automate"
Conclusion, on sait griller des sous stations électriques par internet maintenant \o/
(test fait par la DHS de tête).
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 7.
Non, pas vraiment. Prends un script d'init bsd et mets le sur un linux, qu'on regarde comment ça marche bien. C'est pas parce que tu peux faire un script qui va marcher partout que tout les scripts marchent partout, ni même que l'intégration soit correct. Si tu veux suivre les coutumes locales, la config du script va aller dans /etc/default pour debian et consorts, et /etc/sysconfig pour RH et dérivé, et ailleurs pour suse, sauf erreur de ma part. Ou les BSD et arch.
Donc permet moi de dire que tu surestimes la portabilité, et que tu sous estimes le travail des packageurs à ce niveau. ( et l'imagination dont font preuves certains upstreams pour faire des trucs chiants à lancer correctement )
/sbin/init fait plus que ça. Il se charge aussi de tuer les process zombies qui se rattache à lui, de relancer si tu demandes ( respawn ), il gère les touches ctrl alt del, il gère le fait d'avoir courant coupé (via l'action powerwait, powerfail et consort ).
Je veux bien croire que les gens veulent un init minimal, mais ça fait des années que /sbin/init n'est pas aussi minimal et fait des trucs qui ne le regarde pas ( exemple, powerwait, powerfail ) , et bien sur, personne n'a jamais rien dit ni trouver ça anormal. ( et je parle pas de "refaire sa propre implémentation d'un système de message" via un pipe dans /dev, ce qui n'a rien à faire la d'après la FHS, sauf si ça rentre dans "special file" et ça me semble être vraiment tirer par les cheveux comme raison, car "un pipe pour communiquer avec l'userspace", ça n'a rien de spécial ).
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 1.
Ce n'était pas le but de mon propos.
init V et systemd n'ont jamais eu pour but de remplacer LSB ou l'intégration des mainteneurs.
Suivants les distribs/… certains soft sont packagé dans /usr/share, ou dans /opt/ ou dans …
tu vas me dire que systemd va deviner tout seul quand le service à gérer est dans /opt plutot que le /usr/ classique ?
J'ai comme du mal à le croire, je ne sais pas pourquoi.
Ou alors je ne confond pas le rôle du système de démarrage avec le role du mainteneur et de la distrib.
Si la distrib ont décidé de changer les répertoires utilisés, systemd ne vas pas les deviner tout seul. Il faudra dans ce cas packager correctement et tu auras du taff à faire, systemd ou init V
Pour les process zombie ok, mais d'un point de vue hierarchique c'est le seul qui peut le faire aussi.
sur ctrl+alt+del, et les powerwait/… tu ne peux pas me dire que ça n'a pas de lien avec l'arrêt/démarrage des services, même si je suis d'accord que d'un point de vue modulaire, ça devrait faire l'objet de services à part.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 6.
init V non. Par contre, systemd a pour but aussi d'unifier les services entre distributions. Par exemple, en offrant une API documenté pour changer la locale ou le nom d'hote, et pas des détails purement historique comme le fait d'avoir un fichier avec un chemin différent pour le nom d'hôte. De la même façon, un fichier .service va marcher de la même façon partout. un service a besoin de charger un module va pouvoir le faire de la même façon en posant le fichier dans /etc/modules.d/ avec une syntaxe défini.
Et du coup, tu peux pousser ça upstream tout comme tu peux pousser upstream le fichier .desktop pour que tout le monde s'en serve.
Les autotools et grosso modo tout les trucs du monde ont de quoi faire des templates. C'est déja ce qui fait pour les .desktop justement.
bien sur j'ai jamais dit qu'il n'y avait pas de raison à ça. Juste que l'image d'un init qui lance juste les services est un chouia incomplète, init fait grosso modo 4 fois plus que ça.
Mais justement, ça fait déjà l'objet de service à part comme acpid.
Et à ce moment la, se charger de lancer de façon propre un service ( ie, mettre les namespaces si besoin, faire le setuid si besoin ), ça rentre aussi dans l'arrêt/démarrage des services. Mais pourtant, quand systemd le fait, c'est bloated, quand c'est init, ç'est normal.
Ensuite si tu trouves que systemd fait trop, la question est de savoir si le binaire de systemd fait trop, ou si le fait d'avoir tout dans le même git est un souci. Si c'est le second, on te dira que les BSDs font ça aussi, et personne ne trouve que c'est bloated de mettre tout dans un seul cvs/svn. Si c'est le premier, peut être que comme pour l'ancien init, ça a un sens techniquement de faire ça de façon unifié ?
Et quand on voit tout ce que fait le noyau qui peut être fait en userspace ( par exemple, le nat est fait via natd sur FreeBSD en userspace ) et le nombre de gens qui se jette sur le hurd pour aider, j'aurais tendance à dire que "trop faire" n'est pas une si grande tare. Et je peux même pas dire que c'est la personnalité du développeur initial, vu que Linus est vachement moins diplomate que Lennart.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 0.
Encore le truc que tout le monde a essayé de faire avan et qui n'a jamais marché parce que les distribs sont trop différentes …. On va encore bien rigoler avec ça …
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 1.
merci pour toutes ces explication (au moins avec toi on peut discuter :) ) .
Pour ta question, je pensais bien entendu le binaire pid 1.
Pour l'init, c'est fait comme ça car c'est "historique" cette façon de faire, comme tu l'indiques.
Quitte à faire un truc nouveau, autant qu'il soit complètement propre ?
Histoire symple : je voulais le tester sur une de mes machines embarquées.
Je lis.
Ah tiens il faut autofs dans le noyau, devtmpfs, et je sais plus quoi.
Bon loupé , noyau compilé spécifiquement et sans ces options…
alors peut être est-ce juste un binaire de support de systemd qui utilise ça, mais j'ai pas envie de bloquer ma machine embarqué donc …
(et si c'est une galere de cross compiler et de pousser le noyau par tftp).
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
Systemd a plein de switch pour son script configure. Et d’après les archives, le projet accepte assez facilement ce qui permet de désactiver certains requirements comme par exemple, selinux, pam, gcrypt, etc.
Ceci dit, de ce que je lit du code, c'est systemd qui va demander à monter de force 4/5 fs ( cf ./src/core/mount-setup.c tableau mount_table ), et qu'en effet, le logiciel requiert d'avoir /dev/ en devtmpfs. Je suis pas assez expert pour savoir si ça fait plus qu'un simple tmpfs, mais c'est vrai que c'est discutable, même si je peux comprendre l'envie de pas avoir des milliers de cas au vue de tout ce que le noyau supporte ou pas.
Ensuite, oui, le fait de dépendre d'un certain nombre d'option noyau est gênante. Par exemple, feu mes 2 RPS n'avaient pas de support de cgroups, j'ai jamais pu mettre à jour la mageia dessus. Et c'est le même souci que j'ai avec divers appareils embarqués ( téléphone, routeur ) avec des pilotes proprios ou des patchs qui sont pas upstreams dans le kernel, je peux pas mettre à jour, ou mettre à jour, c'est chiant.
Systemd, de part sa place centrale, requiert quand même un minimum d'intégration et de travail, et du coup, tu peux pas juste "je boote avec n'importe ou et ça passe" :/
[^] # Re: C'est plus facile de travailler salement…
Posté par oinkoink_daotter . Évalué à 3.
Point de détail : un process zombie est déjà mort. Init se borne à lire le code de retour du processus zombie, ce qui termine sa destruction.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 7.
en pratique, il va dépendre des bugs dans le kernel, dans le bios, et dans la libc. Et des bugs dans les compilos, bien sur. Soit une somme de code bien plus importante que tout ce que systemd va tirer.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
:D
misc un peu de sérieux, il est évident que systemd dépend de bien plus de choses que init.
En fait ce sont les mêmes dépendances qu'init plus d'autres. M'enfin misc… :D
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 3.
Once again : quel besoin exactement ?
Parce que c’est super facile de dire « systemd répond mieux au besoin » sans définir précisément « besoin », moi aussi je peux le faire : MediaInfo c’est de la merde, ffmpeg répond mieux au besoin.
Parce que moi, sur une de mes machines, j’ai un besoin qui est « traitement complexe dans rc.local », et je peux te dire que systemd se vautre lamentablement là dessus.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 1.
N'étant pas expert du domaine, je me garderai de répondre (d'autres l'ont fait dans d'autres journaux, si ça t’intéresse réellement).
Mais essaye de te poser juste une question de base, rapide à répondre : des mecs sont payés par des boites pour développer la chose, d'autres mecs intègrent ça dans leur distro, mais ça ne sert à rien?
Tu penses sérieusement ça?
Si ce besoin n'est pas un besoin bizarre à toi que en fait le problème vient plutôt de toi, je ne doute pas que tes besoins seront répondus (soit par systemd, soit par un initd maintenu).
Mais le problème ne vient peut-être pas de systemd…
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
D'autres on créé Windows 8, vous pensez que c'est utile ? J'en veux pas.
Windows 8 a enlevé le bouton de démarrage ? c'était pertinent ?
(Ils ont remis le bouton de démarrage avec la 8.1…)
Des produits sont fabriqués de nos jours et font des flops, pourquoi en informatique ce serait différent ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 7.
Sauf que un des directeurs produits de Microsoft peut imposer sa vision du produit à tout le monde.
Red-Hat ne peut influer/imposer que sur ses produits mais pas sur OpenSuse, ArchLinux, Mageia et autres.
Pourquoi les autres reprendraient le caca du voisin ? Pour le fun ? Car ils sont masochistes ?
Peut être qu'en réalité les gens qui ont pris ces décisions de manière indépendante ont fait le poids des avantages et inconvénients de chaque système et ont choisi ce qui était pour eux le meilleur.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10. Dernière modification le 28 juin 2013 à 12:25.
Ben si.
Si je veux que les autres utilisent systemd par exemple, je n'ai qu'à créer des produits qui ne peuvent fonctionner que sur systemd, comme PulseAudio par exemple. PulseAudio sera de plus en plus incontournable.
(Obliger ce n'est pas mettre un fusil sur la tempe non plus)
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 4.
PulseAudio est né bien avant systemd et est indépendant de celui-ci.
Mauvais exemple.
De plus, si Red Hat a de grands moyens, il ne peut tout faire seul et nombre de concurrents peuvent décider de ne pas utiliser ses produits et de faire autre chose.
Sois attentif à deux exemples :
Ubuntu a conçu Upstart pour remplacer init. Il a été par défaut pendant des années dans RHEL et Fedora (alors que ubuntu est théoriquement un concurrent de Red Hat) et quelques autres l'ont adapté.
Pourtant Upstart est indépendant de tout, mais des gens l'ont adopté car il répondait à des besoins.
De plus, de nombreuses distributions ont adopté systemd très rapidement alors qu'il est indépendant de la plupart des composants dont OpenSuse dont la version commerciale est le concurrent de RHEL.
Pourquoi systemd et pas Upstart pour les autres ? Rien ne les y a forcé et pourtant ils avaient de quoi soutenir un produit concurrent à Red Hat mais ils ne le font pas…
Il ne faut pas chercher plus loin, Red Hat n'a menacé et forcé personne. De nombreuses distributions n'ont pas systemd par défaut comme Ubuntu et Debian et ils survivent bien, c'est bien la preuve que les migrations ont été faits par un choix raisonné basé sur la technique.
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 1. Dernière modification le 28 juin 2013 à 13:58.
-- mauvais bouton répondre --
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Archlinux est né avant systemd, et cela n'empêche pas l'usage de systemd.
La stratégie de RH sera d'intégrer systemd de manière à ce qu'il soit incontournable: PulseAudio est la solution pour ça.
Ils ne veulent pas d'upstart parce qu'à ce que j'ai lu, upstart est trop orienté ubuntu au contraire de systemd
Donc, non.
RH ne va pas vous dire en face: on force les gens.
Mais lorsqu'on regarde bien les tendances, je peux dire qu'ils forcent déjà même indirectement, et à supposer que je me trompe ils forceront bien plus dans le futur…
On parie ?
Analysez bien ce que fait ubuntu.
Une migration ce n'est pas une chose simple, cela prend du temps.
Ce n'est pas parce que la migration réussi qu'il y a adhésion non plus.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 6.
Déjà il faudra justifier un lien entre systemd et PulseAudio. Bizarrement personne n'a suggéré à ma connaissance un tel projet.
Tu as des sources de cela ? Non parce que c'est pure spéculation, tu pourrais dire que RH projette de tuer ta maman demain que c'est pareil…
Bref, il faut arrêter d'imaginer des trucs tordus et sans queue ni tête. Si tu n'as pas l'ombre d'une piste que cela se fera, autant arrêter ici la discussion là dessus.
Donc tu te contredis.
Systemd est un plan de domination du monde pour RH mais les autres préfèrent systemd à Upstart car Upstart c'est trop lié à Ubuntu ?
C'est donc bien la preuve que systemd a été choisi par choix technique et non par but politique sinon ils n'auraient même pas pris systemd car "trop lié à RH".
Tu te contredis en deux messages, c'est magnifique.
Franchement, tu n'as aucune preuve. Je te sortirais un bel exemple pour te dire à quel point c'est faux : Slackware, Ubuntu et Debian n'ont pas systemd par défaut ce qui montre que c'est possible de le faire tout en ayant une distribution fonctionnelle.
Les autres ont fait un choix purement technique et n'ont pas été forcé ou influé par RH.
Non mais les distributions ont trois choix : init, systemd et Upstart (et même d'autres)
Ceux qui ont pris systemd l'ont fait par choix technique, c'est évident sinon pourquoi d'autres choisiraient autre chose ? C'est bien que le choix est possible et qu'ils ont pris ce qu'ils considéraient être le meilleur.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
1) Jamais RH ne te dira en face sa stratégie.
2) Jamais RH te dira qu'ils te forceront à passer à systemd via des logiciels comme PA.
3) Jamais RH ne va te dire qu'il est en guerre contre ubuntu.
Bref, jamais. C'est là où tu as besoin de te servir un peu de ta tête.
ArchLinux ne voulait pas de systemd à la base, mais compte tenu de la façon dont arch est distribué, il fallait impérativement s'y mettre. Il y a des logiciels qui ne fonctionnent qu'avec systemd, sinon rien.
Oui, je n'ai pas de preuve mais je me sers de ma tête.
Et en quoi je me contredis ?
Upstart est trop lié à ubuntu, systemd est moins lié à RH.
Je prends qui ? Le plus lié ou le moins lié ? Moi je prends sans hésiter le moins lié. C'est pas logique ?
Quand tu n'as pas le choix tu prends, parce que comme j'ai dit il y a des applications qui ne demandent que du systemd.
Je me souviens aussi de cette chose curieuse pour un projet qui se veut universel.
A un moment donné l'auteur de systemd a été critiqué pour le fait que systemd est linux-centré.
Il a répondu quelque chose comme : " BSD peut s'en servir ce n'est pas un soucis "
Or, sur le plan des licences c'est un soucis, et sur le plan technique ce n'est pas faisable.
Il n'en a pas fallu plus pour que le monde BSD accuse Linux de ne pas chercher à travailler ensemble.
C'est le genre de chose dont j'aimerais bien qu'on se passe.
Si quelqu'un considère l'auteur de systemd de mauvaise foi alors je dirais que oui au moins sur ce point.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
C'est vrai, mais j'ai du mal à croire que tu connais super bien la stratégie de RH alors que tu ne connais même pas ses concurrents réels et son marché…
Non mais crois moi que systemd lié à PA cela n'a jamais été un projet et cela ne passera pas comme une lettre à la Poste…
Pas de bol, Ubuntu se place sur un autre marché que RH en général. RH est plus menacé par Novell et Oracle pour commencer.
Je me sers de ma tête et l'une des règles de base que je me fixe c'est de me baser sur les faits pour tirer des conclusions et non établir des conclusions avant d'analyser les faits pour les adapter.
ça me paraît plus sain et plus juste comme manière de procéder.
Ah bon ? Tant que ça ? Pourtant Debian, Ubuntu, les *BSD, Slackware et tout survivent très bien.
D'après les échos que j'ai eu, l'intégration de systemd n'est pas lié à une obligation pour utiliser des applications…
Ouais mais sans preuve tout ce qu'on peut dire c'est que tu es parano et que tu n'as aucune rigueur dans ta démarche.
Comme l'alternative existe et est viable, il n'y a pas de contraintes. Démontre moi le contraire sinon.
J'attends cette fameuse liste d'applications dont Debian apparemment n'a pas de mal à s'en passer pour l'une des distributions qui a le plus d'utilisateurs.
*BSD n'utilise pas le même système d'init que Linux depuis des années (SysV contre BSD) et tout le monde s'en foutait. Même les scripts d'init n'étaient pas identiques entre les distributions avant systemd, c'est dire que la compatibilité *BSD est le cadet des soucis.
Personnellement je ne vois aucun intérêt de se limiter au niveau logiciel pour une question de compatibilité tant que le code est libre et que le système est avantageux. Linux propose une API puissante et qui évolue sans doute plus vite que celle des *BSD, il n'y a aucune raison de s'en priver pour les applications bas niveaux qui seront par essence incompatibles de toute façon.
Pour le haut niveau par contre c'est plus discutable mais systemd fait parti des couches basses.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Pour dire pourquoi vous ne comprenez pas je me contente de cette partie :
A vous lire la guerre ne peut avoir lieu…
1) RH a des adversaires classiques comme Oracle et Novell.
2) RH a des adversaires particulier comme Hupstream (debian, mageia, etc.), mais il est encore petit.
3) RH a des adversaires invisibles:
a) La banque peut refuser à tout moment de continuer à travailler avec toi par exemple.
b) Les logiciels dont tout le monde a besoin, il faut les contrôler: si ubuntu arrive à imposer mir par exemple, RH aura du soucis à se faire.
c) Ubuntu vise aussi le marché des serveurs. Devinez ce qui intéresse les jeunes ingénieurs ? Ubuntu.
d) Dans le domaine très concurrentiel du cloud, Ubuntu est très présent, du coup, un utilisateur aura tout gratuitement alors qu'avec RH il faut payer des souscriptions…
e) Les ordiphones sont pour Android, FirefoxOS et Ubuntu touch…
La guerre ne peut être gagné que si l'utilisateur aime ton produit.
Utilisateur = monsieur tout le monde.
Et que veut monsieur tout le monde ?
-ordiphone, tablette et desktop avec la même interface.
-le moindre coût
-cloud
-support pour les entreprises.
A ma connaissance, Ubuntu est le seul à satisfaire à ces exigences.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
RH vise le marché des entreprises pour des raisons de placement de marché (pas tout le monde veut traiter avec le particuliers) et parce que RH a déjà tenté l'expérience du particulier qui était selon eux non rentable.
Du coup toute ta théorie de vouloir utiliser du RH chez M. tout le monde est faux car ce n'est pas leur but (ils se font assez de bénéfices rien qu'avec les entreprises).
On voit très bien que tu n'as rien compris à RH et à son marché du coup cela me paraît délicat que tu donnes des leçons sur leur stratégie.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
RH veut rester au niveau de l'entreprise. Qui ne le sait pas ?
Ubuntu se veut universel.
Mr tout le monde veut unifier les usages: ordiphone, tablettes, pc, et même serveur pour ceux qui s'y connaissent.
Le payeur du produit ce n'est pas l'admin, mais le DAF. Le décideur c'est le boss.
si tu arrive à séduire ces deux là, tu as ta signature.
Dans notre discussion, c'est ubuntu qui est universel, pas red hat.
Donc, oui, la stratégie d'ubuntu c'est correct, et RH le sait.
Lorsqu'on parle de stratégie, l'argent n'a rien avoir là dedans (bénéfice ou pas).
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 4.
Ceux qui s'y connaissent aiment adapter les produits aux usages qui en seront faits ce qui exclus les produits trop universels car inadaptés de partout.
Le grand public n'a pas les mêmes besoins et attentes que les experts.
Les grandes structures ont besoin de garanties, de personnes qualifiées et d'assistance de qualité à leurs problèmes en permanence.
Canonical ne peut offrir autant que Red Hat de ce point de vue car ils ne visent pas exactement les mêmes activités et du coup Canonical sera exclu pour ces raisons là.
Canonical n'a de mémoire ni certification à offrir pour ses produits, ni d'assistance ou de support aussi longue et de qualité que Red Hat et surtout n'a pas la même expérience.
Le coup du c'est « universel » n'est pas un critère suffisant pour nombre de structures.
sinon t'en fais pas que Red Hat changerait de position s'ils savaient que Canonical détenait la clé de son avenir propre…
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Ca m'ennuirait si RH n'était pas à la hauteur avec RHEL…
C'est le grand public qui tranche pourtant dans la haute technologie.
iOS était largement devant lorsqu'Android est arrivé.
Je me suis demandé qu'est ce que c'est: en regardant de près je pouvais dire qu'il aura de l'avenir.
Je ne sais pas si au jour d'aujourd'hui, Android est devant, mais il le sera devant iOS c'est déjà une certitude.
On parie ?
Rappelez moi quel type de société est majoritaire dans le monde ? Je vous donne la réponse les PME.
Les PME veulent un truc qu'ils connaissent, genre " mon fils est content de son ubuntu, est-ce qu'on a ça chris ? "
C'est ça la réalité du terrain…
Autre réalité que j'ai vu, de plus en plus de sortant des écoles utilisent comme linux Ubuntu…
Donc si je vous suis une PME devrait garder son Windows XP ? Effectivement, je suis d'accord sur ce point : XP c'est genre 14 ans…
Mais une PME qui va migrer va aller là où il y a du certif avec de l'OS connu, donc de l'ubuntu…
Si elle ne fait que du serveur de mail + web, elle se contentera même d'une bête debian.
Et pour celles qui ne veulent même pas de serveur chez elles, ce sera du cloud en externe.
Et le cloud sera debian… (Peut-être du CentOS…)
C'est ce qu'avait pensé IBM le numéro un de l'informatique de l'époque avec Microsoft dans les années 80…
Redites nous à combien est Microsoft aujourd'hui ? plus de 80% des desktops ?
La plupart des jeux rentables sur PC tournent exclusivement sur Microsoft…
Si ce n'est pas un plébiscite ça, moi qui n'aime pas leur produits, dites nous ce que c'est…
Et pour faire avancer le débat, dites nous pourquoi Windows 8 se bat pour être présent chez Nokia ?
Peut-être qu'ils ont du voir que le marché de l'ordiphone est l'avenir ?
Tiens, si on regarde à vu d'oeil Windows 8 on peut remarquer que c'est la même chose côté ordiphone, tablette et PC…
Tiens c'est curieux, cela me rappelle drôlement Ubuntu…
Et RH il a quelque chose de ce genre ? Dites-nous tout.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
Pour certains marchés oui.
Ne compare pas le marché des téléphones et des serveurs, le public et le besoin sont totalement différents. C'est ridicule.
D'ailleurs Windows est loin de dominer le marché des serveurs alors qu'il domine sur les machines personnelles ? Tu en déduis quoi ? Que ces marchés n'ont rien à voir.
Tu crois que cela est nouveau ? non.
Red Hat engage de très larges bénéfices avec son marché qui concerne principalement les grosses structures qui ne peuvent pas se permettre des pannes, des retards, et qui veulent des garanties et un interlocuteurs.
Les PME en général s'en foutent de ça car c'est trop chers comme service pour leurs besoins, ils sont plus souples et souvent ils se content de leurs admins système maisons et parfois avec des systèmes crackés (ce qui est impensable dans une grosse structure).
On voit qu'au final tu n'as rien compris à la cible de RH en fait.
Tu veux un autre exemple ? Oracle est le roi de la BDD mais aucune PME ne l'utilise vraiment car trop cher et souvent pas adapté à leurs besoins. Pourtant ils sont loin d’être déficitaires et en plus ils sont reconnus dans leurs domaines. RH c'est pareil pour les OS de serveurs voire workstation.
Donc tes PME…
OSEF des PME, tu vas le piger quand ?
Aucun rapport…
Puis en sois passer de Ubuntu à RH pour un administrateur système ce n'est pas compliqué.
Et si ton problème vient des décideurs, quand tu verras la différence des offres RH et Canonical, si tu veux de grandes assurances (ce dont se fout une PME mais pas les grosses structures), Canonical n'y parviendra normalement pas.
Il n'y a aucun outil de cloud sérieux bien intégré proprement dans Debian et assez récent pour être crédible. Ce n'est pas sa faute, ce n'est ni son marché, ni sa politique que d'être à la pointe pour les entreprises. Sans compter que son support est finalement trop court pour être utile dans un tel cadre (un cloud ce n'est pas un petit serveur de courriel pour 3 comptes, en général).
IBM a raté le coche mais c'est loin d'être une entreprise qui a coulé car son marché historique existe encore et il est bien placé.
L'explosion des PME n'est pas un phénomène nouveau, RH a existé bien après et a très bien vécu sans se focaliser sur ce marché.
Donc tu montres bien que le marché des serveurs n'a rien à voir avec celui des desktops car les acteurs sont différents et que le leader dans l'un ne l'est pas dans l'autre et inversement.
Donc quand RH a dit « stop les desktops, pas rentables pour nous » et qu'ils font uniquement du serveurs voire workstation. C'est cohérent, logique et économiquement sain.
Le rapport avec le marché de l'entreprise ? tu crois que la secrétaire joue à Crysis 3 durant sa pause café ?
C'est vrai que le patron d'entreprise choisit l'OS de ses machines pour leur capacité à jouer à des jeux industriels de grande qualité.
Non mais sérieusement, tu réfléchis parfois ? Tu ne vois pas que cela n'a aucun sens ton argumentation ? Tu as déjà vu des entreprises où c’était un critère sérieusement ? (à part ceux qui créent des jeux vidéo…).
Microsoft veut fournir son OS sur téléphone.
Tiens mais RH n'a aucun projet dessus car c'est un marché ultra-concurrentiel ou ils n'ont aucune expérience et de personnes qualifiées dans le milieu.
Ça alors, ils vont couler comme IBM, Renault, Peugeot, Herta, Ferrero, HP, Willam Saurin, Frolic, Pampers, etc. (bah oui, ces entreprises n'investissent pas dans un OS pour mobile, ils vont forcément couler car c'est l'avenir).
C'est une stratégie de synergie des interfaces qui a ses limites (si tu voyais le taux de satisfaits tu verrais que c'est discutable comme approche).
de plus RH a dit adieu aux desktops, qu'est-ce que tu ne comprends pas dans cette phrase ? Ces marchés ne sont ni un cible, ni à sa porté.
Et le rapport ? tu démontres juste que Ubuntu veut concurrencer Microsoft sur le même terrain. Tant mieux pour eux mais c'est casse gueule.
En attendant RH joue avec d'autres concurrents sur d'autres marchés et financièrement s'en sort très bien.
Non et justement tout va bien.
La diversification est quelque chose de bien mais s'attaquer à des marchés déjà expérimentés (RH sur le desktop ça a existé et RH a arrêté faute de rendement) où c'était un échec, il vaut mieux éviter d'y retourner si on tient à ne pas couler.
RH est sur un marché ou il est bien reconnu, a des bénéfices records et a de grandes marges de progression et possède largement les compétences pour évoluer car c'est son cœur de métiers. Pour faire autre chose et concurrencer Canonical et Microsoft ? quel intérêt ?
Est-ce que Pampers va monter sa ligne de téléphones portables pour concurrencer Samsung ? non car ça n'a aucun intérêt et aucun sens. Bah RH et Canonical c'est pareil…
Oui j'ai pris Pampers comme exemple car j'espère que cela te fera réagir. Ce n'est pas parce que deux boîtes font un OS ou sont dans le même secteur que le marché, les cibles et les produits sont en concurrence direct.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
Non, c'est une cible :
cf https://fr.redhat.com/products/enterprise-linux/desktop/ ( ie, y a un produit )
ou http://www.muktware.com/5536/pixar-animation-studios-uses-red-hat-enterprise-linux et il y a des clients
Au passage, ça explique aussi cette photo :
https://lh4.googleusercontent.com/-cGfmbqOglck/Tm7VnKNAU1I/AAAAAAAAAao/_kRn8RtRFdM/w871-h653-no/11+-+1 ou on voit Lennart visiblement chez Pixar, Lennart à l'époque dans l'équipe "desktop" chez RH, cf https://archive.fosdem.org/2011/interview/lennart-poettering
Mais oui, c'est pas la priorité, et pas vraiment l'activité la plus connu de la société.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
Pourquoi pas, mais comme tu dis c'est une activité bien secondaire.
Mais ne pouvons-nous pas inclure cela dans la case des stations de travail ?
Pour moi le Desktop c'est pour la maison, pas au boulot.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 2.
Et j'ai oublié aussi ça :
Il y a une activité autour de l'embarqué :
https://www.redhat.com/services/custom/
C'est peu connu, mais voila, l'équipe ARM de Fedora, c'est aussi des gens qui font ce genre de choses. Donc on peut supposer que si l'avenir, c'est les ordiphones, il y a sans doute une partie de l'avenir qui va tomber sur les gens qui emploient des codeurs de gcc, gdb, du kernel et sur arm ou autres.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 3.
Oui mais là encore, c'est de l'embarqué, c'est bien plus bas niveau de ce dont on parlait avec les ordiphones (enfin, personnellement je pense que les gens s'en foutent de savoir qui a compilé le noyau Linux pour une carte donnée mais s'intéresse plutôt à l'interface graphique qu'il y a dessus).
Or RH n'a de mémoire aucun projet d'OS complet pour aller sur un ordiphones, au mieux une chaine de compilation pour adapter le noyau (ce qui est bien mais c'est assez différent comme activité et en terme de renommée).
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Depuis TRES longtemps. Qui ne le sait pas?
Oh oui, vu l'orientation différente des deux ce doit être ultra simple…
Qui a dit qu'il est mal placé ? A sa place j'aurais pas raté le marché des Desktop parce que c'est un marché captif. Les services dans ce domaine sont très rentables sinon MS aurait déjà disparu du paysage.
MS est là non ?
Mais qui a dit que c'est le même segment ? Personne dans cette page.
J'ai dit que l'on utilise les même composants dans les deux domaines: PulseAudio, systemd, DNS, firewall, courriel, etc.
C'est celui qui a la main mise dessus qui va gagner.
C'est une des raisons de l'existence de MIR et Wayland: ne pas dépendre de l'autre.
(accessoirement il fallait autre chose que xorg)
Marketing: Je veux un jeu chez moi à la maison, je veux donc du PC.
Le patron il veut satisfaire son fiston, donc c'est windows.
Le patron il veut que sa secrétaire reste, il choisi ce qu'elle connaît: MS Office.
Même chose dans le domaine d'ubuntu:
Je veux que le bouton bleu se trouve en haut à droite dans mon desktop, il faut que je retrouve la même chose sur mon serveur, ma tablette et mon ordiphone.
C'est plus simple et au moins je ne me casse pas trop la tête.
RH n'est pas sur ce marché non plus.
Aucun rapport
FB financièrement est très bon pourtant il n'a pas d'avenir.
On appelle cela un marché captif…
1) Ils ne sont pas totalement dans le même secteur : Ubuntu est dans l'OS mobile par exemple.
2) Pas toujours mais dans le domaine des composants, il y a les brevets. La guerre c'est par là: les composants.
3) Evolution = futur. Demain sera Cloud, ordiphone pour les entreprises dans leur majorité.
Ce sont les composants qui vont faire la différence.
Je résume
1) Non, ce qui tire le marché de linux ce sont les utilisateurs.
Et de ce côté là ubuntu est devant.
2) Non, les ingénieurs qui sortent ne sont pas tous des informaticiens mais ceux que j'ai vu veulent de l'ubuntu et pas autre chose, du moins je ne connais pas d'autres qui veulent autre chose.
3) Oui, je connais le marché de RH: certif et grand compte (ie banque, assurance, etc.) et probablement les appels d'offres.
4) Le segment de marché de RH a comme concurrent linux essentiellement Oracle (Oracle linux, DB), Novell (Suse), et Ubuntu server lorsqu'il peuvent entrer.
5) Oui oracle est devant mais aucune PME ne veut d'Oracle.
Et le plus gros pourvoyeur d'emploi c'est qui ? Les PME. Que veulent-il ? MySQL, et qui a acheté MySQL ?
6) OSEF des PME ? Tu veux me dire qu'Oracle a été trop barge pour acheter MySQL ? LOL !
7) RH != Fedora. debian = communauté, Fedora = commmunauté. Une entreprise veut du debian/ubuntu pas de Fedora. S'il veulent du RH ce sera CentOS.
8) La discussion n'est pas : le marché de RH c'est quoi ? (c'est votre idée stupide de parler du présent)
La discussion c'est : l'évolution de linux c'est quoi ? (MON idée qui parle du futur)
Si les gens veulent du systemd, ils n'iront pas prendre de l'upstart, même si par hasard upstart avait été de qualité (j'en sais rien pour sa qualité).
Si les gens veulent du cloud, et c'est le cas, ils feront du cloud qu'ils le veulent ou pas (Ubuntu Cloud).
Si les gens veulent du BYOD, c'est le cas, ils en feront.
Dans tous les cas, Ubuntu est bien placé.
Parce que RH le sait elle commence à tenter de se rapprocher du desktop, sans en faire… (PulseAudio, freedesktop, GNOME 3, Wayland ?)
Ben oui beaucoup d'admin veulent du Desktop pour gérer le parc info.
[^] # Re: C'est plus facile de travailler salement…
Posté par omer666 . Évalué à 6.
Je trouve que tu vas un peu vite en besogne : tu jettes trop d'affirmations sans source ni référence. Lorsque tu nous dis qu'il n'y a qu'à faire marcher sa tête, d'accord, mais dans ce cas puisque ta tête fonctionne si bien, explique-nous le raisonnement qu'il y a derrière. Dire que Red Hat nous prépare un complot est complètement tiré par les cheveux, et ce pour une raison bien particulière : la licence, qui protège l'utilisateur.
Tu nous parle de PulseAudio, mais ce logiciel n'est pas indispensable pour produire du son. D'une part, le son du système provient du driver son, par exemple, ALSA ou OSS. PulseAudio se contente de le rediriger, le resampler et de le mixer (voir la page du projet). La raison pour laquelle les distros l'ont intégré en masse est principalement pour la redistribution du son via le réseau, qui concurrence plus ou moins le système AirPlay d'Apple, c'est à dire pour rester dans la course avec les systèmes propriétaires.
Enfin il y a bien d'autres serveurs son que PulseAudio, ce qui fait qu'il n'est vraiment indispensable pour personne.
De même que Linux n'a pas besoin de PulseAudio pour produire du son, PulseAudio n'a pas besoin de systemd pour fonctionner. Tout au plus a-t-il besoin de udev pour détecter le matériel. Et c'est là que la licence intervient : udev, sur les distros qui ne sont pas sur systemd, a été forké. Eh oui. Le jour où Red Hat tente de verrouiller le marché, ils seront bien embêtés avec tous les forks qui vont fleurir, et qui fleurissent déjà, même sans avoir tenté explicitement de le faire.
Conclusion : la thèse conspirationniste est complètement fantaisiste.
Quant à ta connaissance du marché, tu te base uniquement sur une vision des choses limitée puisque c'est uniquement la tienne. Si tu es étudiant comme je l'ai compris à demi-mot, sache que pour aller plus loin (recherche universitaire et ainsi de suite), il te faut une vision globale, le spectre entier. Te contenter de ce qu'on te dit n'est pas suffisant. Ça m'étonnerait que tous les ingénieurs veuillent de l'Ubuntu quand on voit la gueule des décisions techniques qui sont prises. Je ne critique pas les décisions en elles-mêmes, mais la prise de risque, qui me paraît bien trop importante pour intéresser un administrateur réseau avec un parc important sous sa responsabilité (sans parler des exigences potentielles du client…).
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Aucun rapport avec ce que je dis.
La licence par exemple de FreeBSD est nickel pour ceux qui aiment FreeBSD.
Est-ce que cela empêche Apple de le copier et de le mettre à sa sauce ? Non.
1) Non, une stratégie ce n'est pas seulement une question de licence, si ce n'est que cela, je ne vois même pas l'intérêt de parler de systemd, à titre personnel.
2) RH ne complote pas, pas du moins de mon point de vue. Si pour vous dénoncer une stratégie c'est parler de complot alors ok, il y a complot.
3) Une stratégie est multi dimensionnelle et ce n'est pas une question de finance et encore moins de licence.
Prenons un exemple tout simple:
Des personnes ont créé un système de versionning, CVS. Ce dernier était bien implanté et il fonctionne encore de nos jours. Puis SVN est arrivé parce que certaines demandent n'étaient pas satisfaites par CVS.
Personne n'a pensé que SVN aurait des concurrents sérieux…
Git est arrivé et n'a pas apparemment de plus pour une entreprise.
Sauf que Kernel.org a décidé de s'en servir…
Cette pub involontaire a permis à git de se faire connaître.
De nos jours, git et svn sont très utilisés avec git largement en tête maintenant… malgré mercurial (hg).
Bref, Red Hat est l'équivalent de kernel.org et systemd/pulseaudio est le pendant de git dans ma discussion.
Personne n'a dit le contraire: il faut suivre la discussion.
http://upload.wikimedia.org/wikipedia/commons/0/00/Pulseaudio-diagram.svg
Selon le graphique que j'ai lu la tendance de PulseAudio est de phagocyter donc, à terme, il contrôlera la carte son directement.
Et comme me le disaient pas mal d'interlocuteurs c'est un serveur de son… (comme X est un serveur graphique)
C'est vrai que lorsque la majorité écrasante des distros utilisent PA, ce doit être une erreur de leur part… :D
J'ai du rater un épisode? Je parle du futur pas de ce qu'il fait maintenant.
Mais puisque vous le dites vous même PA dépend d'udev qui est dans systemd…
Ce n'est pas un hasard si tout le monde après veut du systemd, au moins pour ne pas avoir à séparer systématiquement udev de systemd…
Maintenant je fais le pari suivant:
demain PulseAudio dépendra de systemd. Pourquoi? Parce que le serveur de son aura comme tâche d'être en relation avec d'autres réseaux et il est déjà en relation avec le système.
systemd aura la tâche de suivre les règles mis en place par l'admin : interdire par exemple sons, mais autoriser d'autres… Lancer un son précis à un moment précis par rapport à un événement de systemd…
RH n'a pas besoin de verrouiller quoi que ce soit. La preuve pour écarter le monde unix il a suffit de créer systemd qui, je vous le rappelle, a le droit d'être utilisé par le monde unix si ils le souhaitent vraiment.
C'est l'un des fameux mensonges de lennart: FreeBSD peut s'en servir. Sauf que la licence ne le permet pas…
Ben oui, une partie critique d'un OS est entre les mains de systemd dont la licence ne convient pas. Iriez-vous prendre le risque de le prendre ?
Tous les étudiants ? Quand j'ai dit ça ? J'ai dit la majorité. A titre personnel je ne connais pas d'étudiants qui ne font pas d'ubuntu lorsqu'il font du linux.
Oui, je critique aussi certaines décisions techniques, je l'ai même déjà dit, mais au final que les décisions soient bonnes ou pas, un fait que j'ai constaté: ubuntu is back for a long time.
Et il n'y a pas que les informaticiens qui peuvent être ingénieurs hein…
Vous confondez marché grand public, marché des industriels non ?
1) Un admin qui s'y connaît va utiliser de l'ubuntu dans son bureau et administrera ses machines sous debian par exemple via cette machine. Donc pas de risque au sens où vous l'entendez.
2) La responsabilité de l'admin est d'assurer un service. Si il est convaincu que c'est la solution, il s'en servira quand même, sinon relire mon point 1).
3) Ce n'est pas parce que je ne suis pas d'accord avec ubuntu que je vais me permettre de dire qu'on ne s'en servirait pas. Au contraire, je reste objectif et je ne vois pas pourquoi une entreprise s'écarterait du couple ubuntu/debian.
4) Et le client peut très bien exiger de l'ubuntu ce qui est hautement probable dans le futur…
Et là je rappelle ce que j'ai dit: ubuntu est déjà devant par rapport à RH.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 6.
Perforce avait une bonne part des parts de marché. Google est parti sur perforce tout au début et il y a en ce moment une migration lente sur les dépots internes vers git ( en ne faisant que des dépots git pour les nouveaux projets ), Perl a longtemps continué à utilisé perforce, freebsd aussi. Svn avait des concurrents sérieux depuis le début. Et bitkeeper est plus vieux que subversion de quelques mois, donc même le concept de Subversion n'était pas le plus novateur à l'époque. Avant git/hg, tu as eu tla, dont l'idée était séduisante, mais l’implémentation catastrophique.
Git a des avantages pour une entreprise.
D'une part, git a des avantages vis à vis de svn sur le point de vue techniques. Il est plus rapide, permet de faire des git bisect efficaces, ce qui permet de chercher des bugs de façon plus rapide.
Ensuite, le fait que tout clone d'un dépôt git soit un clone complet permet de régler des souis d'ordre opérationnel, comme le fait d'avoir une liaison lente dans certains pays vis à vis de l'Europe. Exemple, le brésil, l'australie ont des liens internets limités. Et si donc tu as des bureaux la bas, pouvoir faire un miroir complet sans magouille est un avantage. ( ie, miroir en lecture ecriture ).
Ensuite, non, une entreprise qui développe a autant besoin de pouvoir faire des branches qu'un groupe comme kernel.org. Si tu fait un site de ecommerce, tu as ta version en production, ta version en dev, etc, et tu fait passer les commits de façon fluides d'un depot à l'autre. Faire des merges sous svn, c'est pourri, avec git, ça passe correctement.
D'ailleurs, la preuve que git apporte des choses, c'est qu'il y a plein de boites qui utilisent git. C'est que Google lache perforce pour git.
Et ensuite, git a été écrit par Linus Torvalds car les outils existants n'étaient pas adaptés. Donc c'est pas "kernel.org a fait de la pub involontaire". C'était très volontaire, d'une part, et avant, Linus utilisait bitkeeper, qui n'a pas lui pris le monde d'assaut, prouvant bien que la pub de kernel.org n'est pas une condition suffisante, ou même nécessaire.
Donc oui, git s'est imposé par ses qualités, pas parce que Linus a décidé de l'écrire ou de le faire. Si un outil réponds aux besoins des gens, les gens l'utilisent. Git réponds à ce besoin, c'est utilisé. Systemd réponds, c'est utilisé. Mercurial réponds aussi et permet d’expérimenter autrement, des gens l'utilisent, pareil pour upstart.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
" Perforce is a commercial, proprietary revision control system developed by Perforce Software, Inc " (…)
( Source : Perforce - Wikipedia, the free encyclopedia )
Je te propose de lire ceci: List of revision control software - Wikipedia, the free encyclopedia
Je ne compare pas de l'open source avec du propriétaire. Donc perforce ne m'intéresse pas.
Sinon pour être objectif, il faudrait aussi comparer les logiciels fait maison…
Je compare ce qui est décemment comparable notamment CVS/SVN/GIT/HG.
Git a ma connaissance c'est largement après parce que justement SVN était proche de CVS et comme tu le sais, CVS est rarement utilisé.
Par contre, Git s'est imposé très rapidement grâce au fait que le noyau linux s'en serve, pas pour ses perf.
Si ce sont ses perf, alors pourquoi beaucoup d'entreprises restent avec SVN ?
Donc tu confirmes ce que je me disais: SVN n'est pas meilleur que Git sauf sur un point il me semble.
Mais SVN a bien battu CVS et largement.
:D Si je suivais ta logique je dirais que tu insultes les utilisateurs inconditionnels de SVN. A titre personnel, je n'y vois aucune insulte, juste un point de vue qui se défend.
Tu as vraiment une dent contre SVN…
Comme je n'utilise pas vraiment SVN je ne peux pas connaître, j'utilise git de temps en temps et surtout Fossil qui correspond a tout ce qui est utile pour la majorité des usages…
Je suis d'accord qu'avec Git je n'ai jamais eu de soucis…
Je ne connais pas la politique de Google dans le domaine de VCS, mais si je devais utiliser un VCS, je choisirais Git pour les gros projets.
Et comme Git fonctionne tout aussi bien avec les petits projets, pourquoi s'en priver ?
SVN était déjà suffisamment bon et CVS est plus ou moins accepté depuis des lustres donc, personne n'ira se payer un propriétaire.
C'est l'évidence même.
Seule une entreprise qui a de gros besoins de versionning et qui a le budget pour s'y investir aurait envie d'un VCS propriétaire.
C'est pour cela que Google dans le passé utilisait Perforce (sécurité, assurance, etc.).
1) Beaucoup de logiciels répondent à des besoins, donc c'est utilisé, cela me paraît évident.
Par exemple, Windows XP, est encore utilisé, cela répond à un besoin…
2) upstart ? Franchement, si on pouvait s'en passer ce serait top…
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
Et ? ça reste un concurrent quand même. Sauf à vouloir être malhonnête, tu supprimes pas tout une partie du paysage pour le plaisir.
Tu as croisé beaucoup de codeurs qui se sont dit "oula, kernel.org prends ça, donc je fait pareil" ?
Parce que moi, c'est pas la réponse qu'on m'a donné. Avant d'affirmer des trucs, prends au moins la peine de discuter autour de toi, ou plutôt, discute avec des gens qui savent de quoi ils parlent.
laisse moi deviner, parce que mettre en place git, ça implique du travail et des formations, et donc que les boites n'ont pas le temps ? En fait, tu devrait aller demander à ces nombreuses entreprises, car moi, mon employeur, et celui d'avant, ils ont commencer, voir bien fini de migrer vers Git ( et ça va de la startup à la grosse multinationale américaine, donc j'ai les 2 extrêmes ).
Donc dire que "un logiciel est pourri sur un point", c'est insulter les utilisateurs, pas de souci. Je vois qu'une fois de plus, tu ne piges pas les critiques qu'on te fait, et tu tentes de les appliquer.
Sinon, comme tu connais ni git, ni svn, cf ce que tu dis, peut être que tu devrais arrêter de commenter, car ça, c'est bien la définition d'inutile.
C'est bien, d'un coté, tu dis "Je ne connais pas la politique de Google dans le domaine de VCS", de l'autre, tu dis " C'est pour cela que Google dans le passé utilisait Perforce (sécurité, assurance, etc.).". Tu as pas le sentiment de te contredire ?
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -9.
Ai-je dit le contraire ? Mon propos est de comparer des cas semblables: CVS/SVN/HG/GIT.
Ils sont open source, et visent le même public.
Ce qui est malhonnête ce serait de prétendre que comparer Perforce (commercial) avec Git (GPL?) est pertinent.
A la limite on devrait discuter de ce qu'IBM et Microsoft ont, là tu serais plus logique.
Je ne supprime pas le paysage puisque dans les faits, chacun y trouve son compte, et sur le terrain tu ne me feras pas croire que la majorité reste en dehors des mains des 4 acteurs: CVS/SVN/GIT/HG.
Et la tendance est d'aller vers Git, ce que tu confirmes.
Tiens tu me disais fièrement que c'est le patron qui décide…
Maintenant, c'est un codeur …
En gros, une VCS de chez IBM ou Microsoft ne vaudrait pas un clou donc ils veulent du git, pour les perfs uniquement ?
Pour les perfs je ne sais pas, mais pour la stratégie d'une entreprise, elle prendra ce qui est utilisé par de grand projet comme kernel.org par exemple.
Donc git est pertinent. Mais même si c'est pertinent j'ai lu quelque part une fois que parfois il y a des problèmes (merge) mais c'était réglé finalement.
Donc dans mon cas, je compile git (en lisant le changelog je sais si c'est une version correcte ou pas).
Une fois la compilation s'est très mal passée… ce qui de mon point de vue explique pourquoi il y en a encore des tas qui restent chez hg ou même svn.
Parce que justement, il faut un truc qui marche mais pas un truc qui bogue en production.
1) Ah bon, il n'y a pas de commande chez git qui permet de dupliquer un dépôt svn vers un dépôt git ? Bizarre.
2) Formation: J'ai mal lu ?
a) D'habitude tu me traites d'imbécile, de demeuré, de pitoyable, et je ne sais quoi… [cela n'engage que toi bien sûr, pas LinuxFR]
b) Donc, le dernier des derniers que je suis est capable d'apprendre tout seul svn, puis git et enfin fossil.
c) La doc de git est tellement imbuvable que ma pauvre personne insignifiante est le seul en ce monde à être capable d'apprendre sans coach ni formateur grâce au seul tutorial officiel.
d) De plus, les super ingénieurs qui me surpassent en intelligence, notamment certains sur linuxfr, ne seraient pas capable d'apprendre un peu le git, même les commandes simples comme merger, commiter, brancher… ?
e) C'est vrai que la commande
git svnne permet pas de faire du git avec un dépôt svn. Faut que je revérifie ce que git peut faire dès fois que je me trompe.Git - SVN Crash Course
Peut-être que le site ci-dessus ce n'est pas top ? Bon alors celui-ci me paraît être très bien…
git-svn - Git SCM Wiki
Ca doit être hyper dur à apprendre dis moi…
Puisque plusieurs membres de LinuxFR me prennent pour le bouffon de service je pense donc qu'un super ingénieur devrait s'en sortir sans problème, puisque je m'en sors.
3) Oui, migrer c'est difficile [résistance au changement par exemple], mais pas insurmontable.
Tous les IDE par exemple, ont intégré les VCS les plus courants (HG/GIT/SVN), donc la formation n'est pas forcément le soucis numéro un.
Non.
Je disais que dans le passé il fallait un VCS de qualité. Donc la logique devrait être, de mon point de vue, faire un appel d'offre sur un VCS dans lequel on fait savoir quels sont leurs exigences (cahier des charges).
Donc, probablement que Perforce a gagné cet appel d'offre. Mais à titre personnel je ne connais pas la stratégie de Google dans le domaine de VCS.
Par contre, si j'étais Google, pour pouvoir capter les meilleurs, il vaut mieux se tourner vers le VCS le plus utilisé du moment et qui est décentralisé: git.
Tu utilises git non? Moi de moins en moins car je préfère Fossil.
Merci coach pour cette partie de rigolade. Merci pour le +1, aussi.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
Tu sembles confondre tes propos avec mes propos. SI j'ai dit ça, je demande une citation et un lien vers le commentaire linuxfr. J'ai marre que mon nom soit cité par un mec qui est incapable de comprendre les trucs basiques.
Et tu sembles diviser une entreprise en 2 groupes totalement distinct, sans imaginer qu'il y a discussion possible, je sai spas dans quel PME est ce que tu as bossé, mais ça devait pas être la joie.
Alors 2 choses :
1) Cite les noms des produits, ça te fera déja moins passer pour un rigolo. EN l’occurrence, tu peux dire clearcase et sourcesafe.
2) Safesource ne tourne que sous windows, ne s'intégre que avec windows, et n'a que des clients windows. Autant dire que si tu as pas déja choisi windows partout, tu peux te brosser.
3) clearcase te force plus ou moins à tirer un serveur d'application webspahre, ce qui requiert d'avoir deja des admins J2EE, ce qui n'est pas forcement le cas ou la voie que tout le monde veux prendre.
Donc non, on est pas dans ton monde binaire ou soit une chose est bien, soit tout pourri. Il y a des contraintes sur ce que tu connais, ce que tu veux faire, ton archi existante, ton équipe existante.
Cool, donc hg est utilisé par python et par mozilla, et bzr est utilisé par Canonical et Ubuntu, mysql, emacs. Fossil est utilisé par rien.
Y a plein de chose que tu fait mal, mais lire en fait pas parti. Par contre, il est fort probable que tu penses que "pouf, les codeurs comprennent comment marche git du premier coup", ce qui montre une fois de plus ta déconnexion complète avec le monde réel. Dans le monde réel, tes codeurs peuvent venir d'une SSII ou ils ont pas appris à se servir de git/svn/etc, sortir d'école ou l'idée de gestion de version n'est pas au programme, et donc passer d'un modéle centralisé à un modéle plus complexe requiert des formations. Venant de svn, le rebase est une idée simple mais qui n'etait pas possible. Le cherrypick non plus. La façon de faire un pull propre sans faire des commit de merge aussi. Bref, y a plein de choses que tu connais pas sur git et qu'une formation permet de clarifier.
Je ne pense pas avoir dit que tu es un imbécile, juste que tes propos sont imbéciles. J'ai des mots beaucoup plus dur pour l'ignorance crasse que tu affiches à longeur de temps, mais que je garde tant bien que mal par civilité.
Cf ce que j'ai dit plus haut. Tout le monde n'a pas la chance comme toi d'avoir du temps libre pour le passer en auto formation, et si tu as du te former pour utiliser l'outil, ça prouve bien qu'il faut une formation, cqfd. Sauf à demander aux gens de le faire hors du boulot, ce qui serait au mieux un procédé cavalier, et au pire sans doute un peu illégal.
Alors une fois de plus, tu emploies des mots pour dire autre chose que le sens officiel. Un appel d'offre, c'est une procédure bien spécifique avec divers parties qui répondent, c'est utilisé principalement pour l'état. Je pense que ce que tu veux dire, c'est sans doute une comparaison.
Je peux te garantir que même à l'époque ou Perforce était utilisé par défaut, le VCS n'avait pas d'impact sur les recrutements vu qu'il y a suffisamment d'outils par dessus pour cacher les aspects les plus moches. De plus, vu que tu n'as pas le droit de transférer le code source sur ton portable (pour les applications internes, je parle pas de trucs spéciaux comme go, chromium ou les divers projets libres de la boite) et qu'il faut bosser via ssh sur des serveurs sécurisés, les parties "pas de travail offline" et "trop lent" sont moins ennuyeuses que dans un déploiement classique.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -8.
Tu ne dis pas toujours directement ce que tu penses, mais par contre, j'ai très bien compris tes propos: le patron décide (logiciels, etc.).
Par contre, tu disais aussi, que c'est le client qui décide par exemple parce que Microsoft a accepté d'ajourner l'arrêt du support de XP.
Je t'ai répondu que non. Ce sont des stratèges: le client veut payer: tant mieux, mais Microsoft lui aurait continué le support… Les banques n'ont fait qu'accélerer le mouvement.
Bref, MS décide en tenant compte du client.
Dans notre discussion, le Boss décide toujours seul, mais il tient compte de son environnement:
Un ingénieur qui recommande Git, le calcul de l'intérêt de faire du libre ou pas (Git vs Perforce), le coût de la migration (Perforce vers git est-ce simple ?), l'usage à l'echelle planétaire de l'appli (qui utilise Git), les possibilités de git (grand projet? stabilité en cas de merge ? gestion des utilisateurs ? Branch private ? Shunt ?)
Le financement va-t'il suivre: il faut du linux pour pouvoir exploiter à fond les possibilité de Git même si cela fonctionne sans soucis avec Windows.
Le ressources humaines vont-elles adhérer ?
etc.
Heureusement que je t'avais donné les liens où tu as une liste des VCS (proprio ou pas, distribués ou pas) dans le commentaire un peu plus haut.
Tu n'avais pas compris que IBM est un simple exemple pour te démontrer que le VCS existe depuis longtemps, donc qu'il a une grande utilité et donc que Google se devait de s'en servir, d'où la nécessité d'une stratégie d'achat ?
Un exemple, servant à expliquer une idée générale lorsqu'on estime que c'est généralisable ?
1) Beaucoup d'utilisateurs l'utilisent à titre personnel… et souvent sans connection.
2) SQLite te paraît trop petit ?
3) Ce n'est pas juste le plaisir de me contredire qui te pousse à affirmer ? :D
4) Fossil est accessible via SSH, il y avait même eu un débat sur le sujet il y avait quelques mois.
Donc les gars qui font de l'informatique sont trop bêtes pour comprendre qu'ils doivent apprendre un VCS, sachant qu'une bonne majorité aime bien coder dans son coin ?
Et moi qui suit le gros naze à tes yeux, je suis trop
intelligentbête pour avoir quand même eu envie d'apprendre ?Ah oui, une auto formation, c'est une formation effectivement. Mais dis moi, dans ta boîte, dont je ne cherche pas à connaître le nom, on n'offre pas la possibilité aux employés de s'autoformer même quelques minutes ?
En gros, si un gars a son projet perso, qu'il apporte dans son ordinateur professionnel, il n'aurait pas le droit de coder pour ça?
Je vais te raconter une situation que j'ai vécu il y a déjà assez longtemps:
Un gars, futur chef de projet, codait. Dans l'entreprise en question il n'y avait pas de VCS. Alors par curiosité je lui avait demandé pour son projet professionnel si par hasard il utilisait un VCS: A l'époque c'était SVN qu'il utilisait dans son Windows… à titre personnel pour le compte de son entreprise.
J'avais dit au patron qu'il faudrait prévoir un VCS… Aujourd'hui je te confirme qu'ils utilisent bien un VCS.
Principalement. Mais Google fait des appels d'offres, parce que côté rapport qualité prix c'est moins cher. C'est le cas de Nexus dont l'appel d'offre a été gagné par LG.
Je parle bien du fait que très probablement ils [Les dirigeants de Google] ont du faire un appel d'offre sur le VCS à utiliser à l'époque. Comme tu le disais, l'entreprise veut des garanties comme le support.
Entre temps, ils ont du voir l'engouement pour git. Et comme je te l'ai dit, ils s'intéressent à l'intérêt stratégique de se servir de git.
Et parmi les raisons, je t'en ai donné une: c'est le plus utilisé à ma connaissance, donc le vivier de compétences informatiques utilisant en général le plus connu, ils n'ont pas cherché à faire même du mercurial.
Remarques, si FaceBook fait du mercurial, Google n'ira pas vers HG… c'est clair ! :D !
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
Non, tu as montré plus d'une fois que tu ne comprends rien. Je doute que ça soit aujourd'hui que ça commence. Arrête de prétendre le contraire, et arrête de me faire tenir des propos que j'ai pas. Si je dit pas un truc, je le dit pas.
D'une part, tu sors tes chiffres de ton chapeau, des gens qui codent pas sur leur temps libre, y en a beaucoup plus que tu crois, et d'autre part, c'est pas parce que tu dois faire un truc que les gens le font. Par exemple, toi, tu devrais te taire et réfléchir avant de poster, et tu le fait pas.
Tu le connais déjà, mais tu as des doutes.
Contrairement à toi, j'arrive à voir plus loin que ma boite. Et C'est pas "quelques minutes" qu'il faut, c'est plus "quelques jours". Dans une SSII classique avec un ingé facturé à 500€ la journée pour du dev, ça te coute 2000€/p juste en productivité perdu de faire 4j de formation. Et encore, 500€, c'est des ingés pas trop chers, estimation à la louche pour l'époque ou j’étais encore dans le circuit. Ça te semble sans doute négligeable mais si tu commences à faire ça pour plusieurs ingés, ça te coute le salaire d'un seul, soit 1 mois de travail sur le projet et la, ça deviens vachement plus visible. Et c'est en partant du principe qu'aprés 4j, ils sont parfaitement rodé.
Et la, on parle que de la formation, tu as parfaitement oublié et passer sous le tapis les choses comme les scripts de builds, l'intégration avec le bugtracker, les outils clients side, les possibles hooks du coté du dépôt, le changement de procédure de backups, etc, etc.
Tu tires ça de ton chapeau
ça me parait surtout trop peu.
Non, c'est juste les faits. J'ai jamais eu à me servir de fossil pour le moindre logiciel. Et pourtant, je suis déjà sur p4 ( zimbra ), sur tla, sur monotone, et des trucs qui selon toi serait plus obscure.
Ah oui, y a un accès ssh donc les gens l'utilisent. Comment ne pas avoir vu ça plus tôt ? Ah oui, parce que ça n'a comme d'hab avec toi aucun rapport.
Encore une fois, non. Ou alors démontre le, vu que la charge de la preuve est à celui qui affirme qu'une chose est faite ( ie toi ). Sinon ça reste que des affirmations sans fondement.
Je pense que l'équipe dirigeante est à 100 lieux des détails d’implémentation de ce genre. C'est Google, pas une de tes PMEs de 3 personnes ou tu va voir le patron. Tout au plus l'équipe en charge de l'infrastructure va avoir un intérêt à se pencher sur la question, vu que le déploiement des sites va leur tomber dessus, la gestion des dépots, les backups, etc.
Le CTO, le CFO, le CEO ? Niet, pas que ça à faire. Si ils embauchent des mecs compétents, c'est pour faire confiance à ce qu'ils font, pas pour aller faire du micro management à la dilbert.
Ah oui, et Facebook fait du Linux, donc Google n'ira pas vers Linux ?
Il y a une certaine porosité entre les boites de la Silicon Valley, et une part non négligeable de gens de l'un viennent de l'autre et vice versa.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -9.
Je serais curieux de voir tes chiffres, pour ton affirmation.
Au delà d'un certain âge, on ne peut pas rester dans le codage, même chez soi: on peut vouloir autre chose, mais je soutiens qu'une bonne majorité aime ça.
Ce qui ne veut pas dire qu'ils le font à chaque fois que c'est possible.
Non je ne connais pas et je ne cherche pas à connaître car cela pourrait influencer négativement mon opinion sur l'entreprise en question.
Par contre si tu veux t'étaler sur le sujet je veux bien te l'accorder. Je ferais l'effort de voir le côté positif de ta présence dans le boîte en question.
Quelques minutes de pause par jour pendant des mois, ce doit être négligeable à tes yeux, i.e. l'entreprise perd, et le gars il perd aussi.
Non, l'entreprise ne perd pas puisque si le gars il se barre parce qu'il estime que les contraintes sont trop pesantes ce n'est pas un mois de salaire que l'entreprise perd mais tout un savoir faire.
Donc, je confirme: tu ne sais pas de quoi tu parles.
Au fait tu ne t'es pas demandé pourquoi les entreprises se permettaient même de donner des stock options ? Juste parce que c'est rentable ?
Tu ne crois pas qu'une des raisons c'est d'empêcher quelqu'un d'aller voir ailleurs dès fois qu'on lui proposerait mieux ?
C'est vrai que lorsque j'ai au début essayé Fossil, j'ai tout de suite réussi… Je dois être un génie dis donc.
En gros, une migration pour moi ce serait simplement un truc genre
git svn.Heureusement que j'avais bien dit que certains ne migrent pas … parce que par exemple, la commande git permet de faire du svn.
Et je ne parle même pas des raisons stratégiques.
Pour le bug tracking, si je fais du Fossil, tout est intégré dans le fichier unique. Donc, migrer un script pour une grosse boîte ne pose pas de gros soucis, sauf s'il est mal écrit et mal documenté.
Par contre, je te l'accorde, pour une petite PME de quelques personnes c'est un soucis, d'où ma remarque: il faut bien réfléchir au VCS que l'on va utiliser donc faire de la … stratégie.
Voilà pourquoi je disais bien que Google a du faire de la stratégie sur le sujet, avec par exemple Nexus: c'est un appel d'offre.
Tu disais pour mes erreurs de vocabulaire en français (définition incorrecte) ?
Bah tu ne connaissais pas puisque tu n'es pas au niveau…
Tu as par exemple parlé de monotone et d'autres encore: ben je connais de réputation mais je ne suis pas pour autant convaincu.
A la limite je te propose de nous parler des avantages et inconvénients par rapport à git par exemple, dans un journal…
Au moins, nous ne serons pas deux à en parler mais d'autres pourront partager leur expérience.
TLA a aussi une bonne réputation: il fut un temps où je voulais l'apprendre puis j'ai vu git et fossil, par contre je ne connais pas P4.
C'était quelque chose qui ne fonctionnait pas correctement. C'est un plus que git et svn entre autre possèdent.
Sans cela, il y a peu de chance que cela intéresse sérieusement une entreprise.
Et si une personne veut s'en servir pour coder ses trucs à la maison via son entreprise, parce que le patron l'encourage pour de bonnes raisons, alors c'est un plus non négligeable.
Dans mon cas, je n'en ai pas besoin car je n'apporte pas de truc perso hors de ma maison sauf urgence mais dans ce cas, un mail suffira…
Tu cherchais un lien c'est ça ? Lis ce qui suit déjà.
Soyons honnête avec nous même: tu ne connais rien en politique et stratégie d'entreprise et c'est ce qui te permet d'affirmer cela.
La vérité c'est que tu as du chercher un peu sur internet et tu t'es rendu compte que l'info n'est pas disponible…
Et c'est normal, il faut se servir un peu de sa tête pour trouver la bonne info lorsque cela sort du cadre de tes connaissances.
Or, j'ai remarqué ce défaut gênant chez toi: dès qu'on sort de linux tu es perdu…
J'en ai froid dans le dos, car cela veut dire qu'on ne peut pas discuter sérieusement en dehors du cadre strict de Linux. C'est dommage.
Je te dis même que j'ai mis du temps à l'admettre, mais cela reste définitivement le cas.
Je reviens au sujet:
1) Tu me reproches de ne pas suffisamment chercher, je te renvoie donc le même reproche.
2) tu me reproches de ne pas suffisamment réfléchir, je te propose de faire de même de ton côté.
3) Je te reproche de ne pas savoir séparer l'aspect stratégique de l'aspect technique et je pense même que c'est pire, mais je ne vais pas t'enfoncer davantage.
(Un coach reste un coach)
4) Du moins, je n'enfonce pas ceux qui sont à terre contrairement à toi… C'est contraire à l'esprit du libre… de mon point de vue.
Je te donne un lien en français qui te donne une indication: je l'ai cherché hier pour toi.
J'étais même étonné d'avoir trouvé un lien en français !
(Je vois mal Google s'étaler sur le sujet: info sensible)
" LG bien sûr, quoiqu’on aura beau dire, Google tire les ficelles, fait des appels d’offres à ses partenaires et choisi " (…)
( Source : LG Nexus 4 : Faut-il craquer? Le test! )
NB: Question : Pourquoi c'est un blog ? En lisant ce que j'ai écrit dans CE commentaire, tu es censé savoir pourquoi c'est un blog.
1) Ca dépend du niveau de ce que tu entends pas cadre dirigeant.
2) Larry Page a fait ses classes à Standford: il a du apprendre des notions de stratégie. Et il me semble qu'il sait s'entourer des bonnes compétences dans tous les domaines, ce qui fait toujours la différence.
3) Puisque un VCS est difficile à migrer, je doute qu'ils prennent cela à la légère.
4) Je vois bien Sergei ou Larry vouloir connaître les orientations que vont prendre leur système d'information dont un VCS est un élément important.
Donc probablement qu'ils ont du en discuter en interne avant de trancher…
J'aurais fait comme ça.
5) La confiance n'exclue pas le contrôle: un exemple de management efficace.
Les mecs compétents ne restent pas forcément ad vitam erternam, donc, ta remarque n'est pas correcte. Lire ma remarque tout en bas.
Google était chez linux bien avant FB…
Ensuite comparer Linux qui est utilisé dans un grand nombre de système avec un VCS, c'est un peu tiré par les cheveux.
C'est sûr qu'un gars qui s'intéresse à l'informatique et qui a un minimum de connaissance en stratégie ne sait pas ça. C'est comme cela que tu vois les choses ?
Je me rappelle de mon amusement personnel lorsque des informaticiens préféraient aller chez FB: just hilarious
Ou peut-être je devrais te dire comment de grandes entreprises dont je tairais les noms tentent depuis des années de chiper une compétence par ci une autre par là avec plus ou moins de succès.
Tiens Maryssa Meyer, ancienne de Google, est allé chez Yahoo!: tu as vu Google s'étaler sur le sujet ? Non parce qu'ils savent comme moi que cela fait partie des règles du jeu.
[^] # Re: C'est plus facile de travailler salement…
Posté par Sidonie_Tardieu . Évalué à 2.
Luc2, mais en plus long. Epic.
Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !
[^] # Re: C'est plus facile de travailler salement…
Posté par omer666 . Évalué à 4.
N'importe quoi. Tu dis qu'il faut réfléchir et tu n'es même pas capable de comprendre un logique aussi basique. Red Hat ne peut pas rendre systemd indispensable comme tu le prétend car absolument tout le code qu'ils produisent est forkable. Je ne te parle pas de la foutue licence BSD, dont Apple s'est servie pour développer Darwin, qui est la base de Mac OS X, et qui est Open Source aussi : voir ici, là, ici aussi, et là encore. Et la seule fois où ça s'est un peu mal passé avec KHTML, ils ont quand même rendu leurs changements publiques.
Tu ne comprends rien à rien : la stratégie ne peut même pas exister à cause de la licence d'une part, et l'exemple que tu prends pour tenter d'en démontrer l'existence est hors de propos (je vais y revenir).
Très bien. Alors explique donc ça :
J'arrête là pour éviter la crise de (mauvaise) foie. Tu parle de guerre (commerciale, j'avais compris merci), qu'il faut faire marcher sa tête, d'imposer leurs logiciels, d'impact énorme, d'une entreprise dont le contrôle serait trop important sur l'écosystème linuxien, voir l'Open Source tout entier. Alors après tu nous dis que tu ne parle pas de conspiration, laisse-moi rire. Si ce n'est pas le cas, au nom de quoi dénonce-tu la dite "stratégie" ?
N'importe quoi, PulseAudio a besoin d'un driver son, et tenter de développer le leur serait un suicide pur et simple, quand on voit la difficulté représentée par cette tâche. Ensuite, ALSA est aux mains du noyeau Linux, et ce faisant, n'est pas prêt de disparaître. Enfin, je ne vois pas quelle foutue nécessité technique les conduirait à faire un tel choix.
Sauf que tu oublie une différence capitale que j'ai pourtant bien souligné dans mon précédent post mais puisque tu n'y entends rien je le répète : c'est ALSA qui s'occupe de communiquer avec ta carte son. Cela n'a rien à voir avec X puisque sans X tu n'as pas de session graphique.
systemd écarte autant le monde Unix que ALSA si tu veux mon avis. Linus Torvalds aussi il a une stratégie commerciale ou bien ? …
Effectivement, tu a juste dit que tu ne connaissais absolument personne qui ne s'en serve pas. J'ai juste pris un raccourcis.
Debian n'est pas Ubuntu
Donc tu ne sais pas lire. Ce qui m'étonnerait, c'est justement qu'un admin soit convaincu que ça soit la solution.
Ubuntu et Debian ne forment pas un couple. Je n'ai jamais nié qu'on s'en servait, j'ai juste supposé qu'il ne devait pas y avoir d'unanimité. Aux utilisateurs plus avisés que moi de nous dire si je suppose mal.
Quand je parle des exigences du client je parle de ses exigences en matière de stabilité, de maintenance, etc. S'ils exigent de l'Ubuntu, libre à eux.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Darwin est forkable et pas grand monde s'en sert. FreeBSD est forkable et les systèmes linux sont plus nombreux que les *BSD.
Ce n'est pas parce que c'est forkable que le problème n'existe pas.
Pour rendre systemd indispensable ce n'est pas compliqué: on habitue d'abord tout un chacun à l'usage d'un composant par exemple Xorg.
Et on enlève petit à petit tout ce qui concerne sa relation avec init pour être exclusivement systemd.
Ce sera ce qui va être fait avec Pulse Audio car Lennart n'aura pas le temps de maintenir à la fois init et systemd: il faudra choisir.
Si ma mémoire est bonne, misc avait parlé d'un logiciel ou d'une librairie qui ne pouvait pas se passer de systemd…
Donc dans le futur, mon pari, on ne pourra pas se passer de systemd ni de près ni de loin…
Beaucoup de logiciel ne peuvent pas se passer d'init n'est-ce pas ?
J'ai écrit : " Non, une stratégie ce n'est pas seulement une question de licence " (…)
Vous vous me dites que la licence empêche une stratégie.
Un développeur par exemple veut proposer un produit opensource. Fréquemment il y a des débats sur l'opportunité ou pas de mettre une licence GPL ou pas.
Le développeur sur ce point, fait déjà montre d'une certaine stratégie: trouver la meilleure licence pour son produit.
Sur le long terme la licence ça compte, mais pas seulement. Si par exemple un produit a une mauvaise réputation, on n'en voudra pas.
Si par exemple, une entreprise pose problème dans son attitude on s'en écartera [IBM, Microsoft, etc.]
Si par exemple, la mis en avant d'un produit n'est pas correcte on n'en voudra pas non plus.
Mandrake de mon point de vue était nettement supérieur à Red Hat, et pourtant, Red Hat est devant et mandrake/mandriva est encore dans les choux…
exemple d'erreur de stratégie dans le domaine de la licence
1) Je ne vois pas en quoi RH fait un complot puisque au vu et au su de tous ils sont dans des projets comme Xorg, PulseAudio, systemd…
Si vous me dites qu'il n'y a que nous deux qui sommes au courant que ces projets sont chez RH, donc il y a peut-être complot.
2) Une entreprise ne dévoile pas toujours sa stratégie, si pour vous c'est un complot, alors ou il y a complot alors.
3) La stratégie de RH est visible: utiliser PulseAudio pour le son, comme Xorg et maintenant Wayland pour le graphisme.
Ca c'est ce que je vois.
4) Jamais une entreprise ne te dira directement qu'il veut casser la gueule à son concurrent, cela fait tâche.
Par contre, si tu as l'oeil, tu verrais très vite ce qu'il veut te faire subir…
Donc me servir de ma tête c'est essayer de faire le lien sur quelque chose de plus global: la tendance de Linux en général et de RH et ubuntu en particulier.
Si je me base sur ce que fait ubuntu, je concluerais que RH a intérêt à suivre le même processus donc ils vont par exemple remplacer xorg par wayland.
" Wayland est considéré comme le futur remplaçant du serveur X.Org. " (…)
( Source : Wayland - Wikipédia )
" En mars 2013, Mir a été choisi par Canonical Ltd. comme le remplacement de la vieillissante technologie X dans la distribution Ubuntu " (…)
( Source : Mir (serveur d'affichage) - Wikipédia) )
" PulseAudio (anciennement PolypAudio) est un logiciel serveur de sons multiplate-forme, développé principalement par Lennart Poettering pour le compte de Red Hat, Pierre Ossman pour le compte de Cendio et Shahms E. King " (…)
( Source : PulseAudio - Wikipédia )
" PulseAudio 2.0 completely drops ESounD support. " (…)
( Source : Enlightened Sound Daemon - Wikipedia, the free encyclopedia )
ALSA a été créé pour contrer OSS.
Et il est là bien avant PulseAudio. Je ne vois pas pourquoi une application importante pour tous serait phagocyté par RH.
Non, ils se contenteront de contrôler la partie serveur de son, ce qui est suffisant pour rester devant.
Le but est de rester devant, être incontournable…
C'est ce qu'on m'a dit.
On appelle cela comparer:
serveur X : xorg, mir, etc.
serveur de son: PulseAudio, jack ?
drivers graphique : ATI/nVidia
drivers son : OSS, ALSA
Mon propos est de dire que pour contrôler la partie son il suffit de contrôler la partie serveur, donc pulseaudio, comme dans le domaine graphique, xorg est contrôlé par RH.
Contrôler ne veut pas dire qu'il va y avoir des hommes en armes qui menaceraient de tout casser dès fois qu'il y en a un qui ne voudrait pas se plier.
Contrôler veut dire que l'on envoie quelques developpeurs pour s'occuper du code de xorg pendant que d'autres ne le pourront pas…
Le premier Xorg que j'ai connu c'était du Fedora, les autres c'était du XFree86.
ALSA a été créé pour contrer OSS.
Rien avoir avec l'aspect commercial. :-)
Je n'ai jamais dit que c'est la même chose.
Par contre les commandes
apt-getoudpkgsont une spécificité debian qui sont encore valable chez ubuntu.Utiliser ubuntu pour contrôler du debian tombe donc sous le sens pour quelqu'un qui veut du debian sur ses serveurs mais préfère de l'ubuntu pour son outil de supervision.
Donc, je dis bien qu'ubuntu et/ou debian seront utilisés sous une forme ou une autre.
Comme je l'ai dit plus haut que plus le public qui va utiliser linux est jeune (étudiant vs expert linux) plus il voudra de l'ubuntu et donc acceptera parfaitement de se mettre à debian, via ubuntu.
L'unanimité n'est pas de ce monde, donc dans mon cas, ce n'est pas parce que je constate que personne ne veut du linux sans ubuntu que cela veut dire que tout le monde fera de l'ubuntu.
Mais la tendance me fait dire que dans le futur, hors d'ubuntu sera difficile si on veut faire sa place et en fait connaître debian sera indispensable pour l'aspect serveur.
Mais bien sûr il y a ceux qui veulent du gentoo, du RH, du Suse [qualité allemande], etc.
Pour la majorité des clients, ils demandent si ça marche sans trop de soucis.
Si leur employé, un ingénieur, s'y connaît en ubuntu, il dira: je l'utilise patron. Fin de l'histoire.
A part quelques cas particuliers où le serveur (ou le calcul) est super critique [Banques, data center, serveur de calcul distribué, etc.] cela importe peu pour l'utilisateur que ce soit de l'ubuntu.
Et ça ubuntu comme RH l'ont très bien compris.
Pour l'instant, on peut parfaitement se passer de PulseAudio, mais je parie que dans le futur ce ne sera pas possible…
[^] # Re: C'est plus facile de travailler salement…
Posté par omer666 . Évalué à 2.
Ceci ne démontre absolument rien. Ce que moi je démontre en revanche, c'est qu'on ne peut pas contraindre les utilisateurs puisque c'est forkable, et que donc, non, le problème n'existe pas.
La seule raison qui rend Xorg indispensable est qu'au début c'était le seul serveur graphique viable. Il y a maintenant plusieurs alternatives dont Wayland et Mir, mais ce n'était pas le cas par le passé (voir ce sujet). Ce qui n'est une stratégie pour personne (plus une contrainte).
Je ne dis pas qu'une licence empêche toute stratégie, je dis qu'elle empêche tout spécifiquement la stratégie que tu dénonce (voir même, elle la réfute sur toute la ligne).
Ce n'est pas moi qui crie au complot, c'est toi ! Si ce n'est pas le cas, pourquoi emploie-tu ces termes (que j'ai cité dans mon précédent commentaire) ? Et Xorg n'est pas un projet Red Hat nom de nom !
Bon, après c'est là que ça se gatte. Sérieusement, si tu veux me convaincre que c'est de moi que viennent tes idées, tu es très mal tombé :
C'est toi qui crie au loup à propos de cette stratégie, pas moi.
Ceci est du gros n'importe quoi, voir mon précédent message.
Ceci est tellement ridicule que ça se passe de commentaire.
La planification de l'intégration de Wayland à Fedora puis RHEL est antérieure à l'idée même de développer Mir. Les deux liens que tu cites corroborent d'ailleurs cette information. Du coup, ce que tu affirme est nié par tes propres sources.
Rectification, ALSA a été créé pour contrer le changement de licence d'OSS
Eh bien tu viens justement de toucher le fond du problème : PulseAudio ne sera jamais indispensable puisqu'il y a ALSA, tout simplement, c.f. mes deux précédents messages (eh oui ça fait trois fois que je le dis…)
Non, puisqu'un serveur son n'est pas indispensable pour une utilisation quotidienne.
Non, je pense que le but est de développer des outils qui répondent à un besoin.
"The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system."
Voir ici
Non, puisque cette partie serveur est optionnelle.
Non, ce n'est pas le cas.
Ce qui ne prouve rien. Fedora est une distribution dont la vocation est d'intégrer plus rapidement les nouveaux logiciels et les nouvelles technologies.
Bravo, tu viens de comprendre ce que j'ai écrit :-)
Maintenant, combien de temps va-t-il te falloir pour comprendre l'ironie de cette phrase ? …
Donc il est logique d'utiliser une Mandriva pour superviser un serveur RHEL ? Ou bien une OpenSuse ? Et c'est supposé me convaincre de l'utilité d'Ubuntu dans le monde des serveurs ?
Encore heureux !
Ceci, encore une fois, n'est pas logique, et ne prouve rien.
Hahahahahahahahahaha…
J'en reviens toujours à la même chose : il est impossible que PulseAudio devienne indispensable puisque c'est ALSA qui produit le son, et comme tu le dis toi-même, ALSA n'est pas prêt de disparaître.
P.S. : Ah, au fait, dans mon précédent message j'ai oublié un petit point sur l'adoption de systemd par ArchLinux. Alors pour ta gouverne : voici les messages de la mailing-list de arch à propos de la migration vers systemd, où Tom Gundersen discute des avantages offerts par systemd, et planifie son adoption. Juste pour dire que non, systemd n'a pas été adopté (que) par dépit.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -9.
XFree86 voulait changer de licence donc ils ont décidé de créer un projet qui concurrence Xfree.
Dans le passé je préférais nettement XFree…
" La version 4.4, sortie en février 2004, a vu sa licence changée. Ce changement fut très controversé et aboutit à la décision de nombreuses distributions de Linux de migrer vers X.Org (un fork de XFree86, réalisé juste avant le changement de licence) " (…)
( Source : XFree86 - Wikipédia )
Une des stratégies consiste à choisir la licence la moins problématique pour SONY ou Apple : BSD.
En gros " Elle [la licence BSD] permet de réutiliser tout ou une partie du logiciel sans restriction, qu'il soit intégré dans un logiciel libre ou propriétaire. " (…)
( Source : Licence BSD - Wikipédia )
Ni SONY ni Apple veulent des restrictions notamment parce qu'il y a très probablement des secrets industriels.
Mais je répète, ce n'est pas la seule raison stratégique.
C'est votre interprétation, pas la mienne. Si toutes les stratégies d'entreprises sont des complots, alors toutes les grosses structures complotent TOUS sans exception.
Désolé mais je n'en crois rien.
Désolé j'ai mal écrit: d'ailleurs, les liens que j'avais mis et que j'avais bien lu le montrent bien.
Par contre, je voulais préciser que Mir (mars 2013) a bien été créé pour contrer un adversaire, Xorg et Wayland.
Et xorg a été créé pour contrer Wayland: je m'en souviens car je pestais aussi dessus…
C'est ce que je dis: pour contrer [Je connaissais l'histoire puisqu'un ami et moi même nous en avons discuté sur l'opportunité d'utiliser OSS].
ALSA est un drivers dans le noyau [je coche cette case quand je compile le noyau].
ATI est aussi un driver [Je coche nVidia et ATI aussi]
PulseAudio et Xorg sont des serveurs.
Je n'ai jamais entendu Xorg faire directement quelque chose chez ATI.
De même, pour l'aspect son.
Mon propos est de dire que comme Wayland est avec RH, Pulse devrait suivre le même chemin.
misc dit que PA est entre les mains d'ubuntu: bizarre.
Xorg aussi est optionnel. Par contre Ubuntu dit qu'il n'est pas conseillé de se passer de PulseAudio… (si si)
1) Un board of director avec Red Hat dedans.
2) Lorsque RH met plusieurs dev chez Xorg, ce n'est pas de l'influence ça? Vous connaissez beaucoup d'entreprises qui ont les moyens de mettre même UNE personne (dev) pour contribuer à Xorg?
Non: j'ai dit: Linus n'a rien fait de commercial puisque linux dans le passé était négligeable.
Non, je dis qu'on peut contrôler un serveur quelconque avec Ubuntu, via SSH (Forward X autorisé par exemple) par exemple, et Zabbix ou Nagios comme supervision…
Donc un type qui aime ubuntu peut très bien vouloir de l'ubuntu dans SON bureau pour contrôler un cluster sous RHEL.
PulseAudio != driver. ALSA == driver. PulseAudio est le serveur en poupe apparemment donc concrètement il sera indispensable, notamment selon ubuntu.
Et comme ubuntu est devant, on ne pourra pas facilement s'en passer… C'est ce que je dis.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 4.
Tu te relis avant de poster, ou tu fait exprès pour remplir les fortunes ?
Et si ce que tu voulait dire, c'est que wayland a été fait pour "contrer" xorg, c'est encore une fois un usage incorrect du mot contré. Wayland a été fait car les codeurs de xorg estiment que l'architecture de xorg ne pouvait pas évolué par à coup, et qu'il fallait repartir de 0 pour se débarrasser de tout ce qui avait été accumulé. Les mecs qui bossent sur wayland sont les mêmes que ceux qui bossent sur xorg.
Comme le kernel.
Intel a plusieurs codeurs. Google a divers codeurs, notament sur ChromeOS, si tu veux la liste exact. Canonical a 1 personne. Nokia avait des gens sur la partie input, Suse, Collabora. Même Mandriva à l'époque avait 1 personne.
Va regarder les changelogs, tu va voir qu'il y a du monde.
Alors la supervision, pour divers raisons, tu installes pas ça sur ton poste personel.
Dans une boite de taille correcte avec assez de serveurs ( genre 4/5 ), tu as un serveur de supervision qui est dans la même zone réseau que tes autres serveurs. La question était aussi si il était logique de le faire, pas si c'était possible. En pratique, tu peux superviser ce que tu veux avec ce que tu veux, et tu peux manager ton serveur windows depuis linux ( vu qu'il y a des clients rdp partout ) et vice versa, car il y a ssh et un serveur X partout. En gros, tu démontres encore ton inutilité en répondant à coté de la plaque.
Pulse est indispensable car il règle les soucis des développeurs multimédias et qu'il apporte des fonctions. La gestion facile des écouteurs bluetooth, la gestion saine de plusieurs cartes sons ( saines dans le sens ou l'utilisateur n'a rien à faire, car c'est fait par défaut avec des réglages corrects ). Rien que d'autre ne puissent faire, mais pour le moment, les gens se bousculent pas pour le faire. Donc aussi longtemps que personne ne se bougera pour faire un travail aussi bon, je pense que Pulse sera la solution utilisé car la plus adapté à la majeure partie des cas d'utilisation, donc présente par défaut.
[^] # Re: C'est plus facile de travailler salement…
Posté par omer666 . Évalué à 1.
Ah tiens, et pourquoi donc ? As-tu au moins des raisons techniques à avancer ?
Ah bon ? C'est quoi ça ?
Pour le reste je jette l'éponge. J'ai déjà donné mes arguments et ma réflexion (que j'estime être suffisamment logique pour être compréhensible) sur le problème, de plus le post de Misc est totalement pertinent et répond à peu près ce que j'avais envie de répondre.
Mais au bout d'un moment il faut se rendre à l'évidence, certaines personnes sont trop refermées sur leur propre réflexion pour s'ouvrir à quoi que ce soit. Si c'est là l'apport d'Ubuntu au monde de l'Open Source, c'est bien dommage…
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -9.
Des raisons techniques ? Hmm…
Voyons… Lorsque mon xorg plantait alors que mon XFree était nickel, c'est une raison valable ou pas ?
Ca mon cher, ce n'est pas travailler avec ATI. Travailler avec ATI = Tu codes chez eux. Ce n'est pas le cas. Pas à ma connaissance.
Travailler quelque part signifie qu'ils mettent la main dans le cambouis de leur drivers (ATI fglrx)…
D'accord, j'arrête, même si tu réponds…
[^] # Re: C'est plus facile de travailler salement…
Posté par omer666 . Évalué à 1.
(Alex Deucher ainsi que John Bridgman de chez AMD travaillent activement sur le driver sus-cité…)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 4.
non, c'est parce que le problème n'existe pas qu'il n'existe pas. la seule chose qui compte, c'est si quelqu'un peut ou veut faire le taf. Ceux qui veulent peuvent pas, et ceux qui peuvent veulent pas. IE, les gens compétents dans le domaine voit pas le souci, ceux qui le voit sont pas assez compétents. C'est facile de poster sur linuxfr, c'est moins facile de convaincre avec des arguments techniques les autres.
Ok et la relation entre pulseaudio et init en ce moment est ?
Parce que bon, pour retirer quelque chose, il faut l'avoir, et la, pour le moment, y en a pas.
( c'est une question réthorique, ne réponds pas, on sait que tu es incapable d'aligner le moindre argument techniques, tu as fait largement preuve de ton incapacité à le faire, et surtout de ton incapacité à l'admettre et à agir en conséquence, comme par exemple "ne pas prendre un ton péremptoire et accusateur" ).
tu sais, tu as aussi le droit de citer en donnant des liens. J'ai parler d'un outil qui simplifie la création de conteneurs dans systemd. Donc curieusement, un outil qui fait des conteneurs adaptés à systemd, ça utilise systemd. Tout comme le fait d'avoir une interface graphique pour systemd va pas rendre systemd indispensable, un outil qui fait des conteneurs pour systemd va pas rendre systemd indispensable, sauf si les dits conteneurs ont des fonctions que les autres outils n'ont pas, auquel cas le souci est surtout que les alternatives sont inférieurs, ce qui est totalement différents. Si le but est "on va rendre systemd tellement bien que les gens vont plus s'en passer", tu m'excuseras de rire de ta prévision. "ouais, RH va faire des softs bien pour que les gens les utilisent".
Wayland, c'est poussé par un mec de Intel. Pulseaudio, c'est Canonical qui paye le mainteneur actuel. Tu as pas le sentiment que les faits contredisent tes délires à longueur de temps ?
Soit ta maitrise du français est incorrect, soit ta maitrise de l'anglais est incorrect, soit tu as une vision faussé du logiciel libre. Contrer implique un rapport de force, et c'est pas exactement comme ça que ça se passe. Le but d'ALSA, c'était d'offrir une meilleur API et une meilleur architecture. D'ailleurs, elle est pas portable sur les autres OS, qui sont encore sur une API compatible OSS. Ça rappelle furieusement un gestionnaire démarrage dit donc. Et donc le but, c'était de remplacer, pas de contrer.
Encore une fois, pulseaudio est maintenu en ce moment par un salarié Canonical.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -7.
" 2010-02-12: Canonical are hiring a sound software engineer. More details can be found at [http://webapps.ubuntu.com/employment/canonical_UDSE/ ] " (…)
( Source : freedesktop.org PulseAudio )
Le seul lien que j'ai trouvé ne montre même pas que c'est vrai car lorsque tu cliques dans le lien qui va chez Ubuntu, il va nul part…
Tu as un lien qui montres qu'ubuntu a bien engagé quelqu'un pour faire du PulseAudio.
(Mais qu'il n'en est pas encore le propriétaire… comme avec Upstart.)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
Parce que l'annonce est pourvu, justement. Par exemple, curieusement, l'annonce a disparu, et David Henningsson est arrivé. Je te laisse chercher le reste toi même.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 4.
Et c'est pour ça que RH fait 1 milliard de chiffres d'affaire, embauche toujours et que Canonical est dans le rouge. Car le marché de Linux est tiré par les utilisateurs ou Ubuntu est devant.
Alors c'est pas vraiment que la société défini son marché (cf les rapports de la SEC). Par exemple, RH est sur le stockage (gluster), le cloud (openstack, openshift), la virtualisation (ovirt, kvm, cloudforms), le middleware (jboss) en plus de RHEL.
Et si le futur c'est le cloud, alors RH est le premier contributeur sur openstack, rackstack est un client RH, il y a une expertise interne sur le sujet (kvm, libvirt, ovirt), il y a des produits (cloudforms, intégration d'openstack)
D'une part, RH fait du desktop sur les stations professionnels (je redonne toujours l'exemple de Pixar car c'est un des rares exemples publiques mais c'est pas le seul). Et d'autre part, c'est pas "tenter de se rapprocher", ça fait des années qu'il y a des gens de RH payés sur les softs desktops.
Mais bon, on en reparleras quand Canonical sera plus en déficit, quand Mandriva sera revenu sur son marché originel et quand Mint gagneras plus qu'une boulangerie de quartier avec ses donations.
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Ca ne contredit pas ce que j'ai dit. Petit rappel: facebook est très rentable sur le court terme mais il n'a pas d'avenir, donc je déconseillerais qu'on investisse là (Je l'ai déjà dit mais c'est pour ceux qui ne sauraient pas faire la différence entre rentabilité à court terme et rentabilité à long terme).
Dans le passé un certain Bill Gates s'est lancé dans MSDOS. Si Canonical existait à cette époque, il serait un géant en face de lui.
L'adversaire de Microsoft c'était des systèmes UNIX bien implantés…
Est-ce que par le plus grand des hasards, Bill Gates s'était trompé ?
Je te demande ça parce que ton raisonnement ne tient pas mais peut-être que Microsoft est mon fantôme…
RH ne ferait pas du cloud si le marché ne le demandait pas: Le marché du grand public justement.
Et oui, le cloud c'est l'avenir ça ne veut pas dire que c'est bien. Les fast-food c'est l'avenir aussi, figures-toi.
J'ai dit le contraire ? Ce que je dis c'est simple: Ubuntu a son cloud, donc très probablement l'utilisateur va s'y lancer et ne va pas aller de manière automatique vers OpenStack RH car justement ubuntu contribue à OpenStack …
Comme disait quelqu'un dans cette page, le Desktop a été abandonné par RH, cela ne veut pas dire qu'ils ne vont pas bosser sur des composants…
Sauf que tout récemment, ils décident de préciser la roadmap de RHEL: Gnome 3 sera utilisé.
Ils ont du dire ça parce que:
a) Ils ont abandonné le desktop il fallait donc dire qu'au moins GNOME sera pleinement supporté
b) GTK lui-même est abandonné par pas mal de monde, notamment parce qu'il n'est pas bien implémenté chez MacOS X par exemple (J'ai lu ça il y a quelques jours) et que cela a disons mécontenté.
c) Comme encore quelqu'un l'a dit: tu serais étonné des admins qui veulent du desktop sur leur serveur.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 2.
Bah, il y a des partenaires chez les ISV :
http://www.canonical.com/partners/isv
et des certifications hardwares :
http://www.canonical.com/engineering-services/certification
En fait, ils ont même du support et une assurance légale (même si j'ai des gros doutes sur elle) :
http://www.ubuntu.com/management
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 5.
Ah ah ah. Arrête de parler de ce que tu ne connais pas. Y a autant de salles de réunions dans les bureau du bureau français de RH que de salariés de Hupstream dans le monde ( soit 6 personnes, voir 7 ), pour te donner une idée des écarts de moyens entre les 2.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 6.
Il a dit "le code est fortement lié à Linux, on utilise des tas d'api spécifique du kernel, mais on vous promets de pas toucher à ces APIs, si vous voulez, vous pouvez le refaire", et la liste des APIs est documenté, ainsi que leur niveau de stabilité : http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
la preuve, Canonical a codé des démons qui réimplemente les trucs manquants, cf le début du tableau.
Si demain, les BSD ont un système comme cgroups ( ce qui m'étonnerais, vu que cgroups est déjà mal vu du point de vue de l'API par son mainteneur actuel, alors que je doute que les BSDistes codent ça avant d'avoir vu une ou deux itérations du truc ), alors ils pourront reprendre les unités systemd. Et en fait, même sans avoir ça, un étudiant du google summer of code a réussi à faire un convertisseur pour Debian, donc je me doute bien que si les BSD voulait avoir la compatibilité, ils pourraient. Et si ils ont pas, c'est sans doute que tout le monde s'en fout, ce qui prouve bien qu'on peut se passer de systemd si on veut, tout comme les BSDs se sont passés de upstart, également non portable comme systemd.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 4.
Le mainteneur actuel de Pulseaudio, David Henningsson, bosse chez Canonical
Et je vois pas grand chose de RH sur http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/4.0/
Je vois du Intel, du BMW, du Collabora mais pas de gens de RH dans les plus gros committers.
Mais bon, prenons un autre soft au hasard, omni présent ou RH a des codeurs. Tiens, on va dire que gcc va intégrer un demon de build réseau basé sur systemd, et paf. Ou rajouter ça dans openjdk, tout le monde utilise java.
Non, parce que l'architecture d'upstart est moins bien.
Upstart est un gestionnaire d’événement, et il utilise ptrace pour suivre les process pour savoir comment les tuer, ce qui pose des tas de souci vis à vis de l'heuristique utilisé pour déterminer qui est le process principal. Systemd utilise cgroups, ce qui est plus propre et rajoute en plus la gestion des ressources. Encore une fois, upstart a été tenté et adopté par RH dans RHEL, et par la communauté Fedora. Et les autres distributions avaient commencé aussi à regarder, avant que systemd n'arrive et que des gens se disent "c'est vachement plus excitant qu'upstart".
Upstart n'a rien de lié spécifiquement à Ubuntu, c'est juste qu'il y a plus que eux et Chromeos qui continuent à s'en servir.
[^] # Re: C'est plus facile detravailler salement…
Posté par Juke (site web personnel) . Évalué à 1.
Rien n'empecher de ne pas utiliser PulseAudio ou de le forker pour se passer de SystemD
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 3.
PulseAudio n'a pas besoin d'un système d'init pour être démarré, ni pour fonctionner à 100%.
Il suffit de le lancer depuis ~/.bashrc ou autre.
Le seul cas où il a besoin d'un système d'init, c'est quand on le démarre en tant que daemon système, ce qui est fortement déconseillé par les développeurs de PA.
Et même là ça fonctionne avec systemd, SysV, Upstart, OpenRC, etc… PA s'en fiche.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -9.
J'ai une question alors:
Si je veux du son, je peux me passer de PA ?
On m'a dit que c'est un serveur de son, dans le sens de Xorg pour le graphisme et PA pour le son.
Vous me conseillerez de le lancer en tant que deamon ?
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 1. Dernière modification le 28 juin 2013 à 14:36.
Oui.
Ça ne t'empêche pas d'avoir un affichage en TTY, pas besoin de Xorg pour ça.
Surtout pas.
Il suffit d'un "start-pulseaudio-x11 &" au niveau de ~/.bashrc, ou ~/.bash_profile, ou ~/.xinitrc, ou ~/.config/autostart/un_fichier_desktop.desktop ou tout simplement laisser /etc/xdg/autostart/pulseaudio.desktop s'en occuper (quand j'installe pulseaudio, ce fichier .desktop s'installe avec).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 2.
ou en framebuffer directement. Ou via surfaceflinger. Ou Mir, quand il marcheras :)
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -3.
bizarre qu'il soit à -10, parce que son propos est pertinent (cohérent, logique, et possible) même si il ne convient pas à la vision de tous.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
kadalka poste enfin des commentaires qui commencent à -10 ?
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Kadalka [moi] poste à -8
Pourquoi enfin ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
À force de te faire moinsser, si tu ne changes pas ton comportement sur LinuxFr ça va finir par arriver. :)
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: C'est plus facile de travailler salement…
Posté par kadalka . Évalué à -10.
Ce n'est pas pertinent, c'est la réalité du terrain, même si la plupart ne sont pas de cet avis…
[^] # Re: C'est plus facile de travailler salement…
Posté par Moonz . Évalué à 2.
Où ai-je dit que ça servait à rien ? Au contraire, sur un des serveurs que je gère on a été parmi les premiers à adopter systemd (vu les besoins tu peux même pas imaginer à quel point ça a été un soulagement pour le coup). Simplement, si tu m’avais dit à l’époque « bon maintenant les gars on fout du systemd partout » je t’aurai pris pour un fou.
Le besoin est parfaitement couvert par le vieux init complètement dépassé, ne t’inquiète pas pour ça.
Je croyais que « qui peut le plus peut le moins » ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Olivier LAHAYE (site web personnel) . Évalué à 5.
ça veut rien dire traintement complexe dans rc.local.
Avec systemd:
- même format pour tous les OS => quand tu est développeur d'applis, crois mois, avoir un script pour debian, un script pour suse, un type pour les autres, c'est hyper lourd…..
Là, tu ponds les fichiers xml et hop, ça marche, plus de prise de tête sur le format de l'entête lsb avec les Should-Start ou autre.
- tu as le log de démarrage associé au service (pas besoin de disséquer le syslog)
- tu peux définir un nombre de relance en cas de crash (essayes de faire ça avec init.d)
- les démons type httpd n'ont plus besoin de démarrer root, car c'est systemd qui ouvre les ports. Une seule routine d'ouverture de port => plus de sécurité et de fiabilité. Pas de perte de transaction en cas de relance du service. Essayes de faire ça aussi avec ton script init.d.
- gestion des automontages bien plus fiable.
- interaction avec dbus et du coup, possibilité d'interfaçage avec des clients desktop
- Tu n'as plus 90% du script servant a afficher les messages de lancement et /ou dédié au switch-case start/stop/status/…
Si t'as envie de rester à l'age de pierre, on se demande pourquoi tu n'utilises pas une slackware 1.0 ou une LFS 1.0, un noyeau monolitique, des montage de disque à la main, un /dev statique, et un gestionnaire de paquets basé sur tar.Z, un lpd historique, un ksh des familles, et des .a pour librairies…..
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 0.
\o/
On va gérer les services à la windows. "y'a qu'a relancer, pas besoin de savoir pourquoi ca crash et essayer de gérer ce problème avant".
(et sinon il y a des watchdog ou des solutions de HA quand tu as besoin de HA).
capabilities, ou authbind, ca dit quelquechose à quelqu'un ?
Il n'y a que moi que ça gêne de rajouter des couches à l'intérieur d'un système critique, et non pas rajouter un service qui fait la "traduction" entre le desktop et ledit systeme critique ?
C'est clair qu'on a toujours envie de discuter avec des gens qui croient tout savoir et sont pédants.
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 4.
Ne pas utiliser dbus, qui est déjà là, et rajouter un service de traduction, ça aurait rajouté une couche, justement.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 6.
pour des trucs critiques comme openssh, je préfère quand même qu'il se relance tout seul. Systemd garde le core bien au chaud, si je me sens l'envie de chercher la cause en détail. Et si ça se gauffre pendant la nuit, j'aime avoir le moins de downtime possible, parfois, ça coute de l'argent, ça rentre dans tes objectifs, etc.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 0.
si openssh se plante tout seul, toute mes condoléances.
Ca t'es arrivé souvent ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
On est jamais trop prudent, suffit juste d'une fuite mémoire, d'une barette de ram défectueuse, ou d'avoir des machines dans des versions de développement, par exemple pour que les gens puissent faire des tests de compilation.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 0.
systemd ne va pas te régler les problèmes de barettes défectueuses. A moins qu'il soit encore plus fort que ce que je croyais.
Si tu veux te prémunir contre les pannes hardware, utilise un cluster HA.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 2.
i j'ai besoin d'un openssh qui ne plante pas, sur un serveur qui ne doit pas planter, je mets une redondnce avec un cluster style RedHat Cluster.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 2.
Ca m'est déjà arrivé, hélas.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 0.
Non, c'est ce que je dis depuis le début. Et bientot, Redhat va fusionner systemd et RH Cluster … :)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 5.
Je doute que ton besoin soit stricto sensu "je doit lancer ça dans rc.local". Mais "je doit lancer ça au démarrage". Donc je pense que faire une unité systemd devrait marcher. Quand à dire "il se vautre la dessus", sans plus d'info, c'est difficile de voir si c'est un bug ou une erreur de ta part ( et ça peut être les 2, une doc pas assez claire qui fait que tu fait une erreur parce que ça réagit pas comme tu crois ).
Si le souci est que tu lances une tache longue et que systemd tues la tache, je pense qu'une unité de type "oneshot" est exactement ce que tu veux. Mais sur ma machine, c'est déjà comme ça que rc.local est lancé (et sans timeout). Peut être que le souci, c'est d'être isolé de façon plus drastique qu'avant, c'est difficile de t'aider sans plus d'info.
[^] # De l'influence de l'employeur.
Posté par Sylvain Blandel . Évalué à 7.
L'auteur principal de systemd a déjà répondu à ce point :
La réponse est très longue, elle est intégralement lisible dans le document The 30 Biggest Myths about systemd (c'est le mythe n°27, en bas de la page).
Pour revenir à l'argument avancé : l'employeur a toujours de l'influence sur ses employés. Si on suit l'argument, il faudrait que tous les « logiciels importants » soient développés par des personnes échappant à l'influence d'un employeur. Dans ce cas, comment ces développeuses/développeurs de « logiciels importants » gagneraient-ils leurs vies ?
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -9.
1) L'auteur principal n'a pas bonne presse.
2) admettons que la réputation ça ne compte pas, un auteur ne va pas vous dire en face:
" on vous fait bouffer de la bouse de vache "
Il dira plutôt:
" mon idée est géniale, vous ne pourrez plus vivre sans "
On appelle cela du marketing ou de la comm.
3) Ne pas confondre, avoir besoin du système et vouloir CE système en particulier.
Je peux avoir besoin d'un système qui lance des serveurs à chaud via un cgroup parce que init au départ ne le gère pas, mais pas vouloir de systemd en particulier parce que je n'ai pas confiance.
4) Je crois avoir déjà vu cette page, mais je ne crois pas à ce qu'il dit personnellement.
debian ou freeBSD dépendent-ils de quelqu'un en particulier ? Non.
Lorsqu'un employeur "seul" contrôle quelque chose c'est une catastrophe la plupart du temps.
Microsoft était seul dans le domaine des SE grand public, ou presque.
Tous les développeurs ne dépendent pas que d'un projet, du moins je ne crois pas.
A vous lire, RH par exemple, mettrait à la porte quelqu'un parce qu'il travaille seul sur un projet libre ?
Et RH engage quelqu'un que pour travailler sur UN projet ? Si c'est le cas, c'est une très mauvaise façon de gérer son personnel à moins que la personne soit très calée.
[^] # Re: De l'influence de l'employeur.
Posté par claudex . Évalué à 6.
Mais les gens qui bossent sur Debian ou FreeBSD dépendent d'un employeur qui, parfois, les paye pour développer des fonctionnalités dans Debian ou FreeBSD.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -9.
Ils les payent pour faire autre chose aussi… sinon ce n'est pas rentable.
[^] # Re: De l'influence de l'employeur.
Posté par claudex . Évalué à 4.
Pourquoi ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -9.
C'est un gaspillage de ressource.
[^] # Re: De l'influence de l'employeur.
Posté par claudex . Évalué à 4.
Pourquoi ? Si l'entreprise bosse beaucoup avec Debian et FreeBSD, il vaut mieux avoir des gens qui bossent dessus. Et ce n'est parce qu'il fait autre chose sur le côté que son entreprise ne le paye pas pour introduire des technologies dans Debian ou FreeBSD.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -9.
Je ne sais pas si vous avez suivi le fil de la discussion:
1) des entreprises payent pour faire un truc dans une distro: ok.
2) Je dis qu'il ne font pas QUE ça (même s'il est vrai que dans certains cas, ils ne font QUE ça).
3) Vous me demandez pourquoi c'est un problème.
4) Je réponds ce n'est pas rentable.
5) La vous me dites que c'est utile de bosser dans une distro si on s'en sert (produits, service, etc.)
Et ? Ca contredit ce que je dis ?
Ce que je dis c'est qu'il ne faut pas mettre ses oeufs dans un même panier et donc qu'ils ne devraient pas payer des personnes pour UN projet mais qu'ils doivent les optimiser.
Par exemple supposons qu'on a assigné quelqu'un à UN projet de son (sound). Il ne connaît que ça.
Un beau jour PulseAudio s'impose, mais l'autre il n'y connaît que dalle. On gros on sera obligé de le virer.
Est-ce que c'est sain ? Non.
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . Évalué à 8.
Parce que c'est bien connu, les développeurs ne sont pas capables d'apprendre ou de transposer ses compétences sur autre chose. Si le mec connait un systéme de son, il n'a aucune chance d'en connaitre un autre, surtout si du jour au lendemain, san sprevenir, le truc change. Car c'est aussi comme ça que ça marche, un jour, y a rien, le lendemain, sans avoir le temps de regarder u voir les choses bouger, paf, y a pulseaudio.
( je précise que c'est du sarcasme pour me moquer des idées délirantes de kadalka )
Des personnes qui passent d'un produit à un autre, on en trouve souvent. par exemple, Apple et Ivan Krstic (qui a bossé sur le système de sécurité de l'OLPC avant d'aller faire pareil chez Apple), Luke Kanies qui bossé sur cfengine avant de faire Puppet, les mecs de Chef qui ont fait pareil vis à vis de Puppet, Michael DeHaan le fondateur de ansibleWorks qui a écrit func avant de bosser sur ansible. Des exemples comme ça, je peux en sortir des tonnes, et ça, c'est juste la partie visible de l'iceberg, car c'est exactement pareil dans le proprio.
Si tu veux quelqu'un pour bosser sur un produit, tu va pas prendre quelqu'un qui n'a jamais touché à ce produit, tu va prendre quelqu'un qui a l'expérience dans le domaine. Donc par exemple, tu va prendre une personne qui a déjà codé sur mysql pour bosser sur postgresql, etc. Ou sur un cms en php comme wordpress pour bosser sur drupal.
Donc non, tu va pas être obligé de le virer.
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -10.
C'est vrai que j'ai du avoir le malheur de ne connaître que des incompétents…
Comme me disait une excellent developpeur, la maintenance de code c'est nettement plus difficile.
Ce n'est pas pour rien qu'on facture plus cher la maintenance que la création, même si c'est exactement le même produit.
Après tout peut-être que tu es le meilleur développeur du monde? Quelle chance pour moi d'avoir un coach de ce niveau. Je n'en demandais pas tant.
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . Évalué à 4.
Foutaises.
Facebook paye le développeur principal de mercurial pour bosser sur mercurial à temps plein. Et va bientôt en payer un 2eme.
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -9.
C'est sûr que si tu ne suis pas la conversation tu vas me dire que je débloque.
Bon je le refais pour toi parce que tu es mon coach?
1) De manière générale l'entreprise ne paye pas quelqu'un à temps plein parce que ce n'est pas rentable.
J'ai connu personnellement un exemple où le produit était à la base du service de l'entreprise et bien ce n'était jamais un type à 100%.
2) Lorsque FB, cas particulier, embauche quelqu'un, ce n'est pas ad vitam eternam non plus.
3) Mercurial étant un produit indispensable, je trouve plutôt logique ce que fait FB, car c'est rentable POUR EUX, pas nécessairement pour les autres.
FB ne va pas financer git (Linus) ou svn (Apache ?), mais un indépendant.
4) La majorité écrasante des entreprises ne travaillent pas comme ça.
5) Si je suis ton exemple, je peux aussi parler de ces entreprises qui ne veulent jamais travailler avec le libre et qui mettent que du libre chez eux… (Tu peux même remplacer libre par propriétaire ou faire un mix des deux aussi)
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . Évalué à 3.
Pourtant, Canonical paye des gens à temps plein sur Ubuntu, RH sur les divers projets, Google, Intel, IBM, Bull, Rackspace, etc, etc.
Ou des startups aussi ( qui ont globalement pas le choix ), des SSII sur drupal, sur spip, etc, etc. Des boites qui contribuent sur pgsql en france.
Y a des tonnes de contre exemples.
oui, à un moment, y a l'age de la retraite.
c'est plus Linux qui bosse sur Git, faut se tenir au courant.
Apache, c'est une fondation, si tu veux des gens qui codent, il faut bien avoir les devs payés ailleurs, ou payé la dite fondation.
Je vois pas en quoi c'est suivre mon exemple que de sortir un truc qui n'a rien à voir. Par contre, c'est suivre ton comportement habituel. Donc si tu suis ton propre exemple, tu peux parler de n'importe quoi sans lien logique que ça te choque, ça rendre dans tes capacités sans souci.
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -9.
Tu es un marrant, Canonical veut promouvoir son produit: il ne travaillerait pas dessus ?
Ce que je dis et que comme d'habitude tu fais semblant de ne pas comprendre c'est que rarement une entreprise travaille à temps plein sur du code open source.
C'est à la marge, d'ailleurs, tu ne fais que citer de grosses structure.
Une grosse structure qui a des charges fixes importantes ne peut pas se permettre de laisser un produit dont il dépend partir à la dérive, une petite structure est plus mobile et peut mieux s'en sortir.
Si tu me disais que RH ne fait rien dans l'open source je te dirais que tu es un affabulateur et c'est tout.
Les contre exemples de ta part ce n'est pas honnête c'est évident. Moi je parle du cas général, un contre exemple c'est un cas d'exception.
La règle c'est : rares sont ceux qui travaillent avec l'open source de manière permanente en y mettant une personne à temps plein.
Hors sujet.
OSEF: ça ne change en rien ce que je dis, au contraire ça confirme que même linux ne travaille plus trop sur Git, selon tes dires: ce n'est pas permanent.
Nous avons sur linuxFR des gens suffisamment intelligent pour comprendre ce que je dis.
Apache est bien celui qui travaille sur le projet, pour cela elle peut utiliser des gens, ou des sous traitants.
Ce n'est pas comme ce que tu dis que des gens.
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . Évalué à 6.
ah oui, quand je dit "des startups", je cite des grosses structures…
Alors, c'est une affirmation à l'emporte piéce, voyons la définition du mot honnête :
https://fr.wiktionary.org/wiki/honn%C3%AAte
"Ce qui n’est pas falsifié, fraudé, de ce qui est loyal, consciencieux sans être de la première qualité. "
j'aurais tendance à dire que mon intervention n'est pas falsifié ou fraudé, donc ça, ça colle
"Qui est conforme à la raison, bienséant, convenable à la profession et à l’âge des personnes. "
j'aurais tendance à ne pas trouver mon intervention contraire à la bienséance, donc pareil, ça colle
"Qui est conforme à la vertu, à la probité, à l’honneur. "
Je ne vois pas en quoi je ne suis pas conforme à la probité ou à l'honneur, donc je pense que ça colle.
"Qui est civil, poli. "
Et comme je vois pas d'impolitesse, je dirait aussi que mes propos sont honnêtes.
Donc non, il n'est pas évident en quoi mes contre exemples ne sont pas honnêtes. Sauf à avoir une définition qui n'est pas la définition couramment admise, ce qui ne serait pas la première fois.
ça confirme juste que tu ne sais pas de quoi tu parles et que tes exemples sont pas frais. J'aurais bien dit que ça remets en cause ta crédibilité, mais comme elle est inexistante…
Mais c'est dommage ue tu fasses pas partie de ce groupe de gens assez intelligents pour te comprendre.
La fondation apache n'a pas de codeurs employés à temps plein ou de sous traitant. Le travail est fait par des gens externes à la dite fondation, sans avoir de lien financier avec la fondation. Et par fondation, je parle de apache.org, pour être bien clair.
Une des règles pour obtenir l’accès en tant que projet de la fondation, c'est d'avoir des développeurs de plusieurs employeurs différents, afin de s'assurer que le projet est pérenne.
[^] # Re: De l'influence de l'employeur.
Posté par kadalka . Évalué à -9.
Je vais faire simple :
C'est bien la définition que tu prends ?
Je répète ce que j'ai dit : en règle générale les entreprises ne mobilisent pas quelqu'un à temps plein pour de l'open source.
Ce sont des cas particuliers donc ton exemple n'est pas conforme à la raison, car je n'ai jamais dit que cela n'existe pas. Ce qui existe ce sont des personnes qui font leur boulot classique et un peu de l'open source.
Je ne connais pas de startup qui va prendre le risque de faire de l'opensource exclusivement à moisn d'avoir un marché pour cela.
le mainteneur d'hg n'est pas engagé en tant que start up par exemple.
Je ne suis pas dans le secret des dieux mais je suis certain qu'il financent des projets sous diverses formes dont des sous traitant (rapide pour légèrement plus cher).
Vu qu'ils vont engager des sous, je doute qu'il n'y ait pas des exigences au départ (pérenisation du projet par exemple…;-)).
Mon pauvre misc comme je suis triste pour toi… tu es bien mon coach.
Tu te rappelles ? Un coach peut-être médiocre voire pourri… Ne va pas dans ce sens car cela me ferait de la peine…
Il faut un peu améliorer ton argumentation…
Bon, je te laisse méditer dessus.
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . Évalué à 2.
et les clients sur les employeurs, et donc les utilisateurs sur les développements. mais c'est sans doute mal (tm).
Ou alors, c'est le fait que les gens qui payent arrivent à avoir des gens qui codent pour eux indirectement alors que la personne qui ne paye pas et qui ne code pas n'a rien ?
ie, le fait que tout les utilisateurs de logiciels libres sont égaux, mais certains plus que d'autres (ie les devs) ?
[^] # Re: C'est plus facile de travailler salement…
Posté par JGO . Évalué à 2.
Les distributions prennent des directions différentes…
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 2.
Ou il est possible que l'auteur de upstart bosse dans l'équipe de chrome et qu'il pousse sa solution ?
[^] # Re: C'est plus facile de travailler salement…
Posté par JGO . Évalué à 2.
Possible, en tout cas il n'a pas bloggué à propos d'Upstart depuis plus de 2 ans, et c'était avant qu'il quitte Canonical.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 2.
Ce que tu dis de Mir me fait penser à PulseAudio lorsqu'il est sorti.
Sinon, Mir, c'est libre ou pas ? Qu'est-ce qui empêche les autres distribs de l'adopter ? Je suis loin d'être pro-ubuntu, j'ai des choses à leur reprocher (entre autres Unity et le côté de plus en plus intrusif des dernoères distribs), mais on ne peut quand mêm pas leur reprocher de tenter des choses non ?
[^] # Re: C'est plus facile de travailler salement…
Posté par cozo . Évalué à -2.
tout à fait d'accord avec toi, ces trolls sont inutiles, ces gars font des choses, qui plus est en libre, libre à vous de l'utiliser ou non. Ils ne doivent rien à personne et font ce qu'ils veulent.
Et franchement ça faisait longtemps que notre système chérie n'avait pas tant bouger. Le temps nous dira quel sera la meilleure solution car les gens ne sont pas bêtes et au final ils n'utiliseront que ce qui marche.
Il faut faire des bouses pour se rendre compte de ce qu'il faut; Crash and learn, le libre nous le permet.
[^] # Re: C'est plus facile de travailler salement…
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 9.
Qu'est-ce qui empêche les autres distribs de l'adopter ? En théorie, rien mais en pratique, cela sera quasi impossible:
1) Abandon de copyright à Ubuntu pour les contribs associé à la GPLV3. Imagine toi Redhat ou Suse accepter cela…
2) Absence de protocol (API) stable. Cela signifie que dans les faits, seul un Unity développé dans un contexte de développement Ubuntu pourra suivre ce développement instable de Mir. Je laisse reboucler avec le point 1)
KDE et Gnome notamment, ou les autres distribs ne pourront pas fonctionner dans les faits avec Mir, ou alors en citoyen de troisième zone, pire que mono avec .Net.
Et après, tu peux rajouter le fait que si Ubuntu lie des partenariats exclusifs, genre Steam codé pour Mir seulement, ben ça sera baisé pour les autres.
Ce que "tente" Ubuntu, ce n'est pas d'apporter des choses ( parce que Mir n'a aucun intérêt technique à par celui d'être incompatible à Wayland…) , c'est une prise de contrôle sur l'écosystème linux et de tuer les autres distributions desktop… ainsi que les bureaux autre que Unity. C'est juste un pur scandale pour qui n'est pas un fanboy Ubuntu…
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . Évalué à 1.
Sauf que Mir tente d'être compatible avec Wayland et Xorg.
Ça ne colle pas avec ce que tu dis.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
Mir ne tente pas d'être compatible avec Wayland. Mais alors vraiment pas!
La compatibilité Xorg, la seule qui intéresse Ubuntu, n'est que dans le sens "appli X" utilisable sur Mir (via XMir).
Pour avoir une compatibilité wayland, il faudrait:
- Un Wmir permettant à une appli wayland d'utiliser Mir. Est-ce prévu?
- Un MWayland, permettant à une appli Mir d'utiliser Wayland. Est-ce prévu?
Et ce n'est pas prêt d'arriver puisque cette incompatibilité est volontaire comme la CDDL d'Opensolaris vs la GPL du noyau Linux.
[^] # Re: C'est plus facile de travailler salement…
Posté par JGO . Évalué à 8. Dernière modification le 28 juin 2013 à 15:33.
Il y a deux articles qui expliquent tout ça très bien. Je les cite pour préciser les détails outre ce que tu as déjà mentionné.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 1.
Pour moi c'est un point fort, au moins le temps de stabiliser le bouzin : ca évitera de contaminer salement les autres comme l'a fait pulseaudio au début de son intégration dans les autres distribs. Et au moins si ce que fait Ubuntu ne me plait pas, je pourrai passer à une autre distrib.
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 3.
Ouais enfin personne n'a forcé PA d'être sur les autres distributions.
Nombreux furent ceux qui ont critiqué l'annonce de PA dans Ubuntu car il était couru d'avance que cela n'était pas assez stable pour eux…
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 2.
Peut-être, sauf la course aux "parts de marché".
Comme quoi les devs/intégrateurs ne prennent pas toujours les bonnes décisions …
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 4.
A qui la faute alors ?
Pas toujours, l'erreur peut survenir.
Mais notons que nombre de développeurs de Fedora et de PA ont justement signalé cette erreur de l'intégrer si vite (Fedora venait de l'inclure la version d'avant pour justement l'améliorer et avait conscience du problème).
systemd n'a pas eu le même levé de boucliers de la part des développeurs compétents et je n'ai que rarement vu systemd poser problème dès le départ (alors que PA était presque inutilisable au départ).
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 3.
c'est libre.
Canonical pense que pour gagner des parts de marché, il faut faire preuve d'agilité et de vitesse. C'est une position comme une autre, ç'est pas déconnant. Ensuite, le souci, c'est que ça implique plusieurs choses :
- des hacks parfois court termes plus que des corrections propres long termes. par exemple, qui se souviens de la controverse autour de xsplash et plymouth.
- ne pas hésiter à refaire tout de 0 si besoin. Il suffit de voir justement l'histoire d'unity, ou les bases sont passés de gtk à qt à compiz ( ou dans un autre ordre ).
- ne pas hésiter à corriger rapidement sur sa distro que de négocier avec upstream. un exemple d'école, c'est android et le kernel, genre les waveocks. Dans le même genre, ubuntu à tendance à patcher pour le support des indicateurs, et tout le monde ne voit pas d'un bon oeil que de rajouter des patchs pour ça un peu partout.
Et on pourrait laisser le bénéfice du doute à Canonical, mais c'est exactement pour ça que Unity est dispo officiellement dans quasiment aucune distro autre que downstream de ubuntu. Debian n'a pas le paquet, la communauté Fedora a tenté 2 fois de l'avoir, etc.
on va pas reprocher à Canonical de foncer, de coder. Ou du moins, moi, je reproche pas ça. Au contraire, qu'ils foncent, qu'ils arrivent à gagner du pognon et à devenir une boite à l'équilibre, pour le bien du libre et de ses salariés.
Par contre, faire ça et se vanter de "bosser upstream" (cf blog de Jono bacon : http://www.jonobacon.org/2010/07/30/red-hat-canonical-and-gnome-contributions/ ou il liste tout les softs 'upstreams' qui tourne que sur Unity et qu'ils ont commencés ) et de "consulter la communauté", et de "bosser de maniére ouverte" alors qu'il y a des trucs fait en secret.
Encore une fois, y a rien de mal à tout ça. Si Canonical pense que c'est valable pour faire vivre la boite, parfait, j'ai pas les infos pour juger (autre que "pour le moment, ça marche pas"). Mais c'est le contraste entre ce qu'ils disent et ce qu'ils font en pratique qui énervent une part des gens qui expriment des critiques sur Canonical.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 7.
Wow…
Ce n'est pas parce que tu as subjectivement décidé que c'était une bouse immonde que ça l'est en réalité…
La différence est que beaucoup de monde a adhéré à systemd.
Si systemd était resté un truc que chez RedHat sans aucune adhésion des autres acteurs, ça serait bizarre certes, mais c'est idiot, d'autres ont adhéré! sans doute parce que c'est tout sauf une bouse immonde.
Il n'y a pas 2 poids, 2 mesures, sauf chez toi.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 1.
Rien de subjectif dans ce que je dis, mais on verra dans quelques temps (j'avais aussi un avis mitigé sur devfs, et on voit aujourd'hui ou il en est …).
Bien sur que si : Canonical essaie quelque chose pour répondre à un besoin et se fait descendre, alors qu'ils font exactement la même chose que Redhat avec systemd et pulseaudio. De plus ce qu'ils font a beaucoup moins d'impact que ce que fait Redhat par exemple. Laissons-les faire, au mieux, ce qu'ils vont produire apportera quelque chose, au pire ce sera un retour d'expérience profitable pour tous (comme l'a été devfs par exemple).
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 6.
Il se fait descendre car il y a déjà un remplaçant pour répondre au besoin (et que les gens ont adhéré)… systemd et pulseaudio n'avaient pas déjà un remplaçant avec une forte adhésion.
Il se fait descendre car il a une politique sur la licence limite… systemd et pulseaudio n'ont pas cette politique.
Absolument pas parce qu'il fait "comme RedHat".
Tu cherches une similitude pour te conforter dans ton déni, en réalité ça n'a rien à voir (sur le sujet de savoir pourquoi il se fait descendre).
Au pire ce sera une perte de temps (en trolls compris, et extinction de troll pour les autres compris) et une expérience profitable pour personne.
Je vois aussi une différence : tu as décidé que systemd était une "bouse immonde", donc tu chercheras tout pour cracher dessus.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 1. Dernière modification le 28 juin 2013 à 09:57.
Un échec est une expérience profitable, pour soi-même et pour les autres (on apprend de ses erreurs et des erreurs des autres).
Je suis loin d'être le seul a le penser. Contrairement à ce que tu sembles avancer, tout le monde n'est pas aussi unanime que tu le rétends sur systemd : ceux qui ont à administrer des Linux au quotidien ( ceux qui se sont tapés des serveurs Windows et qui ont eu du mal à les faire redémarrer doivent un peu mieux compendre) sont beaucoup plus partagés.
Sinon, n'oublie pas qu'on est Vendredi … ;)
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 6.
Il y a beaucoup d'autres administrateurs systèmes qui au contraire adorent systemd car leur boulot est simplifié dans de nombreux cas.
Sans compter les distributions pour qui cela simplifie énormément la tâche de maintenance des services. J'ai un gros doute qu'autant de distributions mettraient par défaut un système aussi "pourri" par défaut (voire en option).
En tout cas ce sont ceux qui bossent sur les distributions qui décident de ce qu'il y a dedans. ;)
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 0.
On verra quand ça va pêter … C'est pas souvent que ça arrive mais c'est dans ces cas là que tu apprécies les choses simples.
autant de doute vis à vis des constructeurs qui installent par défaut un Windows ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 5.
Init est tellement cool que nombre de choses sont impossibles voire difficiles à réaliser sur nos machines modernes ce qui bloque nombres de personnes. C'est sûr qu'un truc qui fait rien ne risque pas de péter.
Si tu veux un truc simple de conception, prends Plan 9 ou Minix qui ne risquent pas de péter tellement ils sont petits par rapport au noyau Linux truffé de bogues par sa taille. Après ne viens pas te plaindre que pas mal de choses sont limités avec…
Bref, c'est bien de vouloir la simplicité, mais il faut un moment comprendre qu'en 30 ans l'informatique évolue et que les architectures logiciels doivent s'adapter.
Déjà les constructeurs font du matériel et non du logiciel. Faire un OS n'est pas en général leur coeur de métiers donc ils ne sont pas forcément compétents là dessus.
De plus, ils ont des contrats avec des garanties et leurs buts est de vendre des produits quitte à ce que ce soit techniquement moins bon. Et là dessus ils ont une armées de commerciaux pour remplir cette tâche à merveille et cela semble correctement effectué.
Ici on parle de systèmes libres maintenu en général par des gens compétents dans leurs domaines et dont le dialogue se fait entre les différents échelons de la conception de la distribution.
Personne n'a ici des intérêts financiers à ce que systemd soit utilisé (et encore moins des distributions comme OpenSuse car c'est la concurrence qui 'la développé à l'origine) et pourtant ils l'adoptent c'est bien parce que techniquement c'est adapté à des besoins que sans doute toi tu ignores.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -2.
J'aimerais bien savoir quoi (et ca bloque combien de personnes vu que tu as l'air de savoir plein de chose, y compris "nombres de personnes")
Parce que à part dire "systemd ca simplifie tout" "init c'est de la daube", j'ai pas vu grand chose de plus précis.
Je peux faire la même chose en inversant les noms…
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 5.
Si t'as rien vu de plus précis ca veut dire que t'as pas lu l'annonce de systemd et les tonnes d'articles sur le blog de lennart pour presenter les fonctionnalités de systemd :
http://0pointer.de/blog/projects/systemd.html
Tu peux eventuellement dire que tu n'es pas d'accord avec certains trucs, mais dire qu'il n'y a rien de précis c'est vraiment de la pure mauvaise fois.
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à -2.
je parlais dans les commentaires ici.
La mauvaise foi c'est aussi déformé les propos pour ne pas reconnaitre que, si, depuis le début des commentaires, il est quand même dur d'avoir des choses objectifs dans les commentaires.
[^] # Re: C'est plus facile de travailler salement…
Posté par Anonyme . Évalué à 5.
Il suffit de se renseigner un minimum sur systemd pour tomber sur cette page et plein d'autres. Ou lire n'importe quelle discussion sur linuxfr à propos de systemd ou ces memes explications sont rabachées.
[^] # Re: C'est plus facile de travailler salement…
Posté par Zenitram (site web personnel) . Évalué à 6.
La mauvaise foi c'est aussi de n'avoir jamais pris le temps de lire ce lien, qui ressort à chaque discussion.
Si l’honnêteté sur systemd t’intéressait, tu connaîtrais déjà ce lien avant de critiquer, tu connaîtrais ce lien depuis longtemps et ne dirai pas des choses fausses déjà discutées dans ce lien (et plein d'autres).
Quel intérêt de ré-argumenter alors qu'on sait que tu ne liras pas et continueras à dire des mensonges sur systemd juste parce que tu as décidé qu'il était pourri, comme ça, par plaisir?
[^] # Re: C'est plus facile de travailler salement…
Posté par briaeros007 . Évalué à 0.
ahaha chaque discussion.
Et pourquoi pas "en pied de page de chaque commentaire" pendant que tu y es.
on parlait de la mauvaise foi non ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 5.
Au contraire, le fait que ça soit fait par une autre boite, et donc sur les deniers d'un concurrent rends la chose plus intéressante, vu que ça permet de ne pas avoir à faire le travail toi même. Je dirais donc que tout le monde a un intérêt financier à mutualiser entre sociétés et groupes du libre.
(et désolé de sembler te contredire à chaque fois)
[^] # Re: C'est plus facile de travailler salement…
Posté par Renault (site web personnel) . Évalué à 4.
Pour moi cela ne me contredis pas réellement, c'est un point différent de celui que je souhaitais aborder.
Tu as raison sur ce point, mais de l'autre systemd s'il est développé uniquement par RH et que Novell en dépende, RH va pouvoir utiliser ce logiciel comme levier pour isoler Novell (en développant des utilitaires ou services associés et dont seul RH aurait le contrôle et pourrait orienter le développement vers ses besoins uniques).
C'est une possibilité, je ne dis pas que RH le fait ou a un intérêt réel à le faire. Pour moi cela justifie le fait que Novell a du y réfléchir sur systemd avant de l'inclure pour des arisons politiques vis à vis de la concurrence et si le oui l'a emporté c'est bien que les avantages techniques sont présents.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . Évalué à 4.
avec les scripts bash, tu as pas besoin d'attendre que ça pete pour être déjà en train d'avoir des emmerdes. Les scripts de 50 lignes pour charger ton service, ça n'a rien de simple ( et encore, je parle pas des horreurs que j'ai vu par des OEMs sur HP-UX, car la production, c'est ça aussi, des vieux trucs moisis ). Gérer des merdes comme bind ( avec rdnc et le fait de devoir faire un sleep parce que tu peux pas savoir de façon race-free que bind est vraiment arrêter ), ça n'a rien de simple.
je peux comprendre que c'est familier, que c'est rassurant, que systemd force à apprendre des nouveaux trucs, voir qu'il y a des nouveaux bugs, mais le système d'init en bash n'a rien de simple. Il est pauvre en fonction, il est lent, il requiert de connaitre un langage de merde qui n'a rien de prévu pour faire du développement sérieux, et un langage des plus non intuitif sur des points comme le calcul décimal, les sockets ( via /dev/tcp ), etc.
ben faut croire que windows réponds aux besoins des clients de microsoft. Les OEMs ont la certifs, des drivers, et ont l'argument de vente d'avoir une logithèque énorme. Et les clients des OEMs ont pareil, l'accès à la logithèque.
Si la plupart des gens voulaient vraiment du Linux, quelqu'un le proposerait et se ferait des couilles en or. C'est pas faute d'avoir tenté plus d'une fois ( mndrake, suse, RH, lycrosi, corel linux, mint, Ubuntu, entre autres ), et d'avoir à chaque fois fait un pétard mouillé.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à -2.
Ben justement, au pire si ce que propose Canonical ne me plait pas, je peux aller vers autre chose. Si on reprend system, à moyen terme, ça va être difficile de m'en passer, et c'est justement un des problèmes de systemd.
[^] # Re: C'est plus facile de travailler salement…
Posté par woprandi . Évalué à 2.
Cette bouse fonctionne très bien
[^] # Re: C'est plus facile de travailler salement…
Posté par zebra3 . Évalué à 3. Dernière modification le 02 juillet 2013 à 10:57.
Bah au moins systemd c'est pas une copie de l'existant en moins bien, et ça a le mérite d'être très bien documenté.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: C'est plus facile de travailler salement…
Posté par claudex . Évalué à 6.
Le gros avantage que je vois, c'est d'avoir une API stable pour ces paquets et donc des logiciels proprio qui fonctionnent encore dans 3 ans.
Le gros intérêt, à mon avis, c'est d'avoir plus de contrôle sur l'installation (histoire d'éviter un paquet avec un script qui recopie tout de /opt dans /usr). Et aussi d'identifier facilement ceux qui doivent tourner dans une sandbox.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est plus facile de travailler salement…
Posté par Adrien . Évalué à 8.
Je pige pas trop : deb est assez stable il me semble. Perso au boulot je crée des paquets Debian crade, pour des gros logiciels proprio. Le tout s'installe dans /opt, avec toutes les lib statiques fournies par le bouzin. Dans trois ans, je suis prêt à parier que mon paquet fonctionnera tout pareil… à moins que les pré-requis du logiciel ne soient plus disponible, mais quelque soit le système de paquet ça sera la même chose.
[^] # Re: C'est plus facile de travailler salement…
Posté par claudex . Évalué à 6.
Ce n'est pas du deb que je parlais, mais de l'API autour qui vient avec le format de paquet. Avec ce format, tu es sûr d'utiliser les libs systèmes qui seront maintenu (d'après Ubuntu), donc tu ne dois pas réfléchir à ce que tu mets comme dépendance de ton deb, si ça va évoluer en cassant tout ou pas. C'est effectivement possible en faisant ça avec les deb, c'est juste plus simple avec ce format.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est plus facile de travailler salement…
Posté par cedric . Évalué à 3.
C'est plutot la stabilite API/ABI des bibliotheques utilisaient par tes logiciels proprio. Un certain nombre de projet, comme GNOME, Boost, XUL par exemple, ont beaucoup de mal a maintenir la stabilite de leur API/ABI entre deux releases ce qui casse les applications qui l'utilisent. C'est un contournement plutot du probleme, car il est je trouve normal et important que les API/ABI des bibliotheques soient stable entre deux releases mineurs et qu'en cas de majeur on puisse avoir une installation en parallele. Mais bon, tous les toolkits n'ont pas compris ca…
[^] # Re: C'est plus facile de travailler salement…
Posté par fmaz fmaz . Évalué à 1.
Je pense qu'il aurait été plus simple de simplement dire qu'à part certaines bibliothèques qui font partie du système (typiquement pour les toolkits genre QT), on fait une appli compilée en static. Comme ça pas de dépendances et tout reste géré avec des .deb.
Et ne me dites pas que si on fait, ça, on va gaspiller beaucoup de place. Je viens de compter. Sur ma debian, j'ai environ 1800 paquets installés et environ 900 paquets libtruc. Par exemple, ne me dites pas que libmetacity-private0a est utilisé par 1000 paquets différents.
[^] # Re: C'est plus facile de travailler salement…
Posté par Marotte ⛧ . Évalué à 7.
Bah non mais si on commence à prendre des bibliothèques de plus bas niveau genre la glibc, voir même d'un niveau un peu plus haut genre Qt, si tu commences à avoir besoin de 4 versions de glibc ou de 12 version de Qt ça va commencer à chiffrer.
L'avantage des bibliothèques partagées c'est que ça oblige chaque projet qui utilise telle bibliothèque à suivre un peu le mouvement en adaptant son code. Si on commence à tout mettre en statique ça risque d'aller loin… Non seulement au niveau espace et mémoire mais aussi poser des problèmes de sécurité comme ça a déjà été dit ici.
Un projet utilise bib-1.0, on découvre une faille dans cette bibliothèque qui est corrigée dans bib-1.1, si le projet reste sur bib-1.0 c'est à lui de rétro-porter le fix, donc il se retrouve à maintenir une bibliothèque en plus de l'application proprement dite (au lieu de modifier son application pour suivre l'API qui a (peut-être) évoluée). Vu qu'un projet peut reposer sur 5 ou 6 bibliothèques c'est pas dur de comprendre que ce n'est pas vraiment viable sur le long terme.
[^] # Re: C'est plus facile de travailler salement…
Posté par Letho . Évalué à 3. Dernière modification le 28 juin 2013 à 09:36.
Le problème, c'est qu'en ce qui concerne les systèmes à la dpkg/rpm et consorts, travailler proprement du point de vue du développeur, ça fini en règle générale par emmerder l'utilisateur, qui souhaite seulement pouvoir installer la dernière version de son logiciel dès qu'elle est sortie. Sans attendre que les mainteneurs du dépôts de sa distribution daignent s'en occuper. Sans avoir à ajouter un obscur PPA supplémentaire (et en aparté, non, sudo add-apt-repository, ce n'est pas pratique pour l'utilisateur de base). En somme, sans avoir à passer systématiquement par un intermédiaire, et à en être tributaire.
L'idéal serait à mon sens de garder l'existant pour les mises à jour du système. Pour les logiciels "utilisateur", un système tel que PBI/0install/DMG serait beaucoup plus pratique. Le travail propre pour la base du système, le travail rapide pour les logiciels tiers. Ce que propose Ubuntu. Ce que fait OSX depuis des années, et ça marche. Canonical et Apple n'ayant pas que de mauvaises idées.
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . Évalué à 4.
En gros, faire comme font les xBSD par exemple : gérer la partie OS et la partie userland séparément : mon rêve … :) : ça permettrait de mettre à jour les couches applicatives sans forcément toucher aux couches basses (et vice-versa : quoique le contraire risque de ne pas toujours fonctionner).
[^] # Re: C'est plus facile de travailler salement…
Posté par claudex . Évalué à 5.
Vive le One click install d'OpenSuse.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est plus facile de travailler salement…
Posté par Letho . Évalué à 1.
C'est vrai. Par contre, ça ne résout pas le problème de mélanger des sources externes aux sources officielles, ni ne rend les applications plus faciles à empaqueter.
[^] # Re: C'est plus facile de travailler salement…
Posté par claudex . Évalué à 3.
Oui, je répondais à l'apparté. D'ailleurs, un problème que j'ai avec le OCI, c'est qu'il rappatrie potentiellement plusieurs dépôts et qu'il difficile de faire le tri après.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# On force généralement ou pas ?
Posté par kadalka . Évalué à -9.
Dans certains cas, c'est forcé quand même du coup…
# Java Web Start le fait déjà
Posté par Minux13 . Évalué à 9.
Quand je lis les raisons de Canonical je remarque que Java Web Start fait déjà la même chose :
- Gestionnaire d'applications
- Système de mise à jour
- Chaque application peut utiliser une version précise d'une bibliothèque
- C'est du Java donc à priori c'est multiplateforme
- Ça tourne dans un bac à sable
https://en.wikipedia.org/wiki/Java_Web_Start
Quoi ? Comment-ça on n'est pas encore vendredi ?
[^] # Re: Java Web Start le fait déjà
Posté par hsyl20 (site web personnel) . Évalué à 7.
Tout converge vers Java Web Start : les applications web, etc. Sauf que c'est tout refait avec des technos pourries (JavaScript, PHP…) et des VM super lourdes (Firefox…).
Vivement vendredi.
[^] # Re: Java Web Start le fait déjà
Posté par Moonz . Évalué à 10.
Exactement comme Java Web Start quoi.
[^] # Re: Java Web Start le fait déjà
Posté par hsyl20 (site web personnel) . Évalué à 3. Dernière modification le 27 juin 2013 à 18:15.
Exactement. Du coup pourquoi le refaire en aussi pourri, voire souvent pire, 10 ans après ?
[^] # Re: Java Web Start le fait déjà
Posté par Argon . Évalué à 1.
Parce que Canonical veut être maitre de sa bouse :p
Plus sérieusement je ne serais pas étonné que M.S. annonce dans quelques années qu'il laisse tomber gnu-linux au profit de BSD pour suivre les traces de OSX. Quoiqu'il pourrait avoir envie de forker le noyau Linux on ne sait jamais !
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Java Web Start le fait déjà
Posté par Misc (site web personnel) . Évalué à 2.
Canonical n'a pas la même R&D que Apple, et ne peux pas se permettre de devoir faire ses propres drivers si jamais il y a besoin. Bien que Canonical contribues upstream ( sur pulseaudio, twisted, mailman pour ne citer que 3 exemples ), le kernel n'est pas dans la liste. Donc sauf à imaginer que Canonical recrute beaucoup de codeurs kernels, ils sont dépendant du travail des autres pour les couches basses.
Et puis le support des pilotes proprios, c'est pas encore ça. Si Canonical part sur mir, c'est aussi pour aller à coté des kernels android, pour simplifier la vie des OEMs pour les téléphones. Passer sur BSD ferait perdre tout ça.
[^] # Re: Java Web Start le fait déjà
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Je dirais plutôt des technos plus pourries et une vm plus lourde que javaws :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java Web Start le fait déjà
Posté par hsyl20 (site web personnel) . Évalué à 1.
C'est fou, si Sun avait eu l'idée de remplacer Swing par un framework sexy à la ActionScript/Flash, on se serait peut-être épargné Flash, Silverlight, HTML 5, SOAP, node.js, PHP, JSON, etc.
[^] # Re: Java Web Start le fait déjà
Posté par claudex . Évalué à 5.
Tu veux dire JavaFX ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Java Web Start le fait déjà
Posté par hsyl20 (site web personnel) . Évalué à 3.
C'est arrivé beaucoup trop tard.
[^] # Re: Java Web Start le fait déjà
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'ai utilisé swing il y a peu de temps pour créer nanimstudio et j'ai été très surpris: c'est simple, puissant et le designer de netbeans est bien meilleur que tout ce que j'ai vu.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java Web Start le fait déjà
Posté par hsyl20 (site web personnel) . Évalué à 1.
Oui pour faire des interfaces plus ou moins normales, c'est bien. Mais pour faire des trucs kikoolol comme Flash c'est plus difficile.
[^] # Re: Java Web Start le fait déjà
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ca tombe bien la mode est au normal!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Simplification
Posté par Almacha (site web personnel) . Évalué à 5.
C'est vrai que ça nécessite quand même un apprentissage le système de paquets Debian. De mon expérience perso, faire un installateur Windows se fait en 15 minutes (avec Inno Setup) alors qu'il m'a fallut plusieurs jours pour comprendre comment faire un paquet DEB correctement. Je comprends tout à fait que ça rebute les développeurs qui préfèrent passer leur temps à coder leur app que à apprendre la mécanique du système de paquets.
[^] # Re: Simplification
Posté par claudex . Évalué à 10.
Faire un paquet Debian, ce n'est pas compliqué (surtout si on ne respecte pas les règles d'empaquetage pour Debian, ce qui n'est pas grave si on ne vise pas à rentrer dans les dépôts). Ce qui rend la chose compliqué, ce sont les tutoriels qui considère qu'on n’empaquette que des logiciels écrits en C, compilés avec autoconf, avec des dépendances incluses dans Debian. Alors que 95% de ces logiciels sont déjà dans Debian, et ce sont plutôt les autres qu'il faudrait empaqueter.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Simplification
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 1.
Tout a fait!
Et effectivement, lorsque c'est pas du C/cmake and co, il y a plus simple. Perso, j'utilise un pom.xml que je lance, et qui crée un deb/rpm parce qu'il ne s'agit que d'ensemble de fichiers, services… genre le packaging d'une JRE, de services…
[^] # Re: Simplification
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu arrives à créer un deb source avec ton système?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Simplification
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 1.
Jamais essayé, mais je ne crois pas que cela soit le but (en tout cas pas le mien).
L'idée est de pouvoir créer facilement un installable windows (izpack), Linux (rpm/deb/ipk) pour un soft binaire (java ou autre) ou des fichiers (genre des .php a mettre dans le bon répertoire), définir des services pour init.d, une icone et entrée de menu…
Pour un soft c ou C++ qu'on voudrait distribuer en source, je crois qu'on retombe sur les procedures des distribs. Mais dans mon cas (java, php, …), cela m'évite, en tant que développeur, d'avoir à écrire une procédure d'installation en production (qu'un admin va en plus foirer en ne la suivant pas… déjà vu…).
Avec ma méthode, l'admin reçoit un deb/rpm qu'il installe, les fichiers sont copié là ou il faut, les paramétrages sont également fait, les permissions aussi, tout marche nickel. Et tout ce que j'ai eu a faire c'est une poignée de ligne xml. Les deb/rpm sont testé avant en deploy automatique sur les serveurs de qualification à chaque commit SVN, donc la qualité de l'installation est garantie.
[^] # Re: Simplification
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'en suis au même point que toi!
Mais j'aimerais que certains de mes logiciels puissent être intégré dans les dépôts des distribs, mais là ça coince, impossible de comprendre comment faire :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Simplification
Posté par Firwen (site web personnel) . Évalué à 9. Dernière modification le 27 juin 2013 à 15:18.
Si ça l'est, tout comme RPM d'ailleurs…. Et c'est un packageur officiel qui dit ça.
Si c'est pour fournir des .deb ou .rpm pas compilés depuis les sources, sans utiliser les auto-deps ( autoReqProvides ), sans respecter les path standard, sans être arch independant et sans respecter les consignes les plus basiques du packaging…
Alors vaut mieux distribuer des tarballs, des .img, zeroinstall, nix ou je ne sais pas quel système de packaging maison.
1 - ça evitera de péter betement une dépendance système, ce que 3/4 des "dirty packages" font.
2 - ça evitera de meler lib systeme "propres" et cochonneries propriétaires mal installées ( et souvent impossible à désinstaller proprement )
2 - ça pourra s'installer sans droit root dans le $HOME utilisateur simplement.
3 - ça evitera potentiellement pas mal de risque de sécurité… Je ne compte même pas les pseudo faux RPM qui download des tar.gz sans encryption, sans gpg check, sans verification… depuis la section "postinstall" executée en …. droits root.
Si OSX, Android, BSD, NixOS, RedHat ont déployé des systèmes similaires, c'est qu'il y a potentiellement une raison.
[^] # Re: Simplification
Posté par claudex . Évalué à 1.
Donc, ça ne rentre pas dans la catégorie : « surtout si on ne respecte pas les règles d'empaquetage pour Debian ».
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Simplification
Posté par Firwen (site web personnel) . Évalué à 4. Dernière modification le 28 juin 2013 à 13:08.
Certes, mais ça n'est reste pas moins un problème.
Utiliser rpm/deb pour des packages proprio, c'est utilisé un système de package pour une utilisation qu'il n'a jamais été prévu pour.
Le .deb ou le .rpm est prévu pour une compilation depuis les sources, une gestion de dépendances automatisée ( autoReqProv sur RPM ), une installation système en droit root, en espace système, centralisée et cohérente…
Si c'est pour installer un soft "dirty" en espace utilisateur, encore une fois, mieux vaut se tourner vers un système comme zeroinstall ou Nix pour tout un tas de raison que j'ai précisé plus haut.
[^] # Re: Simplification
Posté par Michaël (site web personnel) . Évalué à 6.
La dernière fois que j'en ai fait, il m'a fallu plusieurs jours pour comprendre que la doc que je lisais n'était pas à jour, et que la doc à jour était seulement disponible sur Freenode.
C'est sûrement en partie pour cela que je reste sous FreeBSD.
# ZeroInstall façon Ubuntu
Posté par NanoTech . Évalué à 7.
Le système se rapproche beaucoup de ZeroInstall (ou des appli Android/iOS)
Chaque appli est installée dans son propre répertoire.
Il y a des dépendances sur les paquetages deb (comme pour un deb normal), mais il n'y a pas de dépendances sur un autre paquet utilisateur.
Conséquence: Pas de conflit entre appli tierces.
Le problème de sécurité et partage des librairies n'est présent que si l'appli décide d'utiliser une librairie qui n'est pas fournie par les paquetages deb d'Ubuntu.
# Argument bidon!
Posté par haleth . Évalué à -1.
Ouais, c'est encore des arguments bidons.
Parcque faire un truc dégeu, c'est facile. Il suffit de compiler tout en statique et hop !
[^] # Re: Argument bidon!
Posté par Firwen (site web personnel) . Évalué à 5.
Non, il y a des tas de raisons qui peuvent t'empecher de compiler en statique.
Si tu distribues une appli proprio qui utilisent des bibliothèques en LGPL par exemple.
[^] # Re: Argument bidon!
Posté par Paul Chavent (site web personnel) . Évalué à 0.
J'aurai dit la même chose que haleth pour le statique.
Est-ce qu'il y a un article qui interdit de distribuer un logiciel propriétaire compilé en statique avec des librairies sous licence libre ? Et qui autorise à le distribuer si le chargement des librairies est dynamique ?
[^] # Re: Argument bidon!
Posté par Firwen (site web personnel) . Évalué à 5.
Oui si la shared library est sous LGPL, un soft qui link en static se doit d'être sous GPL ou LGPL.
http://stackoverflow.com/questions/10130143/gpl-lgpl-and-static-linking
[^] # Re: Argument bidon!
Posté par Loïc Ibanez . Évalué à -1.
C'est pas dégueu, c'est mon rêve °_°
[^] # Re: Argument bidon!
Posté par Misc (site web personnel) . Évalué à 2.
Pour toi, y a ça :
http://sta.li/
Et ça :
http://statifier.sourceforge.net/
si ça marche encore. Je suis sur qu'ils cherchent tout les 2 des testeurs.
[^] # Re: Argument bidon!
Posté par Loïc Ibanez . Évalué à 1.
Merci.
Je connaissais le second lien, mais pas le premier. Je vais regarder tout ça de plus près.
# macosx / dmg
Posté par Prosper . Évalué à 10.
Les .dmg ne sont pas un format de paquet , c'est une image disque. Sous macosx ce qui semble proche des .apk ou les .pbi ce sont les bundle .app .
[^] # Re: macosx / dmg
Posté par Loïc Ibanez . Évalué à 3.
Oui, c'est le même système que les .scm de tiny core linux ou l'appimagekit format.
Il me semble que c'est Knoppix qui avait introduit ça à l'époque ( des cloop au début - des squashfs aujourd'hui)
L'avantage c'est qu'il n'y a aucune fragmentation et que l'on peut monter intégralement l'application en ramdisk. Ce que je trouve TRES pratique.
# « Vivent les Logiciels Privateurs ! »
Posté par Space_e_man (site web personnel) . Évalué à 3. Dernière modification le 28 juin 2013 à 08:27.
Pour moi cela n'est réellement utile que pour les logiciels privateurs.
Mon impression est que finalement, un système basé sur, et sensé être entièrement constitué de logiciels libres, ça pose un problème à Canonical…, déjà avec les pilotes privateurs et les blob dans le noyau…
Là, ils cherchent uniquement à simplifier la vie aux développeurs de logiciels privateurs… Et bien entendu, de fait, nous perdons tous l'intérêt d'un système GNU.
Le côté machines virtuelles, bac à sable, etc. Ok, pourquoi pas isoler les processus, protéger les ressources, etc. Mais cela a toujours été l'idée au cœur du système, le noyau… Hurd devait aller plus loin que Linux dans ce domaine…
Pensez à des distrib' telles que Gentoo pour comprendre que la compilation (du fait de la disponibilité des codes sources et des libertés de pouvoir les adapter et les compiler soit-même) permet de faire tout évoluer de manière cohérente et harmonieuse (d'un point de vue binaire).
Et qu'est-ce qui posait un problème alors ? Les logiciels privateurs !
Voila donc la solution pour résoudre le problème des logiciels privateurs : s'éloigner encore du projet GNU :(
Et c'est pas nouveau en plus…
Ce qui est nouveau, c'est « l'institutionnalisation » des cette
solutionoption chez Canonical avec Ubuntu.[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par xcomcmdr . Évalué à 7.
Mon impression est que Canonical suit ses objectifs depuis le début : offrir une distribution qui s'adapte au grand public avant d'être libre.
Il y a des distributions qui sont d'abord libres, il n'y a qu'à les utiliser si on n'aime pas cette politique.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par kadalka . Évalué à -9.
Ayant utilisé Linux Mint et Ubuntu, je crois que c'est plus Linux Mint qui s'approche de cette définition.
Donc pour de l'ubuntu la personne va faire du Trisquel ?
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par xcomcmdr . Évalué à 2.
Moui. 'fin installer le paquet *buntu-restricted-extras, ça prend 5 minutes.
Et au moins, *buntu reste légale dans les pays où les brevets logiciels sont reconnus (comme les États Unis).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par Misc (site web personnel) . Évalué à 4.
Si tu fait abstraction du fait que le paquet openssl active le support des courbes elliptiques (ECDSA) ( https://bugzilla.redhat.com/show_bug.cgi?id=319901 ) alors que c'est une fonctionnalité jugé problématique du point de vue des brevets logiciels.
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par xcomcmdr . Évalué à 1.
J'aurais jamais pensé qu'OpenSSL aurait des problèmes de brevets.
Le moindre codec vidéo/audio, on a l'habitude.
Mais là j'ai l'impression de découvrir une autre partie d'un monstre tentaculaire.
Il y a d'autres logiciels qui n'ont rien à voir avec une technologie MPEG/ITU-T, et qui pourtant ont des problèmes avec les brevets ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par Misc (site web personnel) . Évalué à 5.
Si j'en croit groklaw, il semble que certains attaquent RH pour glusterfs cf http://www.groklaw.net/articlebasic.php?story=20120913073511444 et à vue de nez le truc serait assez vague pour couvrir aussi ceph, par exemple (ceph qui est aussi poussé par Mark Shuttleworth, qui a investi dans inktank après que RH ai racheté Glusterfs)
Tu as des histoires autour de s3tc, ce qui impacte mesa, des drivers, mais aussi de façon surprenante darktable (qui est dans universe sur Ubuntu), cf https://bugzilla.redhat.com/show_bug.cgi?id=972604
Ensuite, il faut voir qu'il s'agit de gestion de risque. Si j'en crois les documents remplis par Red Hat pour la SEC, l'estimation d'une affaire de brevets, c'est de l'ordre de 0.1 à 11 millions de dollars ( cf page 36 du rapport 2010 pour la SEC ). Donc tu sais qu'une boite trop petite ne va pas être attaqué. Mais si tu rentres dans la catégorie "assez grosse pour sortir 1 à 10 millions de dollars sans mourir", alors oui, le risque est la. Par rapport par exemple aux chiffres d'affaires d'une maison d'édition comme Ziff Davis, ça me semble pas irréaliste d'imaginer qu'ils sont vulnérable, par exemple. Mais tu peux aussi imaginer Dell ou un autre OEM.
Mais curieusement, ils se font pas attaqué sur ça, en tout cas pour le moment.
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par totof2000 . Évalué à 5.
Il y a quand même un truc dont il faut te rendre compte : le logiciel proprio existe et si le libre veut vivre, il faut qu'il puisse cohabiter avec (c'est pas le proprio qui fera l'effort).
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par zebra3 . Évalué à 1.
Je n'ai pas de logiciel proprio sur ma machine, et pourtant le libre installé dessus fonctionne. Comme quoi…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Faire un deb propre, c'est difficile et pas vraiment documenté. Je ne sais pas pourquoi, mais ça fait des années que ça dure. Il y a peut être un blocage qui a amené à la réinvention de roue?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par NanoTech . Évalué à 1.
C'est peut être difficile, mais c'est bien documenté, du moins pour un développeur assez expérimenté.
http://www.debian.org/doc/manuals/maint-guide/
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par claudex . Évalué à 3.
Cette doc ne donne que des exemples pour du packaging d'applications en C avec les autotools, je n'appelle pas ça bien documenté.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par zebra3 . Évalué à 2.
En effet. Mais faire un deb sale, c'est pas difficile du tout :
Il fallait vraiment un nouveau format juste pour ça ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Ben non, il fallait juste prendre rpm :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par zebra3 . Évalué à 2.
Tu dis ça sur le ton de l'humour mais c'est pas bête du tout : avec alien tu convertis ton RPM en deb et boum, ça s'installe partout.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.