informatique et high-tech (les meilleures news) %) - Page 665

(merci, j'suis paresseux )

!slap Folco :o
• squalyl slaps Folco :o around a bit with a large trout !

squalyl (./19920) :
plutôt http://www.debian.org/News/2013/20130504

Oui, mais ça ne génère pas de stats de popularité…

(Au passage, cliquez ici. )

l'annonce officielle:
l'espace de travail Plasma avec les applications KDE 4.8.4 ;

(et les autres paquetages sont tout aussi antiques)

plus de 36 000 autres paquets prêts à l'emploi

→

plus de 36 000 autres paquets obsolètes
prêts à l'emploi

fixed

Ah tiens Kevin, je vois que tu ne connais pas Debian. C'est pas grave, je vais t'expliquer. En fait, cette distribution vise à fournir des paquets stables et longuement testés, contrairement à d'autres qui prennent leur pied à pondre des logiciels en pré-alpha, voire même des environnements de bureau complets style GNOME 3 et KDE 4, dans un état complètement inutilisable, et présentant (même à l'heure actuelle) de grosses régressions par rapport à leur précédente version. C'est un choix. Ca s'appelle la qualité. Et contrairement à ce que certains pensent, un grand nombre de gens apprécient.

Bah, manque de chance, Wheezy contient justement GNOME 3 et KDE 4. Et leur GNOME 3.2 est certainement moins stable que le GNOME 3.6 de Fedora 18 ou le GNOME 3.8 qu'il y aura dans Fedora 19 dans environ un mois. Leur KDE est aussi 2 branches en retard par rapport à la version stable actuelle.

Peut-être qu'ils font des tests plus approfondis que ceux de ta distribution fétiche, ce qui entraîne immanquablement un certain retard ?

Peut-être aussi qu'ils ont trouvé des régressions/fonctionnalités instables dans les versions plus récentes et qu'ils considèrent que ce n'est pas acceptable ?

M'enfin, le jour où tu auras compris que tout le monde ne pense pas comme toi...

tiens en fait jviens de realiser qu'au taff on a un mec comme Kevin
des qu'une version d'une lib ou d'un soft devient "obsolete", il peut pas s'empecher de vouloir la mettre a jour direct. (meme si c'est la derniere des priorites pour les 6 prochains mois, parceque la version qu'on a est stable et nous suffit amplement)

generalement ca se traduit par un gros revert

genre visual 2012 tiens...
on avait des clients qu'utilisaient encore 2008 quand 2012 est sorti... ben paf il a essaye de migrer tout sur 2012... avant de s'appercevoir que certains trucs etaient pas encore supportes ("ho bah merde ya pas les sdk pour les consoles? ho ben c'est pas grave tfacons moi je teste que sous windows. ha les autres en ont besoin? pff mais c'est nul "), qu'il y avait des regressions dans le compilo, que ca generait du code plus lent, que...

bref

Visual est pourri quelle que soit la version, de toute façon.

Réponse tellement argumenté que #poubelle# direct

Pour ne donner qu'une raison: Le compilateur C de Visual C++ est déclaré obsolète et n'est pas mis à jour pour les nouvelles versions du standard C. Ils conseillent de tout compiler avec le compilateur C++, mais même pas mal de code C conforme C89/C90 n'est pas compilable en C++, et surtout les standards C++ ne contiennent qu'une petite partie des nouveaux standards C99 et C11 et Visual C++ n'implémente pas les nouveautés du C qui ne font pas partie du C++. En particulier, Visual C++ ne gère pas les tableaux de taille variable, problème qui est à la source de pas mal de buffer overflows dans des projets multiplateforme qui créent des problèmes de sécurité pour tout le monde (cf. par exemple le code des libti* où Romain a mis des char foo[100] plutôt que des char foo[strlen(bar)+42] parce que Visual C++ n'accepte pas ces derniers; du coup, le code plante si bar est trop long). GCC, lui, fait son possible pour implémenter le C99 même dans g++; en particulier, les tableaux de taille variable sont gérés.

Si tu met vraiment des trucs du genre char foo[strlen(bar)+42] dans ce que tu codes, y'a de quoi s'interroger sur la qualité de ton code…

(Et justement, Visual C++ c'est un compilateur C++ avant tout, donc ils implémentent les nouveautés C++ plutôt que les nouveautés C (ils ne s'en cachent pas))

Et c'est bien ce que je leur reproche. GCC implémente les nouveautés du C et du C++ (et de tous les autres langages qu'ils gèrent, par exemple du Fortran).

