C'est différent, même si on parle de quelque chose de comparable en effet.
Inconvénient du miroir : il va répliquer l'intégralité des repos Debian, y compris ce dont on ne se servira jamais (espace de stockage sans commune mesure avec un cache !)
Avantage du miroir : il va répliquer en avance (par exemple) la nuit, et donc tout est disponible "instantanément" quand on en a besoin.
Par contre, je pense qu'il faut bien mettre dans ton sources.list l'adresse de ton miroir.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Judicieuse remarque… ayant essayé uniquement depuis hier, j'ai pas encore eu ce cas. Es-tu sûr déjà que ça ne marche pas quand le proxy n'est pas dispo ? C'est vraiment une erreur fatale ou "juste" un timeout ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je suis d'accord avec toi, comme je dis, c'est comme ça et ça marche pas trop mal, surtout entre adultes consentants :)
Exemple pour illustrer que c'est quand même plus général que Linus et son besoin de déléguer : regarde Gerrit. Outil génial pour la gestion/relecture de patches. Quand tu es relecteur, tu peux mettre +1 pour dire OK, et -1 pour faire des remarques sur le patch (et donc l'améliorer).
- Quand tu mets +1, il y a à côté "Looks good to me, but someone else must approve" (ça me parait bon, mais quelqu'un d'autre doit approuver). C'est logique, il faut qu'un mainteneur mette "+2"
- Quand tu mets -1, il y a à côté "I would prefer that you didn't submit this" (j'aurais préféré que tu ne soumettes pas ça).
Je suis désolé, quand un mec fait un bon patch, que tu lui fais une remarque (y compris un truc énorme comme un buffeur overflow potentiel), t'as pas forcément envie de lui balancer à la gueule "j'aurais préféré que tu soumettes pas ce patch". C'est assez violent je trouve (et gratuit aussi).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Pour avoir tâté le monde de l'upstream, il y a quand même une ambiance à l'humiliation qui est déroutante. Vu qu'on est entre personnes assez compétentes, c'est la coutume, ça passe, mais c'est pas conseillé pour un public non averti.
On retombe peu ou prou sur le problème de la gestion de projet par un Ayatollah. Ça a montré son efficacité, mais c'est pas facile tous les jours pour les autres.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Après selon ton besoin, tu peux te renseigner sur Tor. C'est le réseau qui se chargera de la sortie finale sur Internet, sans dire d'où vient la requête initiale. Ton FAI saura que tu utilises Tor… et c'est tout !
Un VPN c'est entre 2 machines. Au delà de ces machines, le traffic n'est plus chiffré.
Si tu veux te cacher de ton FAI, il te faut donc une machine avant le FAI (ton ordi), et une machine après le FAI (par exemple une dedibox/kimsufi). Le traffic sera chiffré entre ton ordi et ce serveur. AU delà de ce serveur plus rien ne sera chiffré.
Ton ordi -> VPN -> Ton FAI -> VPN -> kimsufi -> site Internet
Donc ton FAI voit juste une connexion chiffrée entre ton ordi et le kimsufi, et n'a aucun idée de ce qu'il y a ensuite. Le fournisseur de ton serveur (OVH dans l'exemple du kimsufi) verra par contre tout ce que tu fais.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Comme dit Bruno, attention à ce que tu fais, ça n'a pas vraiment de sens.
Déjà, explicitons que ton site web local en 192.168.0.20 est accessible avec cette IP uniquement sur ton réseau local. Je pense que tu l'as bien compris. Si tu veux qu'en local n'importe quelle machine puisse y accéder via un DNS, il te faut :
- soit un serveur DNS dans on réseau local que tu vas configurer comme tu veux (et t'as même pas besoin de déposer un nom de domaine chez qqu'un : c'est local, tu fais ce que tu veux, y compris piquer google.com si ça te chante).
- soit sur chaque machine tu vas bidouiller le /etc/hosts pour écrire directement la relation nom/IP.
En général on fait la 2e solution sur sa propre machine de développement, et on fait la 1ere solution pour faire profiter d'autres personnes sur le réseau local. Un intranet d'entreprise est fait comme ça. Dans le cas d'un particulier, il faut oublier les services offerts par la "box" et avoir son propre serveur DHCP, DNS etc. Ça peut faire l'objet d'un joli journal tiens :)
Ensuite si tu veux que ton serveur soit accessible depuis l'extérieur :
- là oui tu dois déposer un nom de domaine
- ce nom de domaine doit pointer vers ton IP publique (www.monip.org te dira laquelle c'est si jamais tu as un doute)
- cette IP publique doit être fixe (sinon va falloir que tu la changes à chaque fois, la propagation des serveur DNS met du temps, des gens vont pointer pendant plusieurs heures vers l'ancienne IP)
- il faut donc qu'un serveur DNS soit disponible 24/7 pour servir ce nom à ceux qui le demandent. dot.tk possède le sien (il suffit donc de lui dire quelle est ton IP, et il se fera un plaisir de donner ton IP à ceux qui cherchent le nom du domaine), ou alors il te propose d'utiliser ton propose serveur DNS : je doute que tu en possèdes un :) (il te faut un serveur style OVH, dedibox etc.)
Donc si tu veux vraiment publier ton site web à l'extérieur, fais simple :
- Use DNS
- Dot TK DNS service
- rempli dans les 2 cases avec ton IP publique
Et bien sûr, il faut que ta box/modem/routeur forwarde le port 80 entrant vers 192.168.0.20 afin que ton serveur puisse recevoir les requêtes HTTP.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Pas dit. Une bonne vanne peut très bien avoir été partagée, et/ou trouvée simultanément. Je ne connais pas les frères ennemis (et faudra remédier à ça apparemment, n'hésite pas à me conseiller 2 ou 3 sketches référence), je ne me permettrais pas d'émettre quelque jugement que ce soit sur eux :D
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Avec mon précédent FAI, j'avais réussi à m'affranchir totalement de leur "box" (je supporte pas ce nom… idée de boîte noire que c'est génial que ça t'apporte l'Internet mondial par magie).
Au menu :
- Modem Zyxel AMG1001
- Boitier SIP Cisco SPA-112 pour la VOIP (il me l'avait fourni en m'y mettant les identifiants)
- Routeur/wifi TP-Link sous OpenWRT
Bref, tu gères ton réseau comme tu veux, c'est cool.
Mais je viens de passer chez SFR suite à leur offre qu'on pouvait pas refuser, et c'est un poil différent ; on te laissera rien faire, à commencer par la VOIP : après avoir écumé les forums, impossible de récupérer ces identifiants. Par contre la "box" (qui est pas si ridicule niveau paramétrages soit dit en passant) te permet de mettre une DMZ.
J'ai donc gardé mon routeur/wifi, que j'ai mis en DMZ. Premier effet : je paramètre mes DNS comme je veux (qui n'est pas le cas avec la box). Je ne passe donc pas par les DNS de mon FAI (confidentialité, censure etc.).
D'après ces mêmes forums par contre, il n'y a aucune difficulté à mettre son propre modem. Du coup, une solution serait de ne plus utiliser leur solution VOIP, et de prendre une ligne chez OVH par exemple (1€ par mois, appels illimités, y compris les fixes à l'étranger. Seul l'appel sur les portables est perdu… à voir si c'est gênant ou pas). Cette ligne serait mise sur le boitier SIP de Cisco, et je reviens à ma config précédente : pas de "box" !!!
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Ah, j'attribuais ça à Raymond Devos pour ma part. Jésus était venu le voir je crois. Il a frappé à la porte, il l'a regardé à travers le Juda. Et quand il le raconte à sa femme "mais non ? mais si !"
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Tu associes "serveur" à un type de matériel, alors que je parle de "serveur" en tant que fonction. Évidemment, le matériel dont tu parles et particulièrement adapté à la fonction dont je parle.
La matériel dont tu parles n'est en rien nécessaire pour définir un "serveur". Il est indispensable dès lors qu'on a une exigence de haute disponibilité, mais c'est tout.
Mais si c'est pour dire que tu manipules au quotidien du gros matos, on te félicite, tu as l'air d'en être très fier, c'est très important d'être fier de son boulot. Mais c'est pas du tout le sujet ici. D'ailleurs toi-même tu lui conseilles finalement un RPi comme serveur (qui je pense est un mauvais conseil d'ailleurs).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
le mec qui fait du traitement video de haute voltige il aura un "desktop" de 40kg plein de quadruple CPUs, de centaines de Go de RAM, de système RAID 0 pour avoir des perfos qui tabassent… pourtant ce sera pas forcément un "serveur" (il pourrait très bien l'éteindre tous les soirs).
mais ta remarque veut dire que tu lui recommande pour gérer ses 4 mails un tel système ? sérieusement ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
La différence entre un serveur et un PC desktop est la même que la différence entre un PC de jeux et un PC de bureautique : l'usage dirige la config.
En général pour un serveur tu vas évaluer :
- tes besoins en espace disque (ainsi qu'en débit de disque éventuellement)
- tes besoins en RAM : c'est dirigé par les services que tu vas héberger. Idéalement, tout est en RAM pendant la vie du serveur, les disques ne servant qu'aux datas proprement dites.
- la conso électrique : allumé 24/7 ça devient un paramètre important
Vu tes besoins, je te propose 2 possibilités :
- partir sur un NUC : conso mini (c'est de la techno d'ordi mobile). Un core i3 avec 8Go de RAM sera déjà très confortable. Prends les version surélevées qui peuvent accepter un disque 2,5". A côté de ça, un NAS boitier pour les sauvegardes.
- un vrai PC boitier : idem, tapes dans un corei3, ou même un pentium (ils sont double coeur). là tu te feras un peu plus plaisir en mettant 8Go de RAM sur une seule barette (prêt à doubler facilement), et directement des disques 3"5 en RAID. pour l'archivage, pense également au NAS, mais si tu t'organises bien et que tu es rigoureux, tu peux l'envisager dans un 2nd temps.
Dans tous les cas, pas d'écran (trouves-toi un écran pendant l'installation, puis tout sera fait en SSH), pas de grosses perfos graphiques etc. De même à l'installation tu peux partir sur des distribs "serveur" histoire de gagner en ressources. La principale différence est dans le fait que ces distribs (Ubuntu par exemple) ne t'installent pas d'interface graphique.
Mais fondamentalement, rien ne différencie un "serveur" d'un "desktop".
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: --rcfile
Posté par gUI (Mastodon) . En réponse au message Faire lire a bash un fichier de configuration personnalisé.. Évalué à 2.
Et en faisant "bash --rcfile global.bash"
Et global.bash qui contiendrait :
. /etc/bashrc
. ~/.bashrc
. ~/ma-config-personnelle
Ça le ferait pas ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Il manque un morceau
Posté par gUI (Mastodon) . En réponse au journal Téléchargement indirect …. Évalué à 2.
Anéfé. Merci pour la correction. Sans vraiment excuser, ça explique tout de même un peu mieux :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# --rcfile
Posté par gUI (Mastodon) . En réponse au message Faire lire a bash un fichier de configuration personnalisé.. Évalué à 4.
Lu dans le man :
L'option --rcfile fichier forcera bash à lire et exécuter les commandes dans fichier plutôt que dans /etc/bash.bashrc et ~/.bashrc.
As-tu essayé ça ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Question de béotien: l'intérêt face à un miroir ?
Posté par gUI (Mastodon) . En réponse au journal Un outil fort pratique : apt-cacher-ng. Évalué à 7. Dernière modification le 30 décembre 2016 à 09:37.
C'est différent, même si on parle de quelque chose de comparable en effet.
Inconvénient du miroir : il va répliquer l'intégralité des repos Debian, y compris ce dont on ne se servira jamais (espace de stockage sans commune mesure avec un cache !)
Avantage du miroir : il va répliquer en avance (par exemple) la nuit, et donc tout est disponible "instantanément" quand on en a besoin.
Par contre, je pense qu'il faut bien mettre dans ton sources.list l'adresse de ton miroir.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Il manque un morceau
Posté par gUI (Mastodon) . En réponse au journal Téléchargement indirect …. Évalué à 8.
Et bien qu'elle ne s'en occupe pas. On est sur le site d'une université, pas du site de l'association des boulistes du village.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Et en nomade ?
Posté par gUI (Mastodon) . En réponse au journal Un outil fort pratique : apt-cacher-ng. Évalué à 3.
Génial, c'est LA bonne façon de faire.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Et en nomade ?
Posté par gUI (Mastodon) . En réponse au journal Un outil fort pratique : apt-cacher-ng. Évalué à 3.
Ah merde !
Judicieuse remarque… ayant essayé uniquement depuis hier, j'ai pas encore eu ce cas. Es-tu sûr déjà que ça ne marche pas quand le proxy n'est pas dispo ? C'est vraiment une erreur fatale ou "juste" un timeout ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Détourage
Posté par gUI (Mastodon) . En réponse au sondage Quel format d'image pour les dépêches et journaux ?. Évalué à 6.
Ça a l'air d'être le cœur du problème, mais je ne comprends pas. Dans 99% des cas on a une image rectangulaire qui n'est pas détourée non ?
En tous cas j'ai du mal à en faire un critère…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Disruptons !
Posté par gUI (Mastodon) . En réponse au journal [HS] Des disruptifs à la pointe... Dans le mélange des genres. Évalué à 2.
Tout monopole est bon à disrupter tôt ou tard. Confidentialité, concurrence, Américabilité pour le cas de PayPal etc.
C'est pas spécialement des méchants, mais évitons qu'ils le deviennent avant qu'on soit pieds et poings liés (exemple de Microsoft, Google etc.)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Améliorer ta configuration?
Posté par gUI (Mastodon) . En réponse au message Vaincre le SPAM. Ou essayer, au moins.. Évalué à 2.
Et niveau faux positifs ça va ? C'est pas trop agressif ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Franche camaraderie
Posté par gUI (Mastodon) . En réponse à la dépêche Sortie du noyau Linux 4.8. Évalué à 9.
Je suis d'accord avec toi, comme je dis, c'est comme ça et ça marche pas trop mal, surtout entre adultes consentants :)
Exemple pour illustrer que c'est quand même plus général que Linus et son besoin de déléguer : regarde Gerrit. Outil génial pour la gestion/relecture de patches. Quand tu es relecteur, tu peux mettre +1 pour dire OK, et -1 pour faire des remarques sur le patch (et donc l'améliorer).
- Quand tu mets +1, il y a à côté "Looks good to me, but someone else must approve" (ça me parait bon, mais quelqu'un d'autre doit approuver). C'est logique, il faut qu'un mainteneur mette "+2"
- Quand tu mets -1, il y a à côté "I would prefer that you didn't submit this" (j'aurais préféré que tu ne soumettes pas ça).
Je suis désolé, quand un mec fait un bon patch, que tu lui fais une remarque (y compris un truc énorme comme un buffeur overflow potentiel), t'as pas forcément envie de lui balancer à la gueule "j'aurais préféré que tu soumettes pas ce patch". C'est assez violent je trouve (et gratuit aussi).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Franche camaraderie
Posté par gUI (Mastodon) . En réponse à la dépêche Sortie du noyau Linux 4.8. Évalué à 6.
Pour avoir tâté le monde de l'upstream, il y a quand même une ambiance à l'humiliation qui est déroutante. Vu qu'on est entre personnes assez compétentes, c'est la coutume, ça passe, mais c'est pas conseillé pour un public non averti.
On retombe peu ou prou sur le problème de la gestion de projet par un Ayatollah. Ça a montré son efficacité, mais c'est pas facile tous les jours pour les autres.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Debian, tout simplement !
Posté par gUI (Mastodon) . En réponse au message Conseil distribution pour Eee pc . Évalué à 6.
J'ai trouvé mon bonheur pour mes eeePC chez Debian.
eeePC701 : Debian minimale, sans interface graphique (rappel : affichage en 800x480)
eeePC901 : Debian avec lxde. C'est léger, beau.
Dans tous les cas, l'installateur marche parfaitement et reconnaît tous les périphériques immédiatement (à commencer par le wifi).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Non
Posté par gUI (Mastodon) . En réponse au message Serveur VPN et client sur la meme machine. Évalué à 3. Dernière modification le 14 décembre 2016 à 13:08.
Après selon ton besoin, tu peux te renseigner sur Tor. C'est le réseau qui se chargera de la sortie finale sur Internet, sans dire d'où vient la requête initiale. Ton FAI saura que tu utilises Tor… et c'est tout !
Explication détaillée et interactive ici : https://www.eff.org/fr/pages/tor-and-https
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Non
Posté par gUI (Mastodon) . En réponse au message Serveur VPN et client sur la meme machine. Évalué à 6.
Un VPN c'est entre 2 machines. Au delà de ces machines, le traffic n'est plus chiffré.
Si tu veux te cacher de ton FAI, il te faut donc une machine avant le FAI (ton ordi), et une machine après le FAI (par exemple une dedibox/kimsufi). Le traffic sera chiffré entre ton ordi et ce serveur. AU delà de ce serveur plus rien ne sera chiffré.
Ton ordi -> VPN -> Ton FAI -> VPN -> kimsufi -> site Internet
Donc ton FAI voit juste une connexion chiffrée entre ton ordi et le kimsufi, et n'a aucun idée de ce qu'il y a ensuite. Le fournisseur de ton serveur (OVH dans l'exemple du kimsufi) verra par contre tout ce que tu fais.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Public vs privé
Posté par gUI (Mastodon) . En réponse au message records dns + 2nde ip sur apache . Évalué à 4. Dernière modification le 13 décembre 2016 à 09:30.
Comme dit Bruno, attention à ce que tu fais, ça n'a pas vraiment de sens.
Déjà, explicitons que ton site web local en 192.168.0.20 est accessible avec cette IP uniquement sur ton réseau local. Je pense que tu l'as bien compris. Si tu veux qu'en local n'importe quelle machine puisse y accéder via un DNS, il te faut :
- soit un serveur DNS dans on réseau local que tu vas configurer comme tu veux (et t'as même pas besoin de déposer un nom de domaine chez qqu'un : c'est local, tu fais ce que tu veux, y compris piquer google.com si ça te chante).
- soit sur chaque machine tu vas bidouiller le /etc/hosts pour écrire directement la relation nom/IP.
En général on fait la 2e solution sur sa propre machine de développement, et on fait la 1ere solution pour faire profiter d'autres personnes sur le réseau local. Un intranet d'entreprise est fait comme ça. Dans le cas d'un particulier, il faut oublier les services offerts par la "box" et avoir son propre serveur DHCP, DNS etc. Ça peut faire l'objet d'un joli journal tiens :)
Ensuite si tu veux que ton serveur soit accessible depuis l'extérieur :
- là oui tu dois déposer un nom de domaine
- ce nom de domaine doit pointer vers ton IP publique (www.monip.org te dira laquelle c'est si jamais tu as un doute)
- cette IP publique doit être fixe (sinon va falloir que tu la changes à chaque fois, la propagation des serveur DNS met du temps, des gens vont pointer pendant plusieurs heures vers l'ancienne IP)
- il faut donc qu'un serveur DNS soit disponible 24/7 pour servir ce nom à ceux qui le demandent. dot.tk possède le sien (il suffit donc de lui dire quelle est ton IP, et il se fera un plaisir de donner ton IP à ceux qui cherchent le nom du domaine), ou alors il te propose d'utiliser ton propose serveur DNS : je doute que tu en possèdes un :) (il te faut un serveur style OVH, dedibox etc.)
Donc si tu veux vraiment publier ton site web à l'extérieur, fais simple :
- Use DNS
- Dot TK DNS service
- rempli dans les 2 cases avec ton IP publique
Et bien sûr, il faut que ta box/modem/routeur forwarde le port 80 entrant vers 192.168.0.20 afin que ton serveur puisse recevoir les requêtes HTTP.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: configuration reseau de base ou presque
Posté par gUI (Mastodon) . En réponse au message records dns + 2nde ip sur apache . Évalué à 2.
tu mélanges tout !
les "IN A" ne sont pas dans network/interfaces mais dans la conf d'un serveur DNS (bind par exemple).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: les Frères ennemis
Posté par gUI (Mastodon) . En réponse à la dépêche Le père Noël arrive avec des jeux. Évalué à 2.
Pas dit. Une bonne vanne peut très bien avoir été partagée, et/ou trouvée simultanément. Je ne connais pas les frères ennemis (et faudra remédier à ça apparemment, n'hésite pas à me conseiller 2 ou 3 sketches référence), je ne me permettrais pas d'émettre quelque jugement que ce soit sur eux :D
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Je suis chez SFR et je veux pareil
Posté par gUI (Mastodon) . En réponse au message Remplacer la box SFR par un routeur particulier. Évalué à 3.
Avec mon précédent FAI, j'avais réussi à m'affranchir totalement de leur "box" (je supporte pas ce nom… idée de boîte noire que c'est génial que ça t'apporte l'Internet mondial par magie).
Au menu :
- Modem Zyxel AMG1001
- Boitier SIP Cisco SPA-112 pour la VOIP (il me l'avait fourni en m'y mettant les identifiants)
- Routeur/wifi TP-Link sous OpenWRT
Bref, tu gères ton réseau comme tu veux, c'est cool.
Mais je viens de passer chez SFR suite à leur offre qu'on pouvait pas refuser, et c'est un poil différent ; on te laissera rien faire, à commencer par la VOIP : après avoir écumé les forums, impossible de récupérer ces identifiants. Par contre la "box" (qui est pas si ridicule niveau paramétrages soit dit en passant) te permet de mettre une DMZ.
J'ai donc gardé mon routeur/wifi, que j'ai mis en DMZ. Premier effet : je paramètre mes DNS comme je veux (qui n'est pas le cas avec la box). Je ne passe donc pas par les DNS de mon FAI (confidentialité, censure etc.).
D'après ces mêmes forums par contre, il n'y a aucune difficulté à mettre son propre modem. Du coup, une solution serait de ne plus utiliser leur solution VOIP, et de prendre une ligne chez OVH par exemple (1€ par mois, appels illimités, y compris les fixes à l'étranger. Seul l'appel sur les portables est perdu… à voir si c'est gênant ou pas). Cette ligne serait mise sur le boitier SIP de Cisco, et je reviens à ma config précédente : pas de "box" !!!
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: les Frères ennemis
Posté par gUI (Mastodon) . En réponse à la dépêche Le père Noël arrive avec des jeux. Évalué à 5. Dernière modification le 11 décembre 2016 à 16:31.
Ah, j'attribuais ça à Raymond Devos pour ma part. Jésus était venu le voir je crois. Il a frappé à la porte, il l'a regardé à travers le Juda. Et quand il le raconte à sa femme "mais non ? mais si !"
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Différence d'usage
Posté par gUI (Mastodon) . En réponse au message Achat d'un PC serveur à prix noël. Évalué à 2. Dernière modification le 07 décembre 2016 à 13:21.
Tu associes "serveur" à un type de matériel, alors que je parle de "serveur" en tant que fonction. Évidemment, le matériel dont tu parles et particulièrement adapté à la fonction dont je parle.
La matériel dont tu parles n'est en rien nécessaire pour définir un "serveur". Il est indispensable dès lors qu'on a une exigence de haute disponibilité, mais c'est tout.
Mais si c'est pour dire que tu manipules au quotidien du gros matos, on te félicite, tu as l'air d'en être très fier, c'est très important d'être fier de son boulot. Mais c'est pas du tout le sujet ici. D'ailleurs toi-même tu lui conseilles finalement un RPi comme serveur (qui je pense est un mauvais conseil d'ailleurs).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Différence d'usage
Posté par gUI (Mastodon) . En réponse au message Achat d'un PC serveur à prix noël. Évalué à 4.
le mec qui fait du traitement video de haute voltige il aura un "desktop" de 40kg plein de quadruple CPUs, de centaines de Go de RAM, de système RAID 0 pour avoir des perfos qui tabassent… pourtant ce sera pas forcément un "serveur" (il pourrait très bien l'éteindre tous les soirs).
mais ta remarque veut dire que tu lui recommande pour gérer ses 4 mails un tel système ? sérieusement ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Différence d'usage
Posté par gUI (Mastodon) . En réponse au message Achat d'un PC serveur à prix noël. Évalué à 4.
La différence entre un serveur et un PC desktop est la même que la différence entre un PC de jeux et un PC de bureautique : l'usage dirige la config.
En général pour un serveur tu vas évaluer :
- tes besoins en espace disque (ainsi qu'en débit de disque éventuellement)
- tes besoins en RAM : c'est dirigé par les services que tu vas héberger. Idéalement, tout est en RAM pendant la vie du serveur, les disques ne servant qu'aux datas proprement dites.
- la conso électrique : allumé 24/7 ça devient un paramètre important
Vu tes besoins, je te propose 2 possibilités :
- partir sur un NUC : conso mini (c'est de la techno d'ordi mobile). Un core i3 avec 8Go de RAM sera déjà très confortable. Prends les version surélevées qui peuvent accepter un disque 2,5". A côté de ça, un NAS boitier pour les sauvegardes.
- un vrai PC boitier : idem, tapes dans un corei3, ou même un pentium (ils sont double coeur). là tu te feras un peu plus plaisir en mettant 8Go de RAM sur une seule barette (prêt à doubler facilement), et directement des disques 3"5 en RAID. pour l'archivage, pense également au NAS, mais si tu t'organises bien et que tu es rigoureux, tu peux l'envisager dans un 2nd temps.
Dans tous les cas, pas d'écran (trouves-toi un écran pendant l'installation, puis tout sera fait en SSH), pas de grosses perfos graphiques etc. De même à l'installation tu peux partir sur des distribs "serveur" histoire de gagner en ressources. La principale différence est dans le fait que ces distribs (Ubuntu par exemple) ne t'installent pas d'interface graphique.
Mais fondamentalement, rien ne différencie un "serveur" d'un "desktop".
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quel est l'alphabet utilisé ?
Posté par gUI (Mastodon) . En réponse au journal Les Init alter-natifs. Évalué à 4.
Blague déjà faite
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Un désabonnement compliqué !
Posté par gUI (Mastodon) . En réponse au journal Des milliers de contenus librement réutilisables. Évalué à 3.
+1 pour ta signature qui m'a bien fait rigoler. Par contre il y a une faute : publiée ;)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.