stopspam a écrit 695 commentaires

pour faire une analogie foireuse, c'est comme un malade atteint d'un cancer, l'allemagne voudrait qu'il se soigne pour aller mieux, mais les médicaments ont trop d'effet secondaire qui nuise au confort du patient.

Et si c'était un cancer du à 35 ans de tabagisme ? N'y a pas t'il pas une solution en amont : les états devraient retrouver leurs capacité à créer de la monnaie sans devoir emprunter aux banques.

En suivant cette logique jusqu'au bout, tu devrais même prendre un nightly build et redémarrer une fois par jour: on ne sait jamais, la correction a peut-être eu lieu dans une branche expérimentale sans que le correcteur réalise que c'est une faille de sécurité exploitable.

Belle caricature.

Il y a une vraie différence entre prendre la dernière release upstream et maintenir des patchs sécu sur une ancienne version. Surtout quand on est sûr de passer à côté. A mettre en parallèle avec le temps passer à maintenir ces patchs, je ne suis pas sûr que ça vaille le coup.

Ce genre d'actu remet régulièrement en cause le choix du mode de distribution : rolling release ou par version longue…

J'imagine les ressources nécessaires qu'il faut avoir pour de suivre les bugs, trous de sécu et les patcher sur une ancienne version. Mais quand l'upstream ne communique même pas alors ce travail ne sert tout simplement à rien !

Autant prendre la dernière version.

Je ne dis pas qu'aucun bug n'arrive jusqu'en prod mais qu'on ne debug pas direct sur la prod. La prod c'est un environnement contrôlé où on ne bricole pas avec ses gros doigts.
S'il y a un bug, on le qualifie, on trouve un scénario de reproduction. On fait un fix, on le livre, il est testé et on installe la build qui a été validée. Bref on essaie de rester dans un cadre maîtrisé.

en théorie, oui.

Après en fonction du type de bug, son impact, la pression de la hiérarchie, le temps nécessaire à synchroniser sur la test… il m'est déjà arrivé à debugger en prod. D'autant plus quand ça n'arrive que sur la prod.

Pas sûr… Un mot de passe alphabétique sera toujours plus facile à taper étant donné qu'on utilise la fonction première de chaque touche.

Pour les mots de passe chiadés, ça peste dans tous les coins du bureau : en allant vite les gens tapent mal un caractère spécial sur deux ($&@€…) et se loupent dans les majuscules. A part les dieux du code clavier.

La différence est subtile : le leader est reconnu par ses collègues alors que le manager est nommé par la hiérarchie. Mais c'est déjà détourné…

Et gtk encourage les devs python/gtk à utiliser PyGObject (https://live.gnome.org/PyGObject) !

Correction : gtk encourage les devs linux/python/gtk à utiliser PyGObject. Ils pissent juste sur ceux qui veulent vraiment faire une appli multiplateforme en éclipsant les 90% d'utilisateur windows.

Qui est une sacrée techno d'introspections et évite à devoir maintenir des bindings de oufs. J'irai même jusqu'à dire que gobject est une techno du futur ;-)

Tellement bien qu'au final ça ne fonctionne que sous linux.

Oui, pygtk est deprecated depuis un bail maintenant.

Et heureusement qu'il est encore là !

Il faudrait penser à le changer pour éviter les problèmes …

Encore pire, merci la méthode globale : j'avais lu en premier "Phonon" (Qt) et je ne voyais pas le rapport avec PHP…

Je me suis dis qu'il était plus facile d’enchaîner les -9 et -10 de suite. Mais visiblement tu n'es pas à la hauteur.

C'est la première fois que je vois autant de 9 et 10 les uns à la suite des autres ! Vivement demain !

je plusse, forcément !

Il parait que Bull à fait son entrée dans le capital de Red Hat. On connait la suite.

Allez, préparez vous à la déferlente de bullshit annuelle… On s'en passerait bien.

Tous les ans, je passes plusieurs heures à préparer mon poisson d'avril. C'est toujours un plaisir d'en avoir quelques uns.

A ce que je vois, legifrance est toujours aussi simple d'utilisation…

la défection des utilisateurs n'a rien changé au projet ni au code, car ces départ n'ont pas d'effet sur le code produit ( vu qu'il y a toujours globalement autant de contributeur).

