El Capitan

colas_colas_ Membre
février 2016 modifié dans Coin canapé & détente #1

Je viens d'installer El Capitan sur mon macbook pro (non retina), mi-2012.


 


Premières réactions (à  vif):


 


+ Oui, c'est plus réactif !


 


- Notes n'est pas stable (déjà  2 crashes successifs)


- Xcode m'a demandé d'installer des modules supplémentaires (j'espère qu'il ne va pas le refaire)


- Les permissions d'accès à  /usr/local (ou je ne sais quoi) ont changé, on doit bidouiller pour faire tourner LaTeX


- Le TRIM n'est pas supporté nativement (je croyais que si, ma mémoire m'a trompé), même si en vrai je ne connais pas les enjeux du TRIM --- sauf sur les String, évidemment ;-)


- J'ai l'impression que l'extinction de l'ordi est plus lente


 


Donc, un passage 10.10 -> 10.11 qui n'est pas totalement transparent, mais qui apporte plus de réactivité.


Réponses

  • TRIM : géré par OSX (depuis 10.4) via la commande



    sudo trimforce enable
  • DrakenDraken Membre
    février 2016 modifié #3

    Et pourquoi pas El Capitan plutôt que Yosemite ?


  • En fait je me suis trompé, c'est bien El Capitan que je viens d'installer. J'étais déjà  sous Yosemite.


  • AliGatorAliGator Membre, Modérateur

    - Les permissions d'accès à  /usr/local (ou je ne sais quoi) ont changé, on doit bidouiller pour faire tourner LaTeX

    Ca je mettrais plutôt ça dans les +, c'est une feature du SIP (System Integrity Protection) qui sécurise pas mal ton ordi, entre autres en évitant de donner des droits trop importants à  l'utilisateur root même sis un pirate arrive à  faire une escalade de privilèges (une des attaques les plus classiques sur les systèmes *nix) par exemple en utilisant un installeur malveillant.

    Par contre, justement /usr/local est un des répertoires qui n'est justement pas touché et laissé autorisé en écriture par SIP, car il est fait pour ça. C'est les répertoires /System, /bin, /sbin et /usr (sauf justement /usr/local donc) qui sont protégés pour restreindre les risques de hacking de ton système.

    Alors certes, tous les programmes qui s'installaient avant dans /bin ou dans /usr " alors qu'ils n'auraient pas dû " doivent être remis d'équerre. Mais déjà  ils auraient dû être de meilleurs citoyens dès le départ, et en plus ça permet de remettre les choses au propre et de mieux protéger ton système.

    Donc oui certes c'est un point contraignant si tu as installé des outils tiers qui s'installaient (à  tort) dans ces répertoires, mais ça reste un point positif du système pour la sécurité supplémentaire forte que ça apporte.
  • colas_colas_ Membre
    février 2016 modifié #6

    Merci pour ces précisions.


    Je n'ai jamais pris la peine de comprendre ces dossiers /usr/local/bin/sbin, etc.


     


    En fait, LaTeX créait (je crois) un raccourci (je pense) de ces programmes dans un dossier /usr/texbin.


    Ce dossier est passé à  la trappe il me semble... Donc, il semblerait que SIP nettoie le dossier /usr en enlevant ce qui y était avant (en trop).


    Du coup, le chemin pour appeler latex était avant 



    /usr/texbin/latex

     et est maintenant



     /usr/local/texlive/2013/bin/universal-darwin/latex

    du moins sous ma distrib.... C'est beaucoup moins universel qu'avant (selon la distrib, ce chemin va changer)


  • AliGatorAliGator Membre, Modérateur
    /usr/texbin ?!? Ah ouais, y'a rien de moins standard quand même comme emplacement, qu'est ce qui leur a pris de mettre LaTeX dans un tel dossier ?
    Normalement tu n'es pas sensé créer de dossier à  la racine de /usr. C'est un peu comme si tu créais toi-même un dossier dans /Users sur OSX par exemple...

    Remarque que "/usr/local/texlive/2013/bin/universal-darwin/latex" semble tout aussi étrange. C'est mieux car c'est dans "/usr/local", mais créer un dossier dédié et surtout l'organiser selon une date et une architecture (universal-darwin) sans faire de lien symbolique générique pour autant semble un peu custom aussi

    Pour moi l'emplacement logique aurait dû être "/usr/local/bin/latex", comme pour tous les binaires custom installés dans n'importe quelle distribution Unix, OSX y compris. C'est dans /usr/local/bin normalement que tu installes les binaires et commandes terminal de tierce partie c'est à  ça que sert ce répertoire donc je vois pas trop pourquoi LaTeX préfèrerai en faire qu'à  sa tête et ne pas suivre les conventions Unix...
  • CéroceCéroce Membre, Modérateur

    je vois pas trop pourquoi LaTeX préfèrerai en faire qu'à  sa tête et ne pas suivre les conventions Unix...

    LaTeX est un gros bordel. Il faudrait reprendre le code mais c'est tellement difficile, que personne ne veut s'y coller.
  • C'est vrai que c'est très vieillissant LaTeX...


    Un outil pourtant encore très utilisé et considéré comme un super programme (codé par Knuth, le dieu de l'informatique), réputé sans bug, etc.

  • Et certains éditeurs exigent encore du texte en ΤΕΧ  pour les publications scientifiques, notamment s'il y a beaucoup de formules mathématiques !!


  • AliGatorAliGator Membre, Modérateur

    LaTeX est un gros bordel. Il faudrait reprendre le code mais c'est tellement difficile, que personne ne veut s'y coller.

    Il y a certainement de ça effectivement.

    Mais si ce chemin bizarre avait été là  dès le début, j'aurai pu entendre l'argument genre "il est difficile à  changer".
    Sauf que là  ils viennent justement de le changer pour ne plus avoir de pb avec la sécurité de SIP...
    Du coup, quitte à  ce qu'ils fassent une correction pour qu'il s'installe ailleurs que dans /usr/textbin, ils auraient pu juste le déplacer dans /usr/local/bin plutôt que dans ce répertoire encore plus chelou, non ?
  • colas_colas_ Membre
    mars 2016 modifié #12
    Non tu te trompes Ali, ce chemin compliqué à  toujours été comme ça. L.autre chemin simple (/usr/texbin) contenait des liens symboliques je crois.


    Le problème c'est que les éditeurs latex vont chercher le programme dans ce dossier. Ce n'est pas très compliqué à  régler car généralement on peut setter à  la main le chemin du programme.
  • AliGatorAliGator Membre, Modérateur
    mars 2016 modifié #13
    Dans ce cas OK... mais à  condition qu'ils créent un lien symbolique dans /usr/local/bin vers le vrai exécutable alors, comme font les autres binaires de tierce partie. C'est en tout cas la convention.

    Comme ça les éditeurs LaTeX peuvent aller pointer sur le programme /usr/local/bin/latex sans se poser de questions de où est caché l'original ni sur quelle archi ils sont pour aller chercher dans le bon sous-dossier ou autre. C'est à  ça que ça sert aussi

    Et en plus /usr/local/bin est en général dans le $PATH alors que un truc aussi spécifique que /usr/local/texlive/2013/bin/universal-darwin/, j'en doute fort ^^
  • tabliertablier Membre
    mars 2016 modifié #14

    J'ai un problème avec toutes les versions d'OS x depuis la 8.5. Et avec El capitan ça n'a pas changé !!


    Pour recharger ma carte de tram, j'utilise un lecteur de carte Neowave fourni par la TAG.


    Pour faire marcher l'aplet de rechargement de la carte il faut modifier le fichier "info" de la libccid.


    Ce fichier est situé à : /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist


    Je peux éditer ce fichier, mais jamais le réécrire à  sa place, même en root !!


    Donc je recharge ma carte sous un OS x 10.6 sous lequel la modification a marché.


    Y a t-il un moyen de modifier ce fichier sous EL Capitan ?


     


     


  • AliGatorAliGator Membre, Modérateur
    Oui, en passant temporairement en mode rootless après un boot en superuser. Mais surtout, surtout, une fois que tu as fait la modification, réactive le SIP.

    Manipulation à  ne faire que si tu sais vraiment, vraiment que la modification que tu fais sur ton fichier système est sans danger, et que tu remets la protection juste après. Sinon c'est comme laisser ton coffre fort ouvert.

    (C'est pour cela que je ne détaille pas la procédure ici, pour ne pas inciter les gens à  la suivre sans réfléchir, mais elle se trouve facilement sur Google en cherchant comment désactiver SIP " bien que ce soit fortement déconseillé à  moins de le remettre immédiatement après)
  • tabliertablier Membre
    mars 2016 modifié #16

    Je dois ajouter l'Id du dispositif que j'ai entre les mains ainsi que l'Id et le nom du constructeur dans les trois listes contenues par Info.plist. 


     


    Je vais aller voir sous Google comme tu le conseilles et si j'ai besoin de précision supplémentaire je te contacterai en MP.


    Merci.


Connectez-vous ou Inscrivez-vous pour répondre.