Renault a écrit 7419 commentaires

Ingénieurs en quoi ? Et pour combien d'années d'expériences ?
Un ingénieur peut travailler dans des secteurs hyper variés avec des salaires hauts comme bas, avec du chômage ou pratiquement pas… Donc dire cette phrase est trop vague. Tu ne compares pas le salaire d'un médecin généraliste avec un cardiologue pour des raisons assez similaires.

Le travail ne se trouve pas qu'au centre ville des grands centres, leurs banlieues accueillent aussi des entreprises compétentes qui ont besoins d'ingé. Du coup tu es plus proche et tu payes le logement moins cher.

EDIT : puis accessoirement, les transports en communs existent pour les trajets un peu long (trains ou bus) ce qui réduit fortement la facture liée au transport sans forcément ajouter du temps de transport en plus.

C'est pas Paris, c'est PACA.

PACA c'est vaste et tu as de grandes inégalités dans le prix du logement dans la région.
Si tu veux vivre près de Marseille, Toulon, Nice ou Aix (ou plus simplement, près de la mer), oui tu vas payer cher le logement… Mais dans les coins plus reculés (et il y en a en PACA), c'est plus raisonnable.

C'est une question de choix.

J'utilise personnellement Rsync qui me convient.
1 sauvegarde hebdomadaire sur un serveur maison qui est incrémental (donc les fichiers supprimés sur mon hôte sont conservés) avec synchronisation totale chaque mois (pour éviter de perdre trop de place et du temps à trier).
Ensuite, une sauvegarde mensuelle sur un disque dur externe en synchronisation avec l'hôte pour la même raison (et cela me permet de faire un peu de redondance).

Il reste le problème d'une catastrophe type inondation ou incendie qui pourraient tuer les 3 disques. Mais je pense que ça reste déjà une bonne prévention pour les pannes matérielles ou logicielles.

Des systèmes scolaires qui fonctionnent mieux il y en a à l'étranger, pas besoin d'utiliser les villes comme laboratoires pour vérifier que ça existe et que ça fonctionne bien à l'échelle d'un pays. ;)

Oui c'est bien pour cette raison.
Bien que, le FAT32 n'a pas encore 20 ans, il se pourrait que le système de fichier soit bardé de brevets encore jusqu'en 2016.

c'était une volonté d'IBM.

Oh que non.
IBM n'y croyait pas aux PCs au départ, ils ont fait un investissement considéré comme modique pour leur projets habituels. Et pour que ça coûte moins cher et que ça sorte plus vite, 90% des composants ont été achetés à des entreprises comme Intel. Il ne reste que la puce BIOS qui était faite maison.

Du coup les concurrents comme Compaq n'avaient qu'à trouver la liste des références et les fabricants. Ensuite rétro ingénierie sur la seule puce faite par IBM et tu as un compatible PC.

IBM n'a pas voulu avoir un environnement ouvert, c'est une conséquence de leur choix pour ce projet. De plus, Bill Gates a voulu dans le contrat avoir la liberté de revendre MS-DOS à d'autres fabricants. Du coup tu peux avoir plein de concurrents avec le même système et compatible entre eux ce qui implique une facilité de concurrence qui a aidé à faire baisser les prix ce qui a attiré le consommateur lambda.

Sophie Gautier (LibreOffice), Anne (Mageia)

Avec toute la reconnaissance que j'ai envers leur travail, de mémoire elles ne sont pas développeuses mais respectivement documentatrice/traductrice et manager.

C'est bien entendu un travail important, mais ça fait hors sujet par rapport au but de la liste.

Le problème est que dans certains marchés on vend le produit qui n'existe pas encore appels d'offres ou projet assez volumineux par exemples). Du coup le commercial va vendre des qualités techniques et enchérir dessus sans savoir si effectivement les ingénieurs sauront le faire avec les moyens proposés.

Ça explique l'échec de nombreux projets, où le choix des produits (achats) et la revente sont définies par des commerciaux.

J'ai comme l'impression que c'est, pour des raisons pragmatiques, la fin de la pureté de Java comme langage orienté objet.

Java n'a jamais été pur niveau orienté objet.
Donc ça ne change pas grand chose, entre presque pur et presque-presque pur, on n'est plus à deux exceptions près. ;)

