Raphaël SurcouF a écrit 2609 commentaires

Ah, ça, je confirme : je vis dans une petite ville de la RP, avec pas moins de 4 supermarchés à promixité immédiate (surtout en voiture pour la moitié d'entre-eux, zones commerciales sux). La ville est un dortoir où les quelques commerces ferment à 20h30 maximum (dont le Super U et même les épiciers dits « arabes ».). Ce détail a son importance, en RP, quand les temps de trajets peuvent aller de 40 minutes à 1h30 : le temps de revenir du bureau et tout est déjà fermé...
Dans ma ville natale de province, les petits épiciers sont ouverts jusqu'à 1h du matin. Certes, en général, la moitié de leurs rayons sont remplis de bouteilles d'alcools et autres sodas, sans parler des chips et autres trucs à grignoter : le choix laisse parfois à désirer, mais certains épiciers offrent des services de traiteurs.

En général, ils n'en ont rien à secouer du mot de passe du BIOS.
D'expérience, je peux t'affirmer que le mot de passe reste tel quel dans le BIOS.
Leur seul objectif est de revendre le portable, rien de plus.

On peut ajoute Chypre, qui fait pourtant partie de l'Union Européenne.

Il n'y a pas si longtemps, les sites militaires français étaient invisibles sur les différentes cartes de l'IGN. Cependant, l'arrivée de Google Maps a tout changé : les mêmes cartes dévoilaient les emplacements alors invisibles sur les cartes IGN, si bien qu'il était facile de faire la relation entre les deux. Tout ceci est grotesque dans la mesure où les satellites amis comme ennemis peuvent allègrement visualiser tout ce qu'il y a à la surface de la Terre (avec des précisions allant jusqu'au mètre près) : autant noyer les sites sensibles dans la masse et enfouir ce qu'on ne veut pas dévoiler.
En outre, les GPS actuels sont déroutés par ces sites sensibles : un collègue règle son GPS avant de démarrer pour calculer un itinéraire le menant à destination. Le GPS affichait la position approximative mais sans aucune route, comme si on était en dehors de la carte.

Justement, pour les cyber-cafés, j'ai vu deux écoles :
- ceux qui posent le boîtier à côté de l'écran, donc largement accessible ;
- ceux qui l'enferment dans un boîtier ou un caisson.

Dans le second cas, pour la maintenance, il ne faut pas oublier les outils pour ouvrir le dit boîtier. Dans les cas, il faut tout de même être discret, même si rebooter le PC est possible.
Pour ce dernier cas, on bloque généralement dans le BIOS, la possibilité de booter sur clés USB ou sur CD.
Évidemment, tout cela est dissuasif car si tu as une heure devant toi, personne dans les parages, et que tu as ta visseuse électrique sous le coude, tu peux facilement faire sauter cette protection toute relative. Le premier but étant d'éviter que les clients fassent n'importe quoi pendant les horaires d'ouvertures.

Dans l'intervalle ils conseillaient de ne pas télécharger le moindre paquet : "as a precaution, we recommend you not download or update any additional packages on your Fedora systems".

En matière de sécurité, mieux vaut communiquer sur les problèmes que laisser les rumeurs le faire à ta place. Même si la loi américaine, notamment DMCA, ne permet à RedHat de préciser la portée du problème de sécurité, la moindre des choses aurait été de le dire.
De ne pas laisser les utilisateurs dans la panade, l'incertitude, le doute.
Au lieu de cela, ils parlent simplement d'éviter de mettre à jour des paquets via RHN...
Et si jamais il y a des failles de sécurité dans d'autres logiciels, on doit attendre la fin de cette période de rétention d'informations ? Faire nous-même les mises à jour ? Non merci.
À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.

Non, j'utilise la jvm de Sun, sun-java6-jre.

Un endroit sans téléphone, c'est aussi un endroit calme... Enfin je dis ça malheureusement, les chieurs qui mettent de la musique de merde à fond sur le portable ça passe toujours
Justement : si le contenu musical est en ligne, ils seront coupés ;-)

