gnumdk a écrit 7492 commentaires

Bluetooth et Avahi, ça a de la gueule sur un serveur en prod !

Mon dieu!!! Y'a deux dépendances vers une pauvre librairie, c'est la fin du monde, t'as raison, recompile tout! A ta place, je passerai sous Gentoo histoire d'optimiser un peu tout cela, ca se trouve, tu pourrais virer directement le support cups de samba, puis virer le support usb de cups, …

Et en plus, dans le cas de Arch, les paquets étant peu découpé, le service est installé mais je ne pense pas qu'il se lance tout seul.

Pfff, ca devient insupportable les mecs qui parlent de systemd sans savoir de quoi ils parlent…

Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit…

Mais bon, c'est tellement plus simple d'utiliser la bonne vielle technique du Fear, uncertainty and doubt.

Ou alors systemd répond à un besoin que sysvinit n'est pas capable de comblé…

Parce que bon, tu oublies quand même ArchLinux dans l'histoire, et tu le fais exprès en plus pour appuyer ton propos.

autant de goto

Comme dans le noyau Linux

de dizaine de return par fonction

Comme dans le noyau Linux

de pointeurs non-initialisés à NULL

Mwai, ca ce discute, mais bon, quand tu fais:

Manager *m;

assert(_m);
assert(running_as >= 0);
assert(running_as < _MANAGER_RUNNING_AS_MAX);

if (!(m = new0(Manager, 1)))
                return -ENOMEM;

Ca n'a absolument aucun intérêt de l'initialisé à 0 quand tu fais l'init 3 lignes plus bas…

Mais bon, après, tout ce que tu dis, c'est ce qu'on m'a appris à l'école mais c'est un peu la guerre de clocher entre les devs system et les devs objets.

Je n’ai pas trouvé de documentation qui me soit accessible.

https://wiki.archlinux.org/index.php/Systemd#Writing_custom_.service_files

Je précise que c'est une techno linux only qui n'est pas obligatoire pour démarrer comme dbus… Pourtant systemd dépend aussi de udev et cela n'a pas l'air de gener ;)

Non, j'utilise puppet

Quand un truc s'arrête brutalement, je veux savoir pourquoi avant de le redémarrer

Tu travailles dans une MJC, c'est ça ?

De plus, si vraiment t'as un service non critique, ben tu dis à systemd de pas le redémarrer automatiquement.

Euh, comprendre le fonctionnement de systemd, c'est à la porté de toute le monde, t'inquiètes que les prochains Linuxiens qui n'ont connu que cela le comprendront, après si tu ne veux pas faire d'effort…

Bref, c'est plus abordable de comprendre la conf de systemd que de comprendre la syntaxe de bash pour un profane…

10 heures à apprendre un nouveau systeme qui me ferait gagner 30 secondes à chaque reboot,
si je ne reboot mon serveur que quelques fois par an

Si tu pouvais passer 10 minutes à comprendre ce que fait systemd plutot que de montrer que tu n'en sais rien… Si systemd avait été créer pour gagné 30 seconde au boot, alors upstart suffisait…

les serveurs n'ont pas besoin de systemd

C'est vrai que le reprise d'un service sans coupure en cas de segfault d'un service, c'est pas du tout intéressant…

les portables et les ordinateurs de bureaux entrent et sortent de veille (ils démarrent
une fois chaque mois)

T'en connais beaucoup des gens toi qui n'éteignent pas leur pc et même leur portable ?

Quand on compare ça à un inittab ou on peut remplacer /etc/init.d/rc par ce que je veux

Tu rajoutes init=/bin/ton_init.sh dans les paramètres de ton noyau et cela fera ce que tu veux… Si t'as pas envie de dbus, je vois pas pourquoi t'aurais envie de udev donc y'a pas de problème… Ton Linux fonctionnera comme tu le veux.

J'ai monté toutes les salles infos de mon école d'ingé en double boot Windows/Ubuntu avec auth Active Directory…

Et bizarrement, j'ai bien galérer la dessus mais c'est très simple en fait:

$ cat /usr/share/glib-2.0/schemas/19_ensat.gschema.override

[com.canonical.indicator.session]
suppress-restart-menuitem=true

