Antoine a écrit 5722 commentaires

L'ignorance des consommateurs est la raison majeure pour laquelle les produits qu'on achète sont fermés, obsolètes rapidement, et liberticides : ils ne voient pas l'intérêt de les modifier ou de les bricoler.

Eh bien, je ne savais pas que savoir programmer rendait expert en voitures ou en machines à laver.

Quant à l'idée que les programmeurs soient majoritairement attachés aux libertés informatiques, heu… faudra sortir de son petit cocon libriste un jour. La plupart des informaticiens professionnels sont des pisseurs de code qui s'en tapent le coquillard du libre, des standards ouverts, etc.

Je crois surtout qu'il y a pas mal de commentateurs qui programment de temps en temps, et "ont le temps".

Le temps, ça se prend, que ce soit pour les tests unitaires ou la gestion d'erreur. Mais bon, c'est sûr que c'est pas l'idéal si le but est de finir mentionné dans http://thedailywtf.com/

Le problème de cette approche prototype, c'est qu'il ait de grand risque que la phase de mise au propre passe par une réécriture complète.

Surtout, l'expérience enseigne qu'un « prototype » finit bien souvent utilisé en production, parce que tout recoder est une perte de temps quand on a un truc qui marche.

UTF-8 devient peu à peu le standard universel, oui (tu peux toujours coder en EBCDIC ou en CP1252 ou en UTF-16BE si ça t'amuse).

C'est une horreur à parser parce que c'est non-standardisé. Mais il n'y a pas de raison pour laquelle le standard (imposé par systemd) devrait être binaire (opaque) plutôt que textuel (lisible). L'IETF se débrouille très bien avec du texte.

Moi ça m'énerve à chaque fois que j'entends parler d'une souris informatique. Une souris c'est un rongeur qui mange du fromage, ou bien c'est un morceau de la patte arrière de l'agneau. Il n'y a rien de tel ici.

C'est réel, la vraie vie, que le courant te lâche plus souvent qu'un malloc à NULL.

Dans ma vraie vie à moi, j'ai plus souvent vu des échecs d'allocation mémoire que des coupures de courant.
(et pourtant je te parle de mon chez moi domestique sans onduleur ; pour un serveur dans un datacenter c'est probablement encore plus flagrant)

Mais que vient faire la limite de mémoire ici???

ON NE PARLE PAS DE FUITE MEMOIRE.

Ben si. Si realloc ou malloc échoue, il y a de fortes chances que ce soit dû à une fuite mémoire qui a épuisé la mémoire disponible.
(l'autre cas courant étant l'erreur de programmation)

Si Apple demande la suppression de toutes les critiques ou discussions sur l'éthique sur elle "car l'entreprise sait bien mieux que les autres ce qu'elle fait et elle est éthique", tu trouveras ça normal?

Tu compares des poireaux et des carottes. L'affirmation d'origine n'est pas une remise en cause de la probité ou de la morale de l'auteur, elle est juste factuellement fausse.

on peut aussi citer plein de personnes dans le "négationnisme"

Gaffe au Godwin qui approche à grands pas. Je te suggère la pédophilie comme sujet de remplacement avec lequel construire des arguments à l'emporte-pièce.

L'auteur, c'est justement une des personnes qu'il faut le moins écouter.

C'est un peu comme si tu disais « les témoins, c'est les personnes qu'il faut le moins écouter » s'agissant d'un accident. Au contraire, l'auteur est tout de même bien placé pour parler de son processus de création et de ce qu'il avait en tête en réalisant son oeuvre (bien mieux qu'un critique qui va essayer de lire des influences et des allusions dans le marc de café ; je rappelle en passant que la critique littéraire n'est pas vraiment une discipline scientifique : n'importe qui peut y raconter n'importe quoi, de façon assez peu réfutable).

Surtout que pour les jeux video, il y a des tas d'autres sources plus commodes que Wikipédia.

Bienvenue sur Internet.

Euh tu parles encore de linux 1? Parceque ca fait longtemps que linux est modulaire.

ça n'en fait pas moin un noyau monolithique

Inventons un nouveau mot : modulithique.

Je suis un développeur expérimenté

J'aime ce genre d'affirmation qui dans l'absolue ne veulent absolument rien dire…

Je suis d'accord, ç'aurait été mieux avec « je suis Senior J2EE Architect ».

Et les noms des provides sont plus normalisés que les noms de paquets ?

Tout à fait, le problème ici étant probablement l'overcommit (le programme ne peut rien faire pour détecter le problème). N'empêche que ça marche tout de même dans pas mal de cas.

Puisque tout le monde ici à l'air super au point sur comment faire ça plus elegamment qu'avec un assert, j'imagine que ces programmes sont très nombreux.

Nombreux je ne sais pas, mais un langage haut niveau (implémenté en C, donc ce n'est pas hors sujet) peut lever une exception :

>>> b"x" * (2**48)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError

Voilà la raison pour laquelle vérifier le retour de malloc() et realloc() est en général assez peu utile

Sous Linux peut-être, mais pas quand on écrit du C portable.

Tu es fou, donner trop d'informations à l'utilisateur risque de perdre le pauvre utilisateur.
(mais peut-être que si tu proposes d'afficher l'explication en appuyant sur Alt, la feature request sera acceptée)

J'éspère que tu dis la même chose à Linus T. quand il n'a rien à foutre de tout casser dans l'ABI qui n'est pas sensée être utilisée mais que tu utilises quand même, et ce plus souvent que tous les 2 ans.

Non, parce que Linus T., lui, ne fait pas chier l'userspace. Et je ne suis pas développeur noyau.

Et dans l'exemple donné, il suffit de se limiter autant que sous Linux

Je vois que tu retournes ta veste. Ce n'est pas toi qui expliquais que Windows était mieux grâce à son ABI stable ? Finalement tu acceptes l'idée que les limitations de Windows sont les mêmes que celles de Linux. CQFD.

Je compile avec libc.so.0 en link, tu compiles avec libc.so.5 en link, les deux libc seront en mémoire.

Heu j'aimerais voir à quelle fréquence change le numéro de version majeur de la libc. Pour rappel, msvcrt change d'ABI environ tous les deux ans (à chaque nouveau MSVC). Ça poserait moins de problèmes si c'était beaucoup plus espacé.

Met la même contraintes que tu fais sous Linux (=tout le monde doit utiliser la même libc, c'est un ordre)

Ah ben, c'est ce qu'on fait : pour Python 3.3 par exemple, on dit "vous devez utiliser Visual Studio 2010 pour compiler vos extensions" (pour Python 2.7 et 3.2, c'était Visual Studio 2008). Mais, justement, c'est loin du discours idéal sur les ABI-qui-ne-changent-jamais.

Windows ne me semble pas en faute.

Je ne sais pas qui exactement fournit msvcrt (Windows ou MSVC ?) mais, bon, on parle bien de l'écosystème Windows et de ses briques fondamentales fournies par Microsoft. Il y a beaucoup d'applications qui utilisent le CRT (notamment, bien sûr, la plupart des applications portables).

Du coup, le problème me semble être un truc du genre on évite de passer des pointeurs de trucs internes à des compilos

On évite si on peut. FILE a l'avantage de fournir une gestion bufferisée des fichiers, ce qu'un fd ou un handle ne font pas. Après on peut tout réécrire à la main, mais ce n'est pas une entreprise triviale…

Au final, l'avantage du libre est qu'on peut tout recompiler et utiliser la même version de libc, mais ton Unix n’échapperai pas au problème (ça dépend du compilo).

Si, si, il y échapperait, pour la raison que j'ai donnée plus haut : sur Unix, toutes les bibliothèques chargées dans un processus partagent la même libc (quelle que soit la version existante lors de la compilation). Donc il n'y a pas de problème de FILE * pointant vers des structures incompatibles, par exemple.

Sous Windows, lorsque des bibliothèques ont été compilées avec des msvcrt différents, elles chargent également des copies de différents msvcrt au sein du même processus. D'où le clash quand ces bibliothèques s'échangent ensuite des pointeurs entre elles.

tu es sûr que si je file un FILE* venant de libc.so.5, ça passera sans broncher vers libc.so.0?

La question est sans objet, puisque cette situation ne se produira pas (tu auras une seule libc chargée dans le processus).

Stricto sensu, ça ne la fait pas varier en effet, mais le résultat est le même. Note que ce n'est pas seulement errno: la structure FILE change, donc si une bibliothèque dynamique compilée avec MSVC X passe un FILE* à une bibliothèque dynamique compilée avec MSVC Y, ça casse (*). Ceci parce que chaque bibliothèque dynamique utilisera un msvcrt différent.

Avec les bibliothèques partagées de type Unix, il n'y a pas ce problème, car toutes les bibliothèques chargées dans un processus partagent la même libc : les pointeurs sont naturellement compatibles.

((*) il y a peut-être d'autres cas similaires, mais FILE est le plus visible et le plus gênant ici)

C'est pas si simple que ça. L'API est préservée, mais l'ABI subit des variations subtiles : http://mail.python.org/pipermail/python-dev/2012-August/121460.html

(pour ceux qui ont la flemme de cliquer sur le lien : si on compile un Python avec MSVC version N, les extensions compilées avec la version N-1 ou N+1 peuvent ne pas fonctionner correctement ; ce qui est plutôt gênant car un nouveau MSVC sort environ tous les 2 ans)

Tu imagines un téléphone sans clavier rétroéclairé? Ben c'est pareil avec un ordi.

Je vois pas pourquoi c'est pareil. On peut avoir besoin de se servir d'un téléphone dans une ruelle mal éclairé, un coin de pénombre… Un ordi, je vois pas.

Genre, tu matte un film, sans lumière, et que tu veux checker tes mails rapidement, pas besoin d'allumer la lumière

Et je m'explose les yeux à regarder une GUI dans le noir. Youpi.

le jour tombe, pas besoin de te lever pour allumer tout de suite

Oui, vaut mieux se ré-exploser les yeux.

Quand on écrit qu'un commentaire est "insultant, nauséabond ou illégal", c'est qu'on sous-entend assez fortement qu'il doit être modéré (ou bien qu'on veut déplacer l'hébergement de Linuxfr sur Freenet).

Note que je n'ai rien contre la modération, mais faut assumer.