peu être l’hémorragie vers les US (faut dire que quand ils arrivent et proposent salaire_fr*5 ça calme) …

Attention aux comparaisons de salaires US-France. Même si c'est vrai qu'un développeur peut avoir une meilleure paye aux US, cela ne signifie pas qu'il y vit mieux. Car en France une bonne partie du salaire va payer l'éducation, la santé et d'autres services publics qu'aux USA il faut (en tout cas plus souvent) mettre la main à la poche.

Mais c'est vrai pour la réflexion sur les salaires où globalement en France le développeur est peu valorisé financièrement par rapport à la finance ou la gestion… Alors que les développeurs ont un potentiel de création d'emplois plus intéressants.

Je croyais qu'il était développeur à l'époque Netscape mais ça semble ne pas être le cas. Mea culpa.

Je ne serai pas si sûr que ça pour l'avenir. Aujourd'hui on voit apparaître pour les bureaux des montages "par siège" (au passage, je déteste cette expression), et tu te retrouves à avoir des périphériques montés différemment selon la personne qui s'est connectée.

Cela n'a rien à voir. En tout cas avec l'implémentation actuelle, c'est juste monté dans un répertoire spécifique avec des droits d'accès particuliers pour éviter que la clé USB monté par un compte X soit visible par le compte Y. Mais c'est dans la même arborescence.

De toute façon la racine doit être unique, contrairement à Windows où ce n'est clairement pas le cas. Donc ça ne devrait pas changer.

Il me semble qu'il y a aussi ce cas de figure sous Linux.

Non justement.

Je ne comprends pas ce que tu veux dire là. Mais pour l'utilisateur lambda, ça veut dire quoi "grace au préfixe "XDG_" " ?

Va voir ce projet : http://www.freedesktop.org/wiki/Software/xdg-user-dirs/
En gros l'utilisateur spécifique que le répertoire Documents est /home/utilisateur/Documents (ou autres), ce qui le fixe à cette valeur dans l'arborescence à tous les niveaux. certains environnements comme Gnome te proposent de changer le nom en cas de changement de langue de la session, et dans ce cas ça renomme effectivement le dossier via cette variable. Sous Windows il semble avoir une couche intermédiaire qui rend le changement effectif que pour le navigateur de fichier mais pas les utilitaires plus bas niveaux…

Quelle attaque gratuite.
Plus sincèrement, c'est l'avantage d'UNIX du fait que tout est au sein d'une même arborescence. Ça limite les problèmes, alors que sous Windows chaque partition ou périphériques a son propre arbre, certains dossiers sont "isolés" ou font semblant de l'être (les bibliothèques décrits plus haut, la Corbeille ou le Bureau qui peuvent être considérés comme le sommet de la hiérarchie).

Un problème que j'avais vu sous Mac OS X et Windows aussi c'était la traduction du chemin. Quand ils renommes Users en utilisateurs ce n'est vrai que dans la vue du navigateur de fichiers, aux yeux des couches plus basses c'est la version anglaise qui existe. Du coup ça peut mener à des confusions, des incohérences et autres. Grâce à Freedesktop.org, les dossiers traduits via les préfixes XDG_* pour définir le dossier des documents, téléchargements et autres permet d'avoir le chemin en dur (voir de le renommer en cas de volonté de changer de langue, mais il n'y a plus d'incohérence où la traduction et l'originale cohabite au sein d'une même session).

Daniel Lezcano, un des auteurs des LinuX Containers.
Tristan Nitot et Pascal Chevrel chez Mozilla sont également connus et ont beaucoup œuvré.

De plus la liste me semble assez Debian centré, j'aurais bien mis quelques contributeurs Fedora et autres dans le lot (mais c'est vrai que la liste deviendrait très longue).

Il y a je crois de quoi dire sur les langages de programmation où je crois qu'il y a des développeurs français pour le projet Python, mais aussi Inria qui a produit Coq et ce type de choses.

En fait je pense qu'une liste de 1000 noms auraient été préférables, 100 on y arrive assez vite rien que dans le LL…

Tu auras la prononciation correcte, l'écriture exacte

Ça c'est faux. Un sous-titre, même en VO, n'a pas le même texte écrit que celui qui est prononcé.
Et c'est normal, l'objectif est de lire vite quitte à modifier certains mots/phrases pour garder certes le même sens mais permettre une lecture plus facile et rapide pour suivre l'action.

