Oui, après, en général, si tu héberges ton serveur dans ta société, 99.9% du temps si quelqu'un doit synchroniser la totalité de ses mails il le fera depuis le bureau. S'il est en déplacement, il ne resynchronisera jamais la totalité de la boite, il se contentera de récupérer les nouveaux mails.
Bof. Si tu travailles avec des VM tu as de toute façon au moins deux hosts qui peuvent reprendre la charge au cas où (quitte à éteindre des trucs moins importants). Sinon, tu bosses probablement avec ta marque préférée donc tous tes serveurs sont sans doute relativement proches au niveau hardware. Puis tu as sans doute bien un vieux serveur que tu n'utilises plus et que tu peux utiliser le cas échéant, car je doute que ton serveur mail nécessite la crème de la crème si c'est juste temporaire. De toute façon, le fait d'avoir un peu de spare (ou un contact qui peut en fournir sans délai) est juste un pré-requis si tu veux avoir une informatique fiable en entreprise, et pas juste pour l'e-mail.
Après, oui, les VM, c'est quand même génial pour ça.
Ok, pour rire essaye de faire écrire à ton FAI que tu auras accès au port 5662 en entrant sur ta connexion pour les 3 prochaines années.
Bah dans le contrat y'a écrit que tous les ports TCP et UDP sont accessibles, qu'il n'y a aucun bloquage. Après je ne sais pas ce que ça dit en France, mais généralement tu choisis ton fournisseur en fonction de tes besoins, et ce qu'il garantit, il le garantit, point. Si Vivendi a eu besoin de faire appel à Colt, grand bien leur fasse, mais si l'on suit ton raisonnement, il n'est pas impossible que Colt modifie un jour ses services et bloquent ton fameux port 5662 pour une mauvaise raison ou l'autre.
Oui, et à moins que tu n'envoies et ne reçoivent tous tes mails en connexion directe (MX initial à MX destinataire sans MTA intercallé), et que tu ne passe pas toutes tes connexions via tunnels sécurisé c'est aussi le cas de ton FAI et du peer principal de ton FAI (au moins pour 80% des infos).
C'est d'ailleurs une grande crainte vis à vis de la tendance de ces derniers temps: on envoie n'importe quoi par e-mail, comme par exemple un lien avec "infos de login" pour ne pas devoir mettre son mot de passe quand on clique dans un mail qu'on reçoit, et tout cela passe en clair. Personne ne pense même à utiliser (ou à donner l'option d'utiliser) une technique comme PGP/GPG...
L'auto-hébergement n'implique pas que tu ne puisses faire confiance à un tiers en cas de force majeure. Le plantage d'un serveur ou d'une connexion est une force majeure.
Tu as déjà fait de l'auto hébergement pour une société ?
Note que l'"autohébergement en société" c'est quand même pas mal pratiqué par tous les clients Microsoft qui installent de l'Exchange. Je ne vois pas pourquoi tu aurais davantage de problèmes avec du libre.
Et je fais comment pour me demander la fourniture d'une pièce défectueuse sous quatre heures ?
Comme ton prestataire le ferait: tu gardes des pièces en stock. C'est d'autant plus facile si tu travailles dans une boite informatique ou avec des machines virtuelles.
Pour info le même problème se pose de façon aussi cruciale avec pas mal de services fournis dans n'importe quel boite (crm, stockage de fichiers, bases de données, etc) donc je ne vois pas en quoi le mail fait exception. C'est une question de bonne gestion du matériel informatique.
Le rétablissement d'un lien ou la réouverture d'un port vers internet ?
Ça ça dépend du contrat que tu as avec ton FAI et de la personne qui gère ton routeur.
Le seul avantage que le professionnel a sur l'auto-hébergement c'est que tu as quelqu'un sur qui gueuler si ça déconne (et encore, si le prestataire s'appelle Google ou Microsoft, tu peux toujours courir).
Ceci dit, la fiabilité dépend principalement des éléments en jeu et, incidemment, du prix que tu paies, mais, pas du fait que tu le fais toi-même ou via un prestataire. Si tu as une ligne DSL avec un niveau de service garanti je ne vois pas où est le problème, et l'auto-hébergement, même pour des boites de plusieurs centaines d'employés, n'est pas si rare que tu peux le croire.
Freedesktop s'est penché sur la question et la tendance actuelle dans cette norme et ailleurs est d'utiliser ~/.local comme préfixe. L'idée c'est qu'on ne pollue pas ~ avec des dossiers inintéressants pour l'utilisation quotidienne (penser avec une GUI quelconque).
Cependant, antérieurement tout le monde avait tendance à utiliser ~ comme préfixe et cela se retrouve encore aujourd'hui dans pas mal d'outils de la belle époque. Je fais toujours cela sur les serveurs également.
Après, tu peux un peu faire comme tu le souhaites tant que tu rajoutes le chemin dans ton PATH. C'est surtout une question de goûts.
Avec les media queries CSS il est possible de styler différemment le site en fonction de la résolution. Du coup une même CSS pourrait s'adapter à la fois au site vu sur PC et sur mobile.
Et c'est probablement plus simple à l'utilisation (et à l'implémentation) que de devoir définir un lot de CSS par taille de périphérique...
Il y a aussi le lien "[^]" qui est cassé vu qu'il donne l'ancre vers le commentaire parent alors qu'il n'apparaît pas sur la page du commentaire.
Je dirais donc que plutôt que de tout corriger le plus sain serait de supprimer purement et simplement la page des commentaires et de la remplacer par des liens complets vers le contenu associé avec une ancre vers le commentaire proprement dit. Pour les anciens liens diffusés hors du site, les 302 Redirect Permanent sont là pour ça.
Dans ce cas peut-être que linuxfr devrait déprécier les pages individuelles de commentaires (voire les remplacer par un 302) et remplacer celles-ci par des liens vers les commentaires. Charité bien ordonnée commence par soi-même.
Bha au niveau de la glib, tu associes un callback avec la hashtable pour détruire les objets que tu mets dedans. En C on ne peut pas détruire un objet de façon générique, il suffit d'avoir un pointeur dans le tas...
Mettre des objets statiques dans une hashtable est facile, suffit de mettre un callback qui fait rien... Par contre mettre des éléments statiques dans une hashtable me paraît avoir un effet limité la plupart du temps par rapport à une structure statique un tant soit peu efficace...
Ceci dit, avec la glib, souvent tu te retrouves à devoir gérer des listes ou des tables de hashage remplies de pointeurs vers une structure de données qui fait à peine plus que la taille dudit pointeur (genre une structure à deux ou trois éléments, comme une GValue par exemple). À ce moment-là, je doute que la copie implique un problème de performance (je dirais plutôt le contraire), par contre ça simplifie beaucoup la gestion du cycle de vie de tels petites structures fonctionnelles.
En fait, en pratique, quand tu as une table de hashage celle-ci a le plus souvent l'ownership sur les objets qu'elle contient, donc ça a du sens d'"include" par valeur les éléments dans la structure de données, même si on peut éventuellement les accéder par référence par la suite.
C'est probablement le cas où les templates sont les plus utiles en fait, et réduisent beaucoup le bookkeeping et les bugs. Après, on peut appeler ça templates, types paramétriques ou génériques, osef. Mais la fonctionnalité serait sympa.
Je dois dire que je suis un inconditionnel de apt-get. Que dois-je écrire derrière le nom de notre sacro-sainte commande de gestion de paquet pour pouvoir tester ce jeux aux screenshots si prometteurs?
Le problème principal est probablement que la communauté ruby semble ne pas beaucoup donner d'importance à la stabilité des APIs et aux régressions au sein d'une même version majeure. S'ils étaient un peu plus coopératifs avec les distributions (qui ont besoin de la stabilité des APIs pour avoir un packaging efficace) tout serait réglé.
Pour ma part je ne suis pas français, mais en l'occurence je ne crois pas que la France soit peuplée de chômeurs, et il n'est certainement pas non plus nécessaire de se faire naturaliser pour travailler à l'étranger.
C'est le problème principal. On est dans le monde de la facilité, de l'immédiateté et de la paresse (les gens veulent quelque chose maintenant, tout de suite et sans se casser la tête) mais aujourd'hui il est extrêmement plus compliqué d'obtenir ce que l'on veut légalement qu'illégalement.
En Belgique il est par exemple impossible d'obtenir certaines séries en VO sous-titré en VO dans des délais raisonnables. Elles ne sortent qu'en DVD (6 mois après avoir été diffusées en français à la télé, soit avec plus d'un an de retard), avec deux pistes audio (fr / en) et deux ensembles de sous-titres (fr / nl)...
Ben c'est un peu comme toutes les activités subventionnées: tant qu'on te donne du budget tu as tendance à l'utiliser complètement sinon après on va te dire que tu n'as pas besoin d'autant et on va te donner moins.
Il y a énormément de pognon gaspillé dans les tournages, tout simplement parce qu'il y a eu quelques années fastes qui ont permis d'enfler les budgets, et maintenant que le blé se fait plus rare, il est difficile de les réduire...
Après, quand tu vois le chantage au salaire effectué par certains acteurs de séries américaines (je pense par exemple à ce qui s'est dit sur les dernières saisons de Desperate Housewives), tu te dis que ça doit être quand même bien rentable sinon ils jetteraient l'éponge ou changeraient d'acteurs (retirer un acteur d'une série ça se fait tout le temps, y'a qu'à voir la saison 9 de "Mon oncle Charlie", sans Charlie).
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 3.
Tu te fourvoies mon ami, les serveurs gmail fonctionnent sous linux!
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 3.
Reste à voir le coût d'une plainte (en temps, en argent et en emmerdement) par rapport à juste aller chez un autre prestataire.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 1.
Oui, après, en général, si tu héberges ton serveur dans ta société, 99.9% du temps si quelqu'un doit synchroniser la totalité de ses mails il le fera depuis le bureau. S'il est en déplacement, il ne resynchronisera jamais la totalité de la boite, il se contentera de récupérer les nouveaux mails.
Puis y'a le SDSL aussi.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 2.
Bof. Si tu travailles avec des VM tu as de toute façon au moins deux hosts qui peuvent reprendre la charge au cas où (quitte à éteindre des trucs moins importants). Sinon, tu bosses probablement avec ta marque préférée donc tous tes serveurs sont sans doute relativement proches au niveau hardware. Puis tu as sans doute bien un vieux serveur que tu n'utilises plus et que tu peux utiliser le cas échéant, car je doute que ton serveur mail nécessite la crème de la crème si c'est juste temporaire. De toute façon, le fait d'avoir un peu de spare (ou un contact qui peut en fournir sans délai) est juste un pré-requis si tu veux avoir une informatique fiable en entreprise, et pas juste pour l'e-mail.
Après, oui, les VM, c'est quand même génial pour ça.
Bah dans le contrat y'a écrit que tous les ports TCP et UDP sont accessibles, qu'il n'y a aucun bloquage. Après je ne sais pas ce que ça dit en France, mais généralement tu choisis ton fournisseur en fonction de tes besoins, et ce qu'il garantit, il le garantit, point. Si Vivendi a eu besoin de faire appel à Colt, grand bien leur fasse, mais si l'on suit ton raisonnement, il n'est pas impossible que Colt modifie un jour ses services et bloquent ton fameux port 5662 pour une mauvaise raison ou l'autre.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 2.
C'est d'ailleurs une grande crainte vis à vis de la tendance de ces derniers temps: on envoie n'importe quoi par e-mail, comme par exemple un lien avec "infos de login" pour ne pas devoir mettre son mot de passe quand on clique dans un mail qu'on reçoit, et tout cela passe en clair. Personne ne pense même à utiliser (ou à donner l'option d'utiliser) une technique comme PGP/GPG...
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 2.
L'auto-hébergement n'implique pas que tu ne puisses faire confiance à un tiers en cas de force majeure. Le plantage d'un serveur ou d'une connexion est une force majeure.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 5.
Note que l'"autohébergement en société" c'est quand même pas mal pratiqué par tous les clients Microsoft qui installent de l'Exchange. Je ne vois pas pourquoi tu aurais davantage de problèmes avec du libre.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 2.
Comme ton prestataire le ferait: tu gardes des pièces en stock. C'est d'autant plus facile si tu travailles dans une boite informatique ou avec des machines virtuelles.
Pour info le même problème se pose de façon aussi cruciale avec pas mal de services fournis dans n'importe quel boite (crm, stockage de fichiers, bases de données, etc) donc je ne vois pas en quoi le mail fait exception. C'est une question de bonne gestion du matériel informatique.
Ça ça dépend du contrat que tu as avec ton FAI et de la personne qui gère ton routeur.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ?. Évalué à 3.
Le seul avantage que le professionnel a sur l'auto-hébergement c'est que tu as quelqu'un sur qui gueuler si ça déconne (et encore, si le prestataire s'appelle Google ou Microsoft, tu peux toujours courir).
Ceci dit, la fiabilité dépend principalement des éléments en jeu et, incidemment, du prix que tu paies, mais, pas du fait que tu le fais toi-même ou via un prestataire. Si tu as une ligne DSL avec un niveau de service garanti je ne vois pas où est le problème, et l'auto-hébergement, même pour des boites de plusieurs centaines d'employés, n'est pas si rare que tu peux le croire.
# XDG
Posté par nud . En réponse au message Chemin standard pour un "prefix" local à l'utilisateur. Évalué à 1.
Freedesktop s'est penché sur la question et la tendance actuelle dans cette norme et ailleurs est d'utiliser ~/.local comme préfixe. L'idée c'est qu'on ne pollue pas ~ avec des dossiers inintéressants pour l'utilisation quotidienne (penser avec une GUI quelconque).
Cependant, antérieurement tout le monde avait tendance à utiliser ~ comme préfixe et cela se retrouve encore aujourd'hui dans pas mal d'outils de la belle époque. Je fais toujours cela sur les serveurs également.
Après, tu peux un peu faire comme tu le souhaites tant que tu rajoutes le chemin dans ton PATH. C'est surtout une question de goûts.
# Mediaqueries ?
Posté par nud . En réponse à l’entrée du suivi un CSS par user agent. Évalué à 1 (+0/-0).
Avec les media queries CSS il est possible de styler différemment le site en fonction de la résolution. Du coup une même CSS pourrait s'adapter à la fois au site vu sur PC et sur mobile.
Et c'est probablement plus simple à l'utilisation (et à l'implémentation) que de devoir définir un lot de CSS par taille de périphérique...
[^] # Re: Lien du thread
Posté par nud . En réponse à l’entrée du suivi Page d'un commentaire: donner un peu de contexte. Évalué à 1 (+0/-0).
Et où est-il, ce lien?
[^] # Re: Lien du thread
Posté par nud . En réponse à l’entrée du suivi Page d'un commentaire: donner un peu de contexte. Évalué à 1 (+0/-0).
Quel lien ?
Sur https://linuxfr.org/nodes/88837/comments/1308555 (ton commentaire) il y a trois liens:
On ne trouve nulle part le lien "intéressant" pour voir le commentaire dans son contexte. Ce lien serait https://linuxfr.org/suivi/page-dun-commentaire-donner-un-peu-de-contexte#comment-1308555 soit lien vers le contenu avec ancre.
Il y a aussi le lien "[^]" qui est cassé vu qu'il donne l'ancre vers le commentaire parent alors qu'il n'apparaît pas sur la page du commentaire.
Je dirais donc que plutôt que de tout corriger le plus sain serait de supprimer purement et simplement la page des commentaires et de la remplacer par des liens complets vers le contenu associé avec une ancre vers le commentaire proprement dit. Pour les anciens liens diffusés hors du site, les 302 Redirect Permanent sont là pour ça.
[^] # Re: Lien du thread
Posté par nud . En réponse à l’entrée du suivi Page d'un commentaire: donner un peu de contexte. Évalué à 1 (+0/-0).
Dans ce cas peut-être que linuxfr devrait déprécier les pages individuelles de commentaires (voire les remplacer par un 302) et remplacer celles-ci par des liens vers les commentaires. Charité bien ordonnée commence par soi-même.
Voyez donc cette entrée de suivi par exemple.
[^] # Re: moar features
Posté par nud . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 1.
Bha au niveau de la glib, tu associes un callback avec la hashtable pour détruire les objets que tu mets dedans. En C on ne peut pas détruire un objet de façon générique, il suffit d'avoir un pointeur dans le tas...
Mettre des objets statiques dans une hashtable est facile, suffit de mettre un callback qui fait rien... Par contre mettre des éléments statiques dans une hashtable me paraît avoir un effet limité la plupart du temps par rapport à une structure statique un tant soit peu efficace...
[^] # Re: moar features
Posté par nud . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 5.
Ceci dit, avec la glib, souvent tu te retrouves à devoir gérer des listes ou des tables de hashage remplies de pointeurs vers une structure de données qui fait à peine plus que la taille dudit pointeur (genre une structure à deux ou trois éléments, comme une GValue par exemple). À ce moment-là, je doute que la copie implique un problème de performance (je dirais plutôt le contraire), par contre ça simplifie beaucoup la gestion du cycle de vie de tels petites structures fonctionnelles.
En fait, en pratique, quand tu as une table de hashage celle-ci a le plus souvent l'ownership sur les objets qu'elle contient, donc ça a du sens d'"include" par valeur les éléments dans la structure de données, même si on peut éventuellement les accéder par référence par la suite.
C'est probablement le cas où les templates sont les plus utiles en fait, et réduisent beaucoup le bookkeeping et les bugs. Après, on peut appeler ça templates, types paramétriques ou génériques, osef. Mais la fonctionnalité serait sympa.
# Packagés dans les distros ?
Posté par nud . En réponse à la dépêche Un pas de plus pour 0 A.D.. Évalué à 0.
Je dois dire que je suis un inconditionnel de apt-get. Que dois-je écrire derrière le nom de notre sacro-sainte commande de gestion de paquet pour pouvoir tester ce jeux aux screenshots si prometteurs?
[^] # Re: Mmmh
Posté par nud . En réponse à la dépêche Hébergez vos projets avec Gitlab. Évalué à 2.
Le problème principal est probablement que la communauté ruby semble ne pas beaucoup donner d'importance à la stabilité des APIs et aux régressions au sein d'une même version majeure. S'ils étaient un peu plus coopératifs avec les distributions (qui ont besoin de la stabilité des APIs pour avoir un packaging efficace) tout serait réglé.
[^] # Re: Menu Global
Posté par nud . En réponse au journal La fin de la barre de menu?. Évalué à 2.
Je sais qu'avec gnome 2.4 je masquais déjà la barre de menu. Vu qu'il y a eu 15 releases entre les deux ça doit faire 7 ans et demi au moins, donc.
[^] # Re: Pas encore au niveau de VLC
Posté par nud . En réponse à la dépêche GStreamer : bientôt la version 1.0. Évalué à 1.
Pour info c'était de l'humour.
Pour ma part je ne suis pas français, mais en l'occurence je ne crois pas que la France soit peuplée de chômeurs, et il n'est certainement pas non plus nécessaire de se faire naturaliser pour travailler à l'étranger.
[^] # Re: Pas encore au niveau de VLC
Posté par nud . En réponse à la dépêche GStreamer : bientôt la version 1.0. Évalué à -1.
Ben la France on l'aime ou on la quitte, si j'ai bien compris.
[^] # Re: .
Posté par nud . En réponse au journal Les représentants du cinéma et de la télé se plaignent encore.. Évalué à 2.
C'est le problème principal. On est dans le monde de la facilité, de l'immédiateté et de la paresse (les gens veulent quelque chose maintenant, tout de suite et sans se casser la tête) mais aujourd'hui il est extrêmement plus compliqué d'obtenir ce que l'on veut légalement qu'illégalement.
En Belgique il est par exemple impossible d'obtenir certaines séries en VO sous-titré en VO dans des délais raisonnables. Elles ne sortent qu'en DVD (6 mois après avoir été diffusées en français à la télé, soit avec plus d'un an de retard), avec deux pistes audio (fr / en) et deux ensembles de sous-titres (fr / nl)...
[^] # Re: marge = coût de vente - coût d'acquisition
Posté par nud . En réponse au journal Les représentants du cinéma et de la télé se plaignent encore.. Évalué à 2.
Ben c'est un peu comme toutes les activités subventionnées: tant qu'on te donne du budget tu as tendance à l'utiliser complètement sinon après on va te dire que tu n'as pas besoin d'autant et on va te donner moins.
Il y a énormément de pognon gaspillé dans les tournages, tout simplement parce qu'il y a eu quelques années fastes qui ont permis d'enfler les budgets, et maintenant que le blé se fait plus rare, il est difficile de les réduire...
Après, quand tu vois le chantage au salaire effectué par certains acteurs de séries américaines (je pense par exemple à ce qui s'est dit sur les dernières saisons de Desperate Housewives), tu te dis que ça doit être quand même bien rentable sinon ils jetteraient l'éponge ou changeraient d'acteurs (retirer un acteur d'une série ça se fait tout le temps, y'a qu'à voir la saison 9 de "Mon oncle Charlie", sans Charlie).
[^] # Re: 5 minutes ought to be enough for anybody
Posté par nud . En réponse au journal L'édition des commentaires sur LinuxFR, ou pas ?. Évalué à 2.
Ça invalidera tous les commentaires des gens qui ont relevé la faute!
[^] # Re: Pas encore au niveau de VLC
Posté par nud . En réponse à la dépêche GStreamer : bientôt la version 1.0. Évalué à 1.
L'auteur de Totem est français aussi.