J'aimerais bien mais il semble y avoir un problème avec le son...
Pourtant, ni esd ni pulseaudio ne tournent et il persiste à m'affirmer que le périphérique est occupé alors qu'il fonctionne avec toutes les autres applications (non-Java).

Boire ou compiler, faut choisir !

Je pense qu'il voulait parler de l'ordre des Diptera ou Diptères dont le « nom_vernaculaire » très connu : la mouche.

Heureusement qu'il y eu des résistants dans le pays dit occupé, sinon certaines opérations auraient tourné au vinaigre sans de précieux renseignements et autres sabotages.
Comme si les Français avaient attendu que les Américains viennent pour essayer de se libérer... Ça ne faisait jamais que 5 ans qu'on était occupé.

http://www.list.org/

Évidemment, j'approuve également Sympa mais aucune des deux solutions n'est écrite en PHP, respectivement Python et Perl. Toutefois, Sympa utilise MySQL.

Donc, on ne peut pas vraiment utiliser apt-rpm en espérant avoir le support de RedHat.
C'était la réponse que j'attendais.

Pour les modules Perl du CPAN, il est trés facile de créer un paquet Debian grâce à dh-make-perl. Ça aide.
Ensuite, les développeurs ne sont pas non plus des maîtres en tout et il y a de nombreuses applications (pas forcément libres mais aussi des libres) dont j'ai pu voir les limites en support réseau, notamment pour gérer le protocole LDAP correctement.
Avec de nombreux développeurs, on (les admins) a parfois l'impression que l'installation de leurs applications se résume à mettre tout ce qu'il faut dans le répertoire qui-va-bien et plouf, ça marche ! Sauf que ça ne marche pas partout, pour diverses raisons, même en utilisant la méthode de l'autruche.
Après, tu peux déplorer le nombre de distributions mais que dire du nombre de langages de développement, notamment les langages interprétés ou pseudo-interprétés (Perl, PHP, Java, Python, Ruby, etc.).

Surtout que le médaillé d'argent en haltérophilie : ça faisait quand même plus de 30 ans qu'on n'en avait eu aucune dans ce sport...
Il n'a pas eu l'or mais au moins, il en a eu une !

Oui mais apt-rpm est-il supporté par RedHat ?

Oui mais le client, il s'en fout.
Il te demande un contexte technique précis, à toi de t'y tenir.
Il en a rien à faire que ta famille dépend de toi pour manger.
Il ne t'a pas forcé la main à signer le contrat ? Et si c'est trop dur en indépendant, pourquoi ne pas (re-)venir à la société de services ou autre poste de salarié ?
La prochaine fois que tu proposeras une modification du contexte initialement demandé, assure-toi de le faire cofnirmer PAR ÉCRIT. Les paroles s'envolent, etc.. Mais si dans le cahier des charges ou CCTP, il y avait explicitement mentionné RHEL, tu étais en porte-à-faux vis-à-vis de ton client. Que certains prestataires mentent sur les compétences techniques réelles, qu'ils assument mais que cela ne porte pas le discrédit sur leurs confrères.

Amusant que tu compares cela au support SUN, parce que de la langue même de certains employés de SUN France, ce n'est pas franchement le cas. Ou alors, tu parles très bien l'anglais international avec les accents indiens, etc.
Une fois, j'ai fait appel à eux et il m'a fallu é-p-e-l-e-r « /usr/lib/... » et mon interlocuteur n'avait aucune base en système Unix. Au final, j'ai trouvé entretemps une solution de contournement via Google, sur un site de SUN et j'ai demandé l'avis du support qui l'a approuvé. Mais ils n'ont pas été capable de me fournir l'information en question avant.
En fait, le support de niveau 1 est mutualisé et, si tu ne connais pas les bons mot-clés à utiliser, tu risques d'avoir un ticket mal routé.
Et ce genre de centres de support mutualisés est, àmha, à la base même de dédain qu'ont les professionnels vis-à-vis des supports techniques. Et, au risque de me répéter, il s'agit d'une conséquence de la rationalisation financière de ces centres qui ont néanmoins un coût.
Un « vrai » support dispose donc de personnels qualifiés, ayant des connaissances techniques et donc, qui coûtent très chers, en tout cas, certainement plus chers que la plupart des personnels employés.