Donc il faut faire attention, parfois ça change un peu.

Je pense que tu as mal compris sa phrase. Il ne vante pas Windows en tant que produit mais en tant que projet.
Oui, dans le milieu informatique industriel, un programme qui fonctionne pas trop mal dans des cas aussi variés peut être considéré comme un exploit (ça ne devrait pas, mais c'est une autre histoire).

Donc ce n'est pas Windows le haut de gamme, c'est le fait de travailler dessus qui est du haut de gamme. La différence est de taille. Et c'est vrai que même si on n'aime pas forcément l'utiliser, programmer un OS complet fonctionnel est un défi d'ingénierie de qualité intéressante par rapport à ce qu'on peut trouver ailleurs…

Non, mais le Qt qu'il a sous la main, normalement, c'est celui pour Linux, il n'a pas sur lui le Qt compilé pour Mac OS X qui contient donc les instructions spécifiques à ce système.

Après tout dépend s'il veut livrer son programme avec Qt compilé statiquement ou dynamiquement. Mais sous Mac OS X en général la livraison est "tout en un".

sinon OSX tournant maintenant sur processeur "intel", la maniere d'ecrire le code est la meme.

Les appels systèmes, les bibliothèques disponibles, le format des binaires, etc. changent. Même si l'assembleur sera celui du bon processeur, l'environnement d'exécution change et rend la tâche impossible sans un compilateur spécifique.

Il faut je pense utiliser un gcc compilé spécialement pour (un peu comme les arm-gcc-* ou mingw*) voire des options seulement à lui lancer.

Ce n'est pas impossible, après est-ce simple, je ne sais pas.

Il y a je pense une incompréhension sur le sujet. Je vais tenter de le résoudre.
Le Projet Fedora se différencie des autres distributions en effet par son aspect upstream, nouvelles fonctionnalités et autres. C'est très clairement mis en avant, mais il faut aller au delà des deux premières lignes :
https://fedoraproject.org/fr/about-fedora
Et https://fedoraproject.org/fr/ section "Pourquoi Fedora est si apprécié".
Dans ces deux endroits, tu verras les 4 piliers de Fedora dont l'aspect bleeding edge mais en aucun cas la stabilité.

Donc non, Fedora ne renie pas sa base d'utilisateurs, au contraire, elle officialise énormément le fait qu'elle est destinée aux amateurs de nouveautés.

Donc pourquoi cette ligne avec stable et utilisation quotidienne ? Déjà c'est du marketing, et comme ce n'est dit qu'une fois, on voit que ce n'est pas une valeur forte. Puis il y a du vrai. Fedora a énormément progressé sur la stabilité avec une équipe de QA et des procédures aboutis. Je ne dirais pas que c'est sans problèmes, mais très honnêtement je ne trouve pas la Fedora moins stable qu'une Ubuntu, Mageia ou une OpenSuse. Ce n'est pas du niveau de Debian, et alors ? Fedora a des exigences de qualité qui la rendent globalement stable. Puis je pense qu'il y a suffisamment de gens qui l'utilisent au quotidien sans alternative pour prouver qu'elle est faite dans ce cadre d'utilisation.

En plus avec Fedora.next, il va avoir un travail pour faire des images clouds et serveurs spécifiques à chaque version. Mais ça ça sera explicité plus en détail dans une dépêche qui arrivera bientôt. :)

Bref, ne pas mélanger des principes forts d'une distribution et des "conséquences" de certains mécanismes. Je pense que la confusion vient de là.

Il gère ça le systemd ?

Je ne sais pas, mais comme il peut lire les scripts SysV, si tu arrives à le faire avec alors il pourra.

Quel est l'intérêt de systemd alors ?

La compatibilité ascendante ça te dit quelque chose ? Ça aide à faire la transition que ce soit pour les distributions ou les admins systèmes.

À quoi ça sert que LibreOffice sache lire des fichiers Words de 97 ? À quoi ça sert que Firefox sache ire des pages HTML 1 ? À quoi ça sert de lire les partitions NTFS quand on a ReiserFS ou BTRFS ? Etc.

C'est vrai que le concept du runlevel est ardu a saisir : la page Wikipedia d'ailleurs est d'une longueur monstrueuse.

