🚲 Tanguy Ortolo a écrit 12240 commentaires

Ah, en fait je crois que j'ai compris, ça doit être du serveur partagé. Chacun a accès aux services communs tels que le courrier électronique, la messagerie instantanée ou l'hébergement Web, ainsi qu'un accès SSH simple utilisateur. Et pour lancer personnellement des outils non prévus, on se les compile et on se les installe en tant qu'utilisateur.

En somme, c'est une proposition de commande groupée d'un serveur dédié. Ça n'a vraiment rien de nouveau, en revanche le faire hors d'un groupe d'amis ou de camarades de promo d'une école, ça a l'air nouveau.

Tu peux faire ce que tu veux. C'est comme un serveur dédié, mais au prix d'un mutualisé.

Je ne comprends pas. C'est du dédié ou du mutualisé ?

Dédié : tu es root, seul aux commandes. Mutualisé : tu peux utiliser les services prévus : Web, courrier électronique, messagerie instantanée ou autres, et seulement ceux-là. Alors ?

Non, pas plus. Si c'est un sous-processus, c'est mort, il ne peut pas agit sur le répertoire courant de son processus père.

Il faudrait donner une preuve que le compte appartient bien à l'émetteur dans ce cas.

Non. Pourquoi vouloir faire une telle vérification ? Si quelqu'un achète quelque chose et que c'est sa mère qui paie, quel est le problème ?

La seule chose importante, c'est de pouvoir déterminer à quelle commande un paiement est associé, et la solution pour cela est généralement de demander au client d'indiquer le numéro de commande dans le motif du virement.

Pour l'émetteur il me semble que c'est gratuit uniquement si c'est dans la même banque.

Non, ça dépend de la banque. Il y a des banques qui ne facturent pas les virements interbancaires, d'autres qui les facturent, ce qui est complètement crétin parce que cela rend les chèques plus intéressants alors qu'ils leurs coûtent plus cher à traiter.

Sinon, dans /opt/bin /opt/lib/ etc... (enfin quand j'ai le courage).

Ça c'est encore une violation de la FHS. Si tu veux classer les binaires, les bibliothèques et tout séparément, tu as /usr/local pour ça. /opt n'est pas un préfixe, c'est un répertoire pour des préfixes distincts.

Un script est bien un automate d'envoi quand bien même il n'enverait un seul message à un seul numero

Un téléphone aussi…

Ben, si le but est de saisir un SMS avec un clavier d'ordinateur, a fortiori j'ai un ordinateur à portée au bout du fil de ce clavier, et mon téléphone toujours sur moi…

Qui parle d'automate, ici ? Tant qu'on n'utilise pas de liste de distribution ou de robot d'envoi, il s'agit de messages composés manuellement… Un système de script est tout aussi artificiel que n'importe quel téléphone GSM, ce n'est pas ça qui est interdit je pense.

Les téléphones disposant d'une interface USB sont à peut près tous capable d'exposer un modem GSM, qui acceptent des commandes AT pour envoyer des SMS. Il existe déjà au moins un outils permettant d'envoyer simplement des SMS en ligne de commange : gsmsendsms, des gsm-utils.

Par exemple, pour Debian : http://packages.debian.org/search?keywords=gsm-utils.

Ça, c'est une violation de la FHS. Si tu as besoin d'un préfixe, tu as le choix entre /, /usr, /usr/local et /opt/logiciel. Mais certainement pas /usr/local/logiciel.

Autre solution, sans attestation, tu lui montres que l'écran en question n'a pas, ou plus, de prise d'antenne…

il te fait une attestation que tu envoie au centre de la redevance

Qu'est-ce que c'est que cette histoire d'attestation, depuis quand c'est nécessaire ça ? Je n'ai pas de téléviseur, on ne m'a jamais demandé de le prouver, je ne paie pas la redevance, je n'ai jamais rien envoyé de tel aux impôts et il est hors de question que je le fasse…

Tiens, d'ailleurs c'est le cas historiquement…

Et ça change pas que ton « si t'as pas le droit de l'utiliser en écriture, alors t'en as pas besoin en lecture » était une bonne grosse connerie.

Mais bordel, on a le choix ! Séparer /bin et /sbin permet aux gens de régler leur $PATH selon leurs besoin.

C'est ce que je dis. C'est la raison pour laquelle les serveurs empaquetés utilisent par défaut des répertoires de données dans /var. À l'administrateur d'organiser /srv et d'y faire pointer ses serveurs.

Ah mais oui il y a le gestionnaire de paquets pour s'occuper de cela... et pour les programmes compilés maison, c'est

… dans /opt/logiciel. Et ça reste très propre.

Plus urgent, il serait temps aussi de déplacer une fois pour toute ces cochonneries de .dossiers présents dans le ~/, dans un ~/.config ou autre.

http://standards.freedesktop.org/basedir-spec/latest/. De rien.

ça veut dire quoi, que les jeux c'est moins important que par exemple un éditeur xml ?

Non, ça veut dire qu'un type au travail n'en a pas besoin, et peut ainsi ne pas s'encombrer d'une autocomplétion sur les jeux, par exemple. Et s'il les veut, eh bien il change son $PATH, il a le droit aussi.

La séparation entre logiciels d'administration, logiciels d'utilisation et jeux est pertinente. On pourrait aller plus loin mais il faut un compromis ; celui-ci est probablement historique, et assez pratique pour qu'on n'ait pas envisagé de le changer.

Non non non, ça montre seulement que ce n'est pas compris. Dans l'immense majorité de ces abus, il existe un chemin standard qui conviendrait, seulement le responsable n'était pas au courant parce qu'il n'a pas la FHS en livre de chevet, c'est tout.

/var/opt c'est standard. /etc/opt aussi.

Il ne s'agit pas de sécurité mais de commodité. L'utilisateur ordinaire préfère probablement ne pas être encombré par des commandes qui ne lui servent pas. S'il préfère les avoir en autocomplétion, super, il a aussi le droit de modifier son $PATH.

Avec cette séparation bin/sbin, on a le choix entre disposer facilement de toutes les commandes ou seulement celles destinées à une simple utilisation. Sans cette séparation, ben on n'aurait pas le choix !

Pour l'admin, oui. Un utilisateur ordinaire qui n'a de toute façon pas accès à ces commandes en écriture se moque bien de les avoir en lecture seule.

J'ai eu du mal à comprendre, donc pour ceux qui seraient dans mon cas : swap.

Les répertoires, ça sert à faire une hiérarchie. Par conséquent, vous ne voulez pas de répertoire, donc vous n'avez pas besoin de liens physiques sur les répertoires.

Ça aurait plutôt sa place dans /srv en effet, mais l'organisation de /srv est laissée à discrétion de l'administrateur, par conséquent une distribution ne peut pas y imposer d'organisation a priori.