alors. vu que c'est parti d'un exemple de ce qu'on utilise a mon taff, j'en conclus que ton "visual c'est pourri" s'adressait a moi, donc, dans le cas de mon taff, ou on utilise visual (parceque c'est adapte a ce qu'on fait, pas parceque c'est "bien" ou "pas bien" ) (mais soit dit au passage, dans le cas aussi d'ENORMEMENT de boites qui ne sont pas des developpeurs dans leur garage ou des chercheurs qui n'ont aucune contrainte de vraies prods, chose qui t'es visiblement parfaitement inconnue Kevin) :
1-

Le compilateur C de Visual C++ est déclaré obsolète et n'est pas mis à jour pour les nouvelles versions du standard C

obsolète ??!!!!?!?!?!?!!!1 omfgwtfbbq /o\
=> on s'en branle.
2-

Ils conseillent de tout compiler avec le compilateur C++, mais même pas mal de code C conforme C89/C90 n'est pas compilable en C++

ca tombe bien, tout ce qu'on a a compiler c'est du C++
=> on s'en branle.
3-

et surtout les standards C++ ne contiennent qu'une petite partie des nouveaux standards C99 et C11

=>
4-

Visual C++ n'implémente pas les nouveautés du C qui ne font pas partie du C++

=>

5-

En particulier, Visual C++ ne gère pas les tableaux de taille variable, problème qui est à la source de pas mal de buffer overflows dans des projets multiplateforme qui créent des problèmes de sécurité pour tout le monde

seriously? jamais eu besoin de ca. c'est un alloca() cache, avec eventuellement un fallback sur un malloc. et c'est TRES BIEN qu'il ne permette pas ce genre de choses.
=> poubelle. on s'en branle. voire meme, c'est un point positif pour visual.
6-

(cf. par exemple le code des libti* où Romain a mis des char foo[100] plutôt que des char foo[strlen(bar)+42] parce que Visual C++ n'accepte pas ces derniers; du coup, le code plante si bar est trop long)

=> le code plante parcequ'il est mal code et qu'il n'y a aucun check. next.
7-

GCC, lui, fait son possible pour implémenter le C99 même dans g++; en particulier, les tableaux de taille variable sont gérés.

=> eh bien c'est tres bien, GCC aura un bon point.

tu m'aurais dit visual genere du code moins bon que GCC, j'aurais dit tres bon argument, et oui c'est vrai, dans certains cas. manque de bol ca ne fait pas tout non plus, meme si ca fait deja beaucoup plus que tous tes pseudo-arguments d'au dessus :/

(si tu veux je peux detailler pourquoi on s'en branle, mais ca me parait parfaitement inutile vu que de toutes facons t'en aura justement rien a branler )

(Du coup, avec ces bukkake, on comprend mieux pourquoi les smilies sont jaunes !)

Kevin Kofler (./19931) :
GCC, lui, fait son possible pour implémenter le C99 même dans g++; en particulier, les tableaux de taille variable sont gérés.

Et, meme si ça part d'un bon sentiment (meme si j'en doute) il a tord. On ne demande aps au cobol c'est compatible avec le python. Le C, et le C++ se ressemblent mais ne sont plus le meme language et vouloir coller des trucs de l'un a l'autre alors que ça ne fait pas partit du standard est un vrai problème.

Et il y a vraiment des gens qui codent en C11 ?

(oui, les nostalgeeks codent encore en C 1911 )

(il y a des choses bien du C99 qui n'ont toujours pas été intégré au C++x11)

Ximoon (./19937) :
Et il y a vraiment des gens qui codent en C11 ?

Pas encore, mais ça va venir. Le C99 est déjà utilisé, et c'est justement le refus de le gérer dans Visual C++ (14 années après son introduction!) qui retarde.

Mais au final, presque tout le monde utilise du C89, donc bon.

C'est l'histoire de la poule et de l'œuf.

Non, c'est l'histoire des gens qui veulent utiliser des technologies stables, validées et maîtrisées.

En tout cas, les projets qui n'ont rien à battre de Visual C++ utilisent déjà le C99 et sont contents de pouvoir l'utiliser.

Et au fait:

Ximoon (./19943) :
Non, c'est l'histoire des gens qui veulent utiliser des technologies stables, validées et maîtrisées.

donc pour toi, une technologie vielle "seulement" de 14 années n'est pas "stable, validée et maîtrisée"??? C'est vraiment n'importe quoi! Le standard C++ que tout le monde utilise n'a qu'une année de plus. Je ne vois pas pourquoi on resterait sur un standard C de 1989 (ANSI) ou 1990 (réédition ISO) pour l'éternité, voire sur du Fortran de 1977. Les standards évoluent!

Parce qu'ils sont suffisants pour l'utilisation qui en est faite ?

Tu sais, à l'échelle industrielle, des projets peuvent s'échelonner sur des dizaines d'années, et personne ne va s'amuser à tout porter d'un standard à l'autre en cours de route. Ensuite, vu que les générations suivantes s'appuient souvent sur ce qui existait avant, le bon sens commande de rester sur la technologie initiale, qui au final suffit très bien pour ce que l'on veut faire.

En tout cas, les projets qui n'ont rien à battre de C99 utilisent déjà Visual C++ et sont contents de pouvoir l'utiliser.

Ximoon (./19943) :
Non, c'est l'histoire des gens qui veulent utiliser des technologies stables, validées et maîtrisées.

Je pense sérieusement qu'on peux "oublier" le C89 est passer au C99, celui-ci apporte une réponse raisonnée à certains manques du C89, notamment au niveau du typage (<stdint.h>) qui peux permettre d'éviter pas mal de mauvaises surprises quand on passe d'un os en 32bit a un OS en 64bit... (j'en ai fait les frais récemment)

Je ne parle pas du C11 qui lui est bien sur trop jeune, c'est certain.

Le C99 n'apporte à ma connaissance aucune incompatibilités avec le C89 (contrairement au passage du C K&R vers le C89 par exemple) (et franchement <stdint.h> et l'affectation nommée dans les structures est vraiment utile)

KK> je viens de voir qu'après 14 ans d'existence, le support n'est pas parfait dans GCC... Selon Wikipedia en tout cas:

http://en.wikipedia.org/wiki/C99#Implementations

Mais en pratique, ça fonctionne, alors que Visual C++ est le seul compilateur dans toute la table qui n'a fait aucun effort ("No" sur fond rouge).