Les chiffres… Hors contexte, tu ne peux pas tirer de conclusion juste à partir d'un nombre constant de contributeurs. Quand la plupart des autres projets du même type gagnent des contributeurs, stagner n'est pas bon signe.

Ça coupe surtout la chique à tous ceux qui rabâchent que ce sont les développeurs qui commandent et que les utilisateurs n'ont qu'à s'écraser (et il y a des amateurs sur linuxfr).

Je suis d'accord à une condition : lorsque le développeur est le premier utilisateur, il le fait pour lui et se fou des autres. Dans le cas de Gnome, les dev ont eu juste envie de faire DE pour tablette et non pour PC. Résultats : ils se sont bien ramassés et ceux qui ont migrés vers les fork de gnome2 ou XFCE apprécient.

Pour être vraiment kikoo lol, il ne manque le binding JS (langage du moment) et une barre pour les réseaux sociaux parce qu'on ne peut pas travailler sans (c'est bien connu).

Je m'interroge également sur les motivations de Canonical, qui, à l'image d'autres géants du secteur, entrevoyant l’énorme potentiel du marché chinois, pourrait se mettre au service du gouvernement chinois dans l'espoir d'augmenter considérablement sa base d'utilisateurs.

Tu es encore bien innocent.

Le lecteur PDF en JS, flash en JS. C'est quoi la suite ?

1. Supprimer le système d'exploitation qui ne sert à rien et qui en plus multitâches (les utilisateurs sont trop bêtes pour en profiter pleinement)
2. Le remplacer par un navigateur qui ne fait qu'une seule chose à la fois (bonus supplémentaire si utilise Modern UI)
3. N'utiliser que du javascript (parce qu'en gros on ne supporte porte que ça)
4. Balancer de la pub et des DRM (parce que bon hein, c'est bien beau de vouloir faire du libre mais si on reste dans notre coin à pas les prendre en charge, google ne signera pas notre chèque à la fin du mois renouvellera pas notre contrat)

Y'a pas à dire, ils ont du taf chez mozilla.

Je dirais qu'il y a 2 types de langages :

1. Ceux qu'on utilise parce qu'ils répondent bien à un besoin (C, python, Java, C#)
2. Les jouets avec lesquels on se force à faire des applications pour montrer que ça sert (OCalm, Haskell, Scheme…)

J'aime bien ta définition et si j'y réfléchis, c'est que je fais au niveau de mes projets.

L'un est corruptible

Non les 2 le sont ! Et dans les 2 cas, ce qu'il faut regarder c'est l'avantage obtenu. Une boîte de chocolat ou une bouteille de champagne ne poseront pas de gros problèmes. Au dessus d'une certaine somme d'argent (50 ? 100 ?) c'est déjà nettement plus louche !

Malheureusement partager la même Session est à double tranchant :

• tu gagnes en écriture
• tu perds en fonctionnalité : adieu les Threads.

Je ne suis pas un fan de microsoft mais je leur reconnais un très bon soft s'agissant de SQL Server.

J'ai clairement appris à utiliser une base de données comme il faut avec. Avant, je ne m'étais jamais vraiment posé la question des vues, prodécures, triggers, jobs…

D'abord en grosse partie parce que le client (Management Studio) explose n'importe quel autre, le meilleur pour un débutant. Seul celui de PostGreSQL peut tenir la comparaison. Ensuite lorsqu'on requête, on comprend vraiment certaines aberrations de mysql.

J'ai du ensuite me mettre à oracle pour les besoins d'une grosse appli RH. On monte encore dans l'apprentissage du SQL. Au passage les fonctions de conversion de type sont magiques comparées au convert() casse-couille de microsoft avec les dates.

Tout ça pour dire que mysql est le dernier choix quand tu achètes une appli et le premier pour du web. Le positionner comme un concurrent d'Oracle est une grosse blague : techniquement et ensuite parce que le segment de marché n'est pas le même.

Ici, nous allons parler du vrai concurrent d'Oracle

LE vrai concurrent d'Oracle c'est SQL Server. Les autres n'ont pas encore ce titre.