Si tu avais lu la page, tu aurais vu qu'un numéro d'exécution chez l'un peut avoir une autre signification chez un autre. En gros, il faut adapter à chaque distribution le numéro selon que l'on souhaite. Il faut trouver cette information, la vérifier et tester. Ici comme c'est nommé, tu sais que quelque soit la distribution ça s'exécutera au niveau d'exécution que tu voulais. C'est plus simple non ?

arathorn:~# man systemctl
No manual entry for systemctl

Si tu n'as pas systemd, c'est normal que tu n'as pas d'entrée de manuel pour cet utilitaire.
Tu n'essayerais pas un peu de te foutre de notre gueule ?

mmh au hasard et suivant les cas : dans /etc/rc.d ou dans /etc/init.d. Le truc bon c'est que c'est valable pour quasiment tous les unix, pas juste linux.

Rien que pour le dossier de base, comme tu le montres, le nom du dossier peut changer.
Quelle portabilité incroyable !

C'est ce que je dis : ça répond a des problématiques plus orienté mainteneurs qu'utilisateur final.

Le mainteneur est confronté aux problèmes des sys admin. L'utilisateur final de systemd ce sont les mainteneurs et les sys admin, pas les autres qui effectivement ne verront pas une différence directe (mais indirectement, s'il y a moins de temps à passer pour gérer les services, la qualité globale du système augmente et cela permettrait de se concentrer sur d'autres tâches).

un pas de plus vers de la complexité non nécessaire dans le cas général.

Pourtant, les gens n'arrêtent pas de lister des cas où SysV a montré ses limites. Pour moi c'est la preuve que c'est nécessaire, pas pour tout le monde certes, et alors ? Gnome est une complexité non nécessaire pour certaines actions faisable plus efficacement en console, cela n'enlève pas son intérêt global d'exister.

En remplacement de System V, alors il y a peut-être un progrès, mais par rapport a un init sauce BSD, c'est juste de la complexité ajoutée pour couvrir des cas peu probables, particulièrement sur des serveurs basiques.

À lire les anti-systemd qui veulent un retour à SysV et non vers une autre solution, on voit qu'il y a un soucis de discours.
C'est de la résistance au changement.

Après c'est sur que pour un éditeur de distro, il y a clairement un gain, mais pour l'utilisateur final…

Qui est l'utilisateur final ? L'admin système et le créateur de la distribution ont un gain évident dans l'affaire. L'utilisateur moyen non, mais est-ce qu'on râle sur des nouveautés de gcc que l'utilisateur moyen ne verra pas non plus ?

Le changement c'est bien quand c'est nécessaire.

Il faudra combien de messages avec la liste des gains apportés pour que tu voies que c'est nécessaire ?
Et combien de distributions vont devoir migrer pour te montrer qu'ils le font car ils savent qu'ils ont à y gagner ?

Là, le changement va être induit par une nouvelle techno qui n'est pas développée pour répondre à mon besoin mais a celui de tiers (les mainteneurs).

Tout le monde s'en fout de ton besoin ou du mien. Dans le LL, le besoin qui est représenté est celui qui code. C'est comme ça. Ils dictent les changements car ils travaillent avant tout pour eux (ils veulent forcément que l'outil qu'ils développent répondent à leur besoin, à moins d'être maso et de programmer un utilitaire dont on ne souhaite pas l'utiliser).

Et si ton besoin n'a pas évolué, celui des autres oui, et systemd s'adapte à ce changement. D'autant qu'en étant compatible avec SysV, il peut satisfaire les "besoins" des "anciens".
Encore faut-il démontrer le besoin réel auquel répond SysV et pas systemd.

le problème est dans le fait qu'on bascule un truc expérimental dans un outil de production.

Ce n'est pas expérimental. Systemd est en développement très actif mais j'ai connu très peu de problèmes avec. J'en ai connu avec SysV aussi…
Ce n'est pas comme avec PA où en effet au début les problèmes étaient plus la norme que le bon fonctionnement. Systemd fonctionne très bien. Puis après on ne peut pas accuser le développeur d'un programme d'avoir son outil dans des distributions par défaut. Ce sont elles qui font le choix et en sont responsables.

En termes de technos oui c'est plus ou moins récent, mais les concepts sous jascents sont loin de l'être.

