Un serveur 64Bits, tant qu'on essaye pas de le faire tourner sur un Pi, on s'en sort pas trop mal. Je le fais tourner sur un A4-5300, 4Go avec un load-average de 0.01 0.07 0.12. Pour une machine qui m'a couté moins de 150 euros, c'est pas mal je trouve :)
Pour Yunohost, c'est un malheureux oubli de ma part. Merci de l'avoir signalé :)
Je n'en ai pas parlé parce que les solutions de stockage et d'accès aux fichiers existent et sont abouties, et qu'un article sur l'auto-hébergement qui les citerait serait probablement redondant :)
Je pensais que memberOf était la façon "standard" de chercher l'appartenance d'un utilisateur à un groupe. En tout cas, toutes les recherches que j'ai fais sur le sujet aboutissent à ça.
Je dois avoir un problème dans mon paramétrage ou ma façon de gérer les groupes avec smbldap…
Pour XMPP, j'ai opté pour OpenFire. J'utilise Zimbra pour le serveur mail, freeRADIUS pour le serveur RADIUS, et j'utilise mod-auth-ldap sur Apache pour certains sites. Et pour être exhaustif, à l'heure actuelle pour faire fonctionner tout ça, j'utilise un champ seeAlso sur chaque utilisateur qui pointe vers des "groupes" qui ne sont pas dans ou=Groups mais dans ou=Roles, qui sont de simple rôles organisationnels. C'est moche, je sais, mais c'était en attendant de réussir à répondre à ma question :) Et le but ultime de tout ça, c'est d'avoir une interface web qui permet à un user de se connecter pour modifier ses infos personnelles (principalement le mot de passe - avec synchro des mdp samba NT et LM). Voilà qui complète la description de mon système actuel et de ce que j'aimerais en faire.
Ok. Donc en fait, on exprime une opinion, et on reçoit des commentaires ironiques, désobligeants qui ne servent à rien, c'est donc comme ça que ça marche. Soit.
Ce n'étaient que des exemples des ajouts récents à PHP qui m'ont rendu sceptique. Ce n'est pas ces deux exemples le problème que je soulève dans mon post. Donc j'aurai tendance à dire que tu t'es contenté de venir pourrir les coms de ce journal sans même prendre la peine de le lire.
Au moins, ce post de Laurent J, en désaccord avec moi, prend la peine de me dire en quoi il estime que composer c'est bien, ce qui contribue positivement au débat. Toi, tu te contente de faire un :facepalm:.
J'attendais un autre niveau de la part des commentateurs en fait. J'aurai mieux fais de ne m'attendre à rien du tout.
Où il est écrit que l'héritage est une bonne manière de réutiliser du code ? Et surtout, la seule.
Ben, je te pose la question. Je n'ai rien dis de tel. Je dis juste que selon la doc de PHP les traits permettent d'hériter des méthodes de plusieurs classes dans la mesure où PHP ne supporte pas l'héritage multiple.
C'est pas parce que c'est la seule méthode que tu connaisse que c'est la bonne manière de faire, et encore moins que c'est un palliatif
Au lieu d'être aggressif, désobligeant et insinuer que je ne sais pas de quoi je parle, il serait plus constructif que tu étaye tes propos par des exemples de réutilisation de code hors héritage tu ne crois pas ?
Tout à fait, et d'ailleurs Redbean s'appuie sur PDO en simplifiant certaines opérations et surtout en modifiant à la volée la structure de la base de données.
Il semble que mes connaissances en la matière soient moins étendues que les tiennes (je dis sans sans la moindre ironie). Aurais-tu l'amabilité de m'indiquer un projet libre industrialisé, écrit en PHP, et à destination du "grand public" (donc pas destiné à un usage professionnel) ?
Je ne sous entends pas que "le libre ne peut pas être professionel", je sous entends qu'une application libre non professionnelle ne devrait pas être industrialisée. Tu me suis ?
si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va
Oui, mais c'est encore plus simple et rapide d'extraire une archive. Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge…
Tu parles d'un utilisateur, ou d'un développeur ?
Peu importe: de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)
En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…
Possible, mais je n'ai jamais pu trouver une autre explication.
Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres
La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.
Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?
Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???
Non, ce n'est pas ce que j'ai dis. Pardon, j'abuse de raccourcis, je vais faire plus attention à comment je présente les choses.
Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, on ne lui donne pas une identité. Mais on peut très bien utiliser bootstrap comme une base, et faire des changement plus importants que lui attribuer un nouveau swatch… J'aime bien parfois tomber sur un site dont l'esthétique me plait, me demander ce qui est utilisé pour le frontend, et découvrir que la base est bootstrap.
On n'est pas tous web-designer, d'où l'intérêt du Libre: que des web-designers contribuent à l'identité de l'application.
En entreprise le problème est différent: on s'en tape de l'identité visuelle d'une application à usage interne. Donc là, on industrialise en mettant du bootstrap, possiblement avec quelques corrections mineures, mais le but étant surtout que ça marche et vite. Cette prérogative de "productivité" comme dit ne devrait pas exister dans le cadre d'un projet individuel, non professionnel.
Encore une fois, je précise que j'utilise ces outils pour mes projets privés, des projets qui ne seront jamais diffusés. Je ne suis pas contre leur usage, il faut être clair là dessus. Je suis contre leur usage pour tout et n'importe quoi et surtout lorsque le travail résultant est rendu public. Ce n'est pas un gage de sérieux selon moi.
J'hallucine là. Tu trolles là en fait hein ? c'est ça ?
Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).
Désolé si tu as interprété mes propos comme étant du troll.
Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis)
C'est bien ça le problème. Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main. C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.
[^] # Re: Zimbra
Posté par Richard Dern . En réponse au journal Auto-hébergement: pas toujours évident.... Évalué à 2.
Un serveur 64Bits, tant qu'on essaye pas de le faire tourner sur un Pi, on s'en sort pas trop mal. Je le fais tourner sur un A4-5300, 4Go avec un load-average de 0.01 0.07 0.12. Pour une machine qui m'a couté moins de 150 euros, c'est pas mal je trouve :)
Pour Yunohost, c'est un malheureux oubli de ma part. Merci de l'avoir signalé :)
[^] # Re: Rainloop ?
Posté par Richard Dern . En réponse au journal Auto-hébergement: pas toujours évident.... Évalué à 2.
En tout cas ça mérite d'être essayé :)
[^] # Re: je suis épaté
Posté par Richard Dern . En réponse au journal Auto-hébergement: pas toujours évident.... Évalué à 3.
Je n'en ai pas parlé parce que les solutions de stockage et d'accès aux fichiers existent et sont abouties, et qu'un article sur l'auto-hébergement qui les citerait serait probablement redondant :)
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Apparemment, memberOf n'est pas si "standard" que ça.
Je crois que je vais continuer à utiliser seeAlso…
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Je pense que mon problème de memberOf vient de là: je n'ai pas l'objectClass samAccount
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Oui justement, j'ai des Windows derrière.
Mais ça, l'authentification de clients Windows avec Samba et un backend LDAP, je sais faire maintenant.
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Après, peut être qu'utiliser samba pour peupler mon LDAP des enregistrements initiaux n'est peut être pas la bonne façon de faire.
Je peux tout à fait tout reprendre depuis le début et virer ma base LDAP actuelle.
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
En maquette perpétuelle :) C'est mon réseau perso.
En effet: c'est exactement ce que je fais avec l'attribut seeAlso et c'est effectivement la merde à gérer, d'où mon besoin de le faire correctement :)
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Je pensais que memberOf était la façon "standard" de chercher l'appartenance d'un utilisateur à un groupe. En tout cas, toutes les recherches que j'ai fais sur le sujet aboutissent à ça.
Je dois avoir un problème dans mon paramétrage ou ma façon de gérer les groupes avec smbldap…
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Oui mais seeAlso ce n'est pas la bonne façon de faire. Je devrai pouvoir utiliser l'attribut memberOf, mais cet attribut n'existe pas…
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Merci pour le lien vers SSP, je vais jeter un oeil, ça me semble bien pour ce que je veux faire :)
Pour la recherche:
Pour info, un slapcat sur mon user donne ça:
Et un slapcat sur le groupe:
On voit dans le groupe que l'user est présent, mais pas l'inverse (pas la seule étrangeté d'ailleurs…)
[^] # Re: syntax
Posté par Richard Dern . En réponse au message OpenLDAP, Utilisateurs et Groupes. Évalué à 1.
Pour XMPP, j'ai opté pour OpenFire. J'utilise Zimbra pour le serveur mail, freeRADIUS pour le serveur RADIUS, et j'utilise mod-auth-ldap sur Apache pour certains sites. Et pour être exhaustif, à l'heure actuelle pour faire fonctionner tout ça, j'utilise un champ seeAlso sur chaque utilisateur qui pointe vers des "groupes" qui ne sont pas dans ou=Groups mais dans ou=Roles, qui sont de simple rôles organisationnels. C'est moche, je sais, mais c'était en attendant de réussir à répondre à ma question :) Et le but ultime de tout ça, c'est d'avoir une interface web qui permet à un user de se connecter pour modifier ses infos personnelles (principalement le mot de passe - avec synchro des mdp samba NT et LM). Voilà qui complète la description de mon système actuel et de ce que j'aimerais en faire.
Pour ldapsearch, j'ai fais:
# DDG
Posté par Richard Dern . En réponse au journal [ coup de gueule ] C'est moi ou google devient de plus en plus pénible ?. Évalué à 10.
100% d'accord avec ton journal.
Google n'est plus fait pour les geeks mais pour les hipsters.
Ça fait un moment que je n'ai plus ce genre de problèmes, merci DuckDuckGo.
[^] # Re: Laravel + Twig semble pas mal
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Cf page d'accueil
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -8.
Commentaire encore une fois très constructif, surtout de la part de quelqu'un dont la signature est:
Ceci explique cela.
Juste une question: j'ai insulté vos mères pour justifier un tel comportement de votre part ?
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -4.
Ok. Donc en fait, on exprime une opinion, et on reçoit des commentaires ironiques, désobligeants qui ne servent à rien, c'est donc comme ça que ça marche. Soit.
Ce n'étaient que des exemples des ajouts récents à PHP qui m'ont rendu sceptique. Ce n'est pas ces deux exemples le problème que je soulève dans mon post. Donc j'aurai tendance à dire que tu t'es contenté de venir pourrir les coms de ce journal sans même prendre la peine de le lire.
Au moins, ce post de Laurent J, en désaccord avec moi, prend la peine de me dire en quoi il estime que composer c'est bien, ce qui contribue positivement au débat. Toi, tu te contente de faire un :facepalm:.
J'attendais un autre niveau de la part des commentateurs en fait. J'aurai mieux fais de ne m'attendre à rien du tout.
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Mettre "copier-coller" dans la liste des techniques de réutilisation du code valides, faut oser…
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Ben, je te pose la question. Je n'ai rien dis de tel. Je dis juste que selon la doc de PHP les traits permettent d'hériter des méthodes de plusieurs classes dans la mesure où PHP ne supporte pas l'héritage multiple.
Au lieu d'être aggressif, désobligeant et insinuer que je ne sais pas de quoi je parle, il serait plus constructif que tu étaye tes propos par des exemples de réutilisation de code hors héritage tu ne crois pas ?
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Et contribuerait à la diversité chère aux libristes :)
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Je précise quand même que certains points soulevés par PHPSadness sont franchement tirés par les cheveux:
Je suis d'accord sur les inconsistances des noms de fonctions par exemple, mais le reste il faut avouer que c'est du bashing :)
[^] # Re: Laravel + Twig semble pas mal
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 1.
Ah et pour info Smarty n'est pas du tout dépasé, il est mis à jour régulièrement au contraire (c'est plus flagrant sur leur dépôt github)
[^] # Re: Python c'est mieux maintenant
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -2.
Tout à fait, et d'ailleurs Redbean s'appuie sur PDO en simplifiant certaines opérations et surtout en modifiant à la volée la structure de la base de données.
Si ça c'est pas fait pour aider les développeurs…
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -5.
J'aimerai quand même une réponse à ma première question, ça m'intéresse vraiment.
Et je parle de libre parce que pour du privateur on s'en tape de toutes ces considérations.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -5.
Il semble que mes connaissances en la matière soient moins étendues que les tiennes (je dis sans sans la moindre ironie). Aurais-tu l'amabilité de m'indiquer un projet libre industrialisé, écrit en PHP, et à destination du "grand public" (donc pas destiné à un usage professionnel) ?
Je ne sous entends pas que "le libre ne peut pas être professionel", je sous entends qu'une application libre non professionnelle ne devrait pas être industrialisée. Tu me suis ?
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -3.
Oui, mais c'est encore plus simple et rapide d'extraire une archive. Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge…
Peu importe: de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)
Possible, mais je n'ai jamais pu trouver une autre explication.
La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.
Non, ce n'est pas ce que j'ai dis. Pardon, j'abuse de raccourcis, je vais faire plus attention à comment je présente les choses.
Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, on ne lui donne pas une identité. Mais on peut très bien utiliser bootstrap comme une base, et faire des changement plus importants que lui attribuer un nouveau swatch… J'aime bien parfois tomber sur un site dont l'esthétique me plait, me demander ce qui est utilisé pour le frontend, et découvrir que la base est bootstrap.
On n'est pas tous web-designer, d'où l'intérêt du Libre: que des web-designers contribuent à l'identité de l'application.
En entreprise le problème est différent: on s'en tape de l'identité visuelle d'une application à usage interne. Donc là, on industrialise en mettant du bootstrap, possiblement avec quelques corrections mineures, mais le but étant surtout que ça marche et vite. Cette prérogative de "productivité" comme dit ne devrait pas exister dans le cadre d'un projet individuel, non professionnel.
Encore une fois, je précise que j'utilise ces outils pour mes projets privés, des projets qui ne seront jamais diffusés. Je ne suis pas contre leur usage, il faut être clair là dessus. Je suis contre leur usage pour tout et n'importe quoi et surtout lorsque le travail résultant est rendu public. Ce n'est pas un gage de sérieux selon moi.
Désolé si tu as interprété mes propos comme étant du troll.
C'est bien ça le problème. Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main. C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.