[org.gnome.nautilus.desktop]
computer-icon-visible=false
home-icon-visible=false
network-icon-visible=false
trash-icon-visible=false

# glib-compile-schemas /usr/share/glib-2.0/schemas/

et c'est torché

2 secondes sur mon laptop entre syslinux et kdm avec systemd, voilà mon sentiment…

Après, il faut savoir ce que l'on test, en gros, si on installe systemd en mode compatibilité sysvinit, y'a peux de chance que ça aille plus vite… Mais c'est surement trop dur de lire une doc…

2) it is modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand. I.e., if you don't like how systemd e.g. does it's fstab handling, then you can write your own little helper (in bash if you wish) to replace the official one. Doing this in the old initscripts is much harder because 1) it is not so clear which parts of rc.sysinit are dependent on eachother 2) any changes you do you'll have to merge on every update.

J'aime bien cette partie qui fout à la poubelle les arguments de anti systemd qui pense qu'ils pourront plus contrôler leur système après alors que c'est tout l'inverse…

C'est un peu facile de cracher sur systemd quand on utilise ArchLinux…

Ca fait des mois que l'init standard Archlinux me fait des FAILS sur toutes mes machines aléatoirement (un shutdown sur trois) donc dois je en déduire que l'init Archlinux n'est pas stable ?

Par contre, sur mon laptop sous ArchLinux avec systemd, je n'ai aucun problème…

Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique
libre, pour moi.

Dans ce sens-là, tu dois penser la même chose de udev avant systemd non? Ce truc codé pour Linux et qui bloque la liberté des BSDistes…

Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois
ans que va mettre systemd à crever ne m'enchante pas.

L'espoir fait vivre hein, bon courage :p

Désolé, je n'ai pas la place d'avoir deux installations de KDE (une en utilisation
courante et la version dév) chez moi. Je vais donc arrêter de traduire. Merci de m'avoir
ouvert les yeux.

Genre t'as un disque dur de 8Go ? C'est quand même un problème, alors je sais que les devs essayent de vous donner du contexte mais pas vous faire savoir si la phrase traduite va complètement défigurer une boite de dialogue…

Comment veux-tu motiver une équipe si elle se fait critiquer de la sorte ?

J'ose quand même espérer que les gens qui traduisent KDE ne le font pas pour moi, donc c'est mon avis, tranché certes mais c'est un problème que je n'ai jamais rencontré chez GNOME…

Et je tiens quand même à rappeler que c'est moi qui me suis fait agresser alors que je précisais juste que Amarok n'avait peu être traduit en Francais… Ah aucun moment je ne faisais une critique sur la trad de KDE à ce moment là… Après, si on m'y invite…

C'est pas comme si je n'avais pas l'habitude se signaler des problèmes avant, il suffit de chercher sur la liste…

J'avais même fait remonté les problèmes de taille de chaine de caractères mais il n'a été pris en compte qu'a un instant t…

http://markmail.org/message/iomnv4extxcuelkk#query:+page:1+mid:llpthvlld5mxpojk+state:results

Il faudrait que ce soit un principe de base chez les traducteurs KDE (comme cela se passe chez GNOME): toujours réfléchir à la pertinence de faire une traduction mot à mot et surtout lancer le logiciel pour avoir une idée de ce que l'on traduit.

L'autre raison et que GNU/Linux se trimbale une architecture UNIX où un maximum de choses
sont en userland ce qui est loin de pouvoir donner un maximum de performances sur un
ordinateur personnel.

Euh, c'est plutot l'inverse, Linux fait un maximum de chose en kernel space, voir même trop comparé à Windows, après OSX je sais pas…

Ca fait longtemps que la plupart des éléments de Windows ne tournent plus en Kernel Space, c'est un choix que Linus assume de son coté…

Les belles icônes de windows

"Gnome isn't really a desktop anyway - it's a research project."

Effectivement, ca taille :)

Name[fr]=Gestionnaire de tâches à icônes uniquement

Dans le fichier .desktop, je suis au courant… Mais je trouve idiot de vouloir traduire une chaine comme "Icon-Only Task Manager" mot à mot alors que en français, c'est vraiment trop long et ca veut surtout rien dire…

Name[fr]=Gestionnaire de tâches à icônes
me semble mieux, et la perte d'information est nulle.