Diaoul

Ce type de SPK n'aura pas de public assez large pour

Les contributeurs sont les bienvenus

Exactement, un RAID5 devrait te protéger contre une panne matérielle d'un disque. Ce qui m'étonne c'est que ce ne soit pas récupérable par Syno car même si c'est un cable SATA défaillant il devrait n'y avoir qu'un disque d'affecter non ? A moins qu'avec le RAID 5 ça ne se soit propagé sur les autres disques... Edit: En relisant j'ai l'impression que ta manipulation a écrasé l'array existant ?

Padbol.

T'es sûr que c'est bien sur /volume1 ? Supprime le partage "downloads" et recréé le. Si tu avais le SPK de superzebulon, le partage et les dossier ont été créé par le SPK et donc il doit y avoir des problèmes de permissions dessus.

Le répertoire "download" existe-t-il bien ? Quel modèle de Syno as-tu ?

Je crois que tu m'as mal compris quand je dis qu'IPKG c'est du bricolage, je te parle de tout ce qui est en amont de ton ipkg install trucmuche : la cross compilation faite via optware, les versions utilisées, les patchs appliqués bref, tout le fonctionnement d'Optware en général. Reste qu'IPKG est la solution la plus simple pour utiliser rapidement un programme.

J'ai du lire ici même quelques avis positifs sur la Popbox v8 de PopcornHour.

Je ne dénigre rien du tout, IPKG c'est très bien pour découvrir des programmes ou se bricoler un petit truc ou tout simplement éviter de cross compiler. Les paquets ne sont pas à jour, il y a des patchs hasardeux dans Optware, comparé à OpenEmbedded c'est très opaque et les toolchains utilisées sont pas les officielles fournies par Synology. Perso je n'expose pas de programme installé via IPKG sur mon Syno sur internet, souvent les versions proposées par IPKG sont vieilles. Quant aux interractions entre IPKG et le firmware natif il y en a bien puisque tu changes le PATH. Ton Syno peut très bien se retrouver à appeller des commandes via IPKG au lieu des commandes natives. Je me rappelle de quelqu'un qui avait du flasher son Syno à cause de l'installation d'un paquet IPKG (busybox de mémoire). Tu perds IPKG à la suite d'un flash de firmware. Les SPKs sont pensés par Synology pour éviter ce genre de désagréments et laisse la main à l'utilisateur d'installer / désinstaller / mettre à jour un paquet via DSM. Ils résistent aussi au flash de firmware et peuvent même conserver les fichiers de conf après désinstallation sur accord de l'utilisateur (via un formulaire lors de la désinstallation). Un SPK bien ficellé c'est 0 dépendance vers les librairies du Syno et 0 interraction avec le système natif. Perl via IPKG c'est très bien aussi et tu as presque un environnement séparé, les points faibles étant les bugs éventuel, les versions dépassées et le manque de paquets. Perl en SPK tu peux faire ce que tu veux. La compilation des modules se ferait en amont via cross compilation et non en natif sur le Syno ce qui évite les désagréments de librairies non disponnible ou pas à la bonne version. Reste aussi Perl via un chroot Debian. Tous les Synos sont maintenant ARMEL ou x86. Les vieux sont en PPC et très vieux (x07) en ARMEB. Le chroot debian serait donc possible sur tous les Synos. Là tu te reposes sur la communauté Debian et profite de toutes les mises à jour possible et imaginables. Par contre comme c'est jail c'est pas super pratique à utiliser en dehors de l'environnement chrooté. Tu peux même faire de la compilation de modules perl en natif.

J'ai commencé ma phrase par "pour faire propre". Tu peux toujours bricoler hein.

Pour faire propre il faudrait cross compiler un nouveau Perl et faire un SPK. J'avais essayé à l'époque mais c'est une sacré galère. Il faut regarder comment faire OpenEmbedded...

La partie serveur de RStudio http://rstudio.org/download/server

Il y a un espace en trop dans ta commande de toute façon.

S'il ne faut qu'un repo git pour faire tourner SparkleShare ce sera pas très compliqué de faire un SPK. Par contre, là ou ça va être chiant c'est qu'il va falloir aussi faire tourner un nouveau SSHD pour gérer les connexions entrantes et jail le tout pour pas avoir de problème de sécurité. Enfin bon, c'est jamais que de la configuration

J'ai essayé mais les allemands sont partis sur leurs trucs de "Package Community Hub" et il n'y avait pas vraiment de développeur de SPK là bas, juste des développeurs web pour faire une interface jolie pour que les gens y déposent leurs SPKs. Maintenant c'est bud77 qui gère ça

A moins d'avoir de nouveau développeurs ces paquets ne verront pas le jour avant au moins 6 mois. Perso j'ai pas le temps.

/opt/bin/ipkg remove sabnzbd[/CODE]

Et "subversion" ?

Ca sert à ce que umurmur se lance avec les persmissions de l'utilisateur système nobody. Ainsi, s'il y a une faille de sécurité dans umurmur et qu'un hacker l'exploite, il n'aura pas les permissions root sur ton Syno et ça limitera les dégats possibles. On appelle ça le privilege dropping.

Tu devrais laisser "nobody" comme username, ainsi que pour le "groupname". C'est une mesure de sécurité.

Tu te connectes au serveur et tu mets le password en jeton d'accès.

La doc ne mentionne pas cette contrainte de l'europe de l'Est : http://pypi.python.org/pypi/chardet Peut être que tu devrais leur indiquer tes cas d'exemple afin qu'ils améliorent chardet ?

TS3 ça ne verra jamais le jour. Sauf peut être sur des Syno x86.

J'en sais rien moi je package j'utilise pas tout.

Bha si tu utilises chardet dans ton script, je pourrai l'inclure dans la prochaine versions de SABnzbd.