Oui, enfin osef. Une technologie qui n'existait que dans un garage ou de manière inaboutie ce n'est pas très intéressant. Cela reste des nouveautés qui impliquent de nouveaux usages et de nouveaux besoins.

Typiquement udev (et HAL) permettent de gérer l'histoire des périphériques à chaud qui existaient depuis un bail mais qui sont populaires depuis seulement une décennie pour l'ordinateur moyen. Et étant donné la fréquence d'utilisation de ces périphériques aujourd'hui, heureusement qu'il y a des mécanismes similaires.

Le concept est certes vieux, mais comme il était discret, le cas d'utilisation n'était pas gérée ou de manière trop légère.

Et avec systemd, pof, ça marche en un clic ?

Non, mais certains problèmes qu'il y avait avec SysV n'existe plus, ou sont plus simples à gérer.
C'est là l'intérêt…

Etape obligatoire quelque soit ton gestionnaire de service non ?

Je ne dis pas le contraire. Mais certains semblent oublier que SysV nécessite un apprentissage.
Et la courbe d'apprentissage de systemd semble intéressante vis à vis de SysV.

Donc lire la doc du service est plus long que lire la doc du service + la doc de systemd. CQFD

Où j'ai dis ça ? J'ai l'impression que tu négliges le temps de rédiger un démon sous SysV de manière propre. Car oui, gérer cela de manière propre est assez long et périlleux par rapport à une unité de systemd qui t'abstrait de l'implémentation de concepts délicats à gérer comme les dépendances de processus ou du chemin d'accès à certains fichiers.

A vous croire ça lave tellement plus blanc que toutes les distros seront identiques en termes de conf et que les migrations se feront en un clic. Rien que quand tu vois le support de la LSB par les distro, tu sais que ça relève du vœu pieux mais que c'est irréalisable justement parce que s'il existe différentes distros, c'est parce qu'il existes différents contextes.

C'est à se demander si tu as lu la doc de systemd et si tu t'en es réellement servi un jour.
Les unités de systemd peuvent différer entre distributions pour un service donné. Systemd ne change rien à ce fait et chaque distribution peut avoir sa petite touche personnelle.

Ce qui change c'est que si Debian fait une unité adaptée pour httpd, un utilisateur de Fedora intéressé pourra copier/coller ce fichier et l'utiliser et ça fonctionnera. C'est ça qui est intéressant.
Essaye de le faire avec SysV, tu vas prendre un certains temps à adapter le script…

Satisfaire les besoins et les dépendances d'un service restera à ta charge.

Par chance, si tu connais les dépendances les gérer est bien plus simple avec systemd qu'avec ton script SysV. Et lui gérera ça pour toi partiellement, tu n'as qu'à lui fournir le nom et non le mécanisme entier.

Toutes les dépendances ne peuvent pas s'exprimer dans un unit systemd,

Référence nécessaire.
Et si jamais ça arrive, systemd n’enlève pas la possibilité d'utiliser des scripts SysV.

Note que l'inverse est sans doute plus vrai encore, de nombreux cas pourtant "simples" ne sont pas gérables proprement avec SysV.

Et si tu ne lit pas la documentation sur tout ton système et que tu ne regarde pas ce que fait chaque programme, tu peux toujours t'accrocher.

systemd ne change rien sur ce fait (et SysV non plus), mais permet de s'affranchir de l'apprentissage de certaines choses avec un minimum d'apprentissage car on peut gérer des services sans être sysadmin d'un serveur critique tu sais…

je te garanti qu'elles n'utiliseront pas les mêmes units.

Possible, et en soit ça n'aura pas une grande importance.
Un fichier init donne les paramètres pour lancer un service dans une syntaxe précise et en couvrant un maximum de configurations possibles. Si une distribution veut changer un fichier unit pour une raison X ou Y, ce n'est pas grave car comme la syntaxe et les possibilités sont uniformisées, un fichier unit d'une distribution fonctionnera forcément dans une autre.

Avec SysV ce n'était pas le cas, car chaque service vérifie des trucs dans son coin de manière non harmonisée, les noms de fichiers ou les chemins d'accès diffèrent entre distributions, etc. Ce qui fait que le copier/coller n'est pas possible.

Systemd corrige cela et c'est déjà un grand pas en avant.