Mais pourquoi attendre ?
Face à un problème qu'un support devrait résoudre, tu ouvres un ticket !
Ensuite, si tu as du temps à consacrer à ce problème, par rapport à ta liste des tâches, au lieu d'attendre bêtement la réponse (avec une solution parce que l'AR ne compte pas, hein), tu peux commencer tes propres investigations.
Ainsi, si le support a manqué à ses obligations, tu seras couverts car tu auras fait appel à eux (et n'hésite pas à en faire part à tes supérieurs lors de tes CR sinon, ils n'en sauront jamais rien) et si ta solution de contournement fonctionne, tu en seras d'autant crédité.

Comme fanatique, tu es pourtant bien placé...
Le problème n'est pas tant de savoir quel format a eu le support XYZ en premier, mais pourquoi certaines fonctionnalités sont toujours manquantes chez l'un et pas chez l'autre.
À chaque fois, tu nous a sortis une tirade sur le thème de « ça ne sert à rien » (genre Debconf...). Si ça ne servait vraiment à rien, pourquoi est-ce que certains développeurs les auraient implémenter ? Par souci de l'utilisateur ?

La gestion de désinstallation d'aptitude ou synaptic (et maintenant apt-get si je ne m'abuse) n'a rien d'une « usine à gaz » et pourtant, ça marche. J'aurais préféré que tu nous sortes les raisons des développeurs Fedora/RH pour ne pas vouloir implémenter cela plutôt qu'essayer de prétendre à l'inutilité d'une telle fonctionnalité.

Il faut comprendre que le support (logiciel comme matériel mais surtout logiciel) n'est pas qu'une assurance technique mais surtout une assurance financière. En clair, on établit un contrat avec l'entreprise qui fera le support d'un logiciel donné.
En cas de problèmes majeurs en production avec le dit logiciel, on ne fera pas forcément appel à toi car le temps vient généralement à manquer (en production) et que le contrat de support est justement là pour cela. On n'aura pas nécessairement le temps d'attendre que tu te documentes à coups de Google, en espérant que quelqu'un ait déjà eu le même problème (et l'ai publié après avoir trouvé une solution).
Tout cela fait beaucoup de si. Si le logiciel cause des pertes significatives de revenus à l'entreprise, les contrats prévoient généralement des pénalités en cas de non-résolutions. Ceci entraîne souvent une gestion intempestive des tickets (avec clôture très rapide).
Cependant, ce n'est pas le support professionnel le problème, c'est plutôt la rationnalisation des coûts des centres de support, qui entraînent ces dérives, en compétences et en gestion.

Je vais prêcher pour ma paroisse mais pour trouver un support plutôt compétent : http://www.08000linux.com/
J'admets le caractère publicitaire que cela peut avoir mais pour les avoir eu quelques fois en deux ans parce le client pour lequel je travaille a souscris une offre de support chez nous, je peux dire qu'ils sont compétents. Pour l'instant, il faut avouer que le centre de support est encore à visage humain et que les recrutements ne négligent pas les compétences. Simplement : un expert, ça coûte très cher à une entreprise spécialisée dans le support et je te laisse deviner ce que ça pèse dans la balance d'un gestionnaire financier.

Puis de toute façon, les juifs et les arabes descendent de Sem, ce sont des sémites, c'est normal de se chamailler entre frères et soeurs. :p
Mais, mais... cela signifierait dont qu'un arabe ne peut pas être anti-sémite ? ;-)

Pas plus qu'un non-fumeur avec une fumeuse, et pourtant...
Pourquoi se borner simplement à l'aspect religieux de la culture ?