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…
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.
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?
Ben je ne sais pas : peut-être parce que RedHat par exemple serait un éditeur que je paie pour ça ?
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…
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.
1) Abandon de copyright à Ubuntu pour les contribs associé à la GPLV3. Imagine toi Redhat ou Suse accepter cela…
Ils ne le font pas lorsqu'ils corrigent des bugs sur les softs gérés par la FSF ?
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)
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.
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.
Si tu es admin de métier et que n'es pas capable de lire/écrire des scripts, change de métier.
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.
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.
systemd peut lancer des scripts init si tu veux…
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).
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".
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.
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 ?
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 ?
Le problème c'est que nombre de personnes sont persuadés que son besoin propre est supérieur à ceux des autres.
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.
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).
Je ne supporte pas la phrase que j'ai mis en gras et qui ne veut rien dire.
systemd peut rendre le comportement précédent identique si tu le souhaites (il supporte les scripts init).
Ca je m'en moque : j'ai un truc au démarrage qui est loin nd'être aussi simple que le principe d'init de base. Et ça ce n'est qu'une partie du problème.
Il y a beaucoup d'autres administrateurs systèmes qui au contraire adorent systemd car leur boulot est simplifié dans de nombreux cas.
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.
Sans compter les distributions pour qui cela simplifie énormément la tâche de maintenance des services.
au détriment de l'admin qui devra redémarrer un serveur dans la nuit suite à un problème.
J'ai un gros doute qu'autant de distributions mettraient par défaut un système aussi "pourri" par défaut (voire en option).
autant de doute vis à vis des constructeurs qui installent par défaut un Windows ?
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é)…
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.
2 poids, 2 mesures… Moi qui croyais que les amateurs de Linux préféraient la réutilisation plutôt que de réinventer!
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 ?
Si tu as une meilleure solution pour répondre au besoin tout en respectant cette phrase, n'hésite pas, propose!
Peux-tu STP me récapituler le besoin (ou me fournir un lien vers le besoin ) histoire qu'on soit en phase sur celui-ci ?
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.
C'est à dire ? je ne te suis plus là.
J'ai l'impression que ce que tu critiques, c'est que systemd réponde au besoin.
Quel besoin ? Je pense que justement tout est dans la définition du besoin …
se fait descendre car il a une politique sur la licence limite…
Peux-tu développer STP ?
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.
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 vois aussi une différence : tu as décidé que systemd était une "bouse immonde", donc tu chercheras tout pour cracher dessus.
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.
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.
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).
Ce n'est pas parce que tu as subjectivement décidé que c'était une bouse immonde que ça l'est en réalité…
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 …).
La différence est que beaucoup de monde a adhéré à systemd.
Beucoup de monde a adhéré à windows, ça n'en fait pas le meilleur OS du monde, loin de là. Beaucoup de monde a adhéré à la candidature de F. Hollande, ça nen fait pas le meileur président du monde, loin de là (c'était la même chose de son prédécesseur). Si le fait que beaucoup de monde adhère à quelque chose étit un gage de qualité et de bon sens, ça se saurait.
Il n'y a pas 2 poids, 2 mesures, sauf chez toi.
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).
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
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.
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).
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 ?
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.
Quand je vois ça : "Written using the Ruby on Rails framework, it is cross-platform and cross-database." , je me dis que ça ne peut être que très bien (pas de serpent affreux en vue … ;)
Merci, je vais jeter un oeil … J'en avais entendu parler à plusieurs reprise (notamment lorsque je m'étais mis à RoR), mais jamais éprouvé le besoin de l'utiliser jusque maintenant.
Merci pour ces retours. Le choix des outils est un autre problème (je vais regarder ce qui se fait et choisirai en fonction de ce que je trouve plus ou moins pratique).
L'installateur Debian semble être familier de ce genre de problèmes : je me rappelle avoir fui Debian à une époque justement à cause de ça. Si on faisait une installation standard, ça passait bien ais dès qu'on voulait réaliser un partitionnement personnalisé, ça partait en vrille, avec impossibilité de revenir en arrière lorsqu'on faisait une erreur (il fallait tout reprendre de zero).
Malhereusement, il semble que ce soit toujours le cas aujourd'hui :(
. Une solution est de le démonter, de le brancher dans un PC fixe à la place du disque dur normal, et de booter sur un ubcd qui réunit tous les utilitaires constructeurs : http://www.ultimatebootcd.com/
A titre personnel, je le fais systématiquement lorsque j'achète (ou reçois) un nouveau disque dur. Ca m'a déjà permis de m'éviter des complications (échange standard le lendemain de l'achat auprès du vendeur, plutot que de devoir passer par la garantie constructeur après quelques mois).
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
Par exemple : http://packages.debian.org/wheezy/systemd
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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: « Vivent les Logiciels Privateurs ! »
Posté par totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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: C'est plus facile de travailler salement…
Posté par totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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 totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à -2.
oui, et qui moinssent lorsqu'on leur fait la remarque …
[^] # Re: C'est plus facile de travailler salement…
Posté par totof2000 . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. É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: Redmine
Posté par totof2000 . En réponse au message "Nécessaire" de démarrage pour développement d'un projet libre.. Évalué à 2.
Quand je vois ça : "Written using the Ruby on Rails framework, it is cross-platform and cross-database." , je me dis que ça ne peut être que très bien (pas de serpent affreux en vue … ;)
Merci, je vais jeter un oeil … J'en avais entendu parler à plusieurs reprise (notamment lorsque je m'étais mis à RoR), mais jamais éprouvé le besoin de l'utiliser jusque maintenant.
[^] # Re: Taille de la communauté
Posté par totof2000 . En réponse au message "Nécessaire" de démarrage pour développement d'un projet libre.. Évalué à 2.
Merci pour ces retours. Le choix des outils est un autre problème (je vais regarder ce qui se fait et choisirai en fonction de ce que je trouve plus ou moins pratique).
[^] # Re: De l'immense gâchis structurel que constitue le recours systématique aux grandes SSII
Posté par totof2000 . En réponse au journal La carte Navigo - quand Big Brother part à la rencontre de Kafka. Évalué à 2.
de par mon expérience : plus la SSII est grosse, plus elle met de pression sur les commerciaux et plus les CV sont trafiqués.
Personnellement jamais un commercial n'a modifié mon CV sans me tenir au courant, mais dans mon entourage c'est ce que j'ai constaté.
[^] # Re: De l'immense gâchis structurel que constitue le recours systématique aux grandes SSII
Posté par totof2000 . En réponse au journal La carte Navigo - quand Big Brother part à la rencontre de Kafka. Évalué à 2.
Je ne t'ai pas demandé de nom …. :)
[^] # Re: De l'immense gâchis structurel que constitue le recours systématique aux grandes SSII
Posté par totof2000 . En réponse au journal La carte Navigo - quand Big Brother part à la rencontre de Kafka. Évalué à 3.
Je dirais plutot :
tout ton public d'informaticien n'a pas réagi sur la 3eme partie parce que c'est normal pour eux (qui bossent en SSII).
Au fait c'est quelle SSII ? "As de pique rouge" ?
# openfuca ...
Posté par totof2000 . En réponse au message souci avec opentransit ?. Évalué à 8.
Ca devrait résoudre les problemes d'opentransit.
[^] # Re: Je suis sans-doute de mauvaise fois mais...
Posté par totof2000 . En réponse au journal Ma vie et debian.... Évalué à 3.
L'installateur Debian semble être familier de ce genre de problèmes : je me rappelle avoir fui Debian à une époque justement à cause de ça. Si on faisait une installation standard, ça passait bien ais dès qu'on voulait réaliser un partitionnement personnalisé, ça partait en vrille, avec impossibilité de revenir en arrière lorsqu'on faisait une erreur (il fallait tout reprendre de zero).
Malhereusement, il semble que ce soit toujours le cas aujourd'hui :(
[^] # Re: GRUB sur /dev/sda
Posté par totof2000 . En réponse au journal Ma vie et debian.... Évalué à 0.
Et ils utilisent aussi les adresses IP plutôt que le nom DNS ?
Dans le genre régression, c'est pas mal ….
[^] # Re: install sur /dev/sda
Posté par totof2000 . En réponse au journal Ma vie et debian.... Évalué à 2.
A titre personnel, je le fais systématiquement lorsque j'achète (ou reçois) un nouveau disque dur. Ca m'a déjà permis de m'éviter des complications (échange standard le lendemain de l'achat auprès du vendeur, plutot que de devoir passer par la garantie constructeur après quelques mois).