Ici le code est écrit et commenté en anglais, mais tout le reste (réunions, documentation, …) est en français. Toute l'équipe est en France et parle très bien le français, je ne sais pas pourquoi il y a des morceaux en anglais. Le bugtracker et le wiki sont un mélange des deux selon l'humeur (avec certains tickets dont le titre est en français et la description en anglais, ou l'inverse). Pareil pour les description des changements dans l'outil de suivi de version. Pas besoin d'anglais parlé pour le travail.
La conséquence la plus pénible: on doit faire 2 fois, en anglais et en francçais, l'effort de nommer les concepts qu'on manipule. L'avantage: on a 2 fois plus de vocabulaire pour réfléchir et s'exprimer précisément. Parfois on a besoin de néologismes (je pense à "plurividuel" qui nous a servi une ou deux fois).
J'ai appris l'anglais en contribuant à un logiciel libre principalement développé par des allemands à l'époque. Donc surtout à l'écrit (IRC, mail) et rarement à l'oral (une semaine par an en gros). J'ai donc un accent tout pourri mais y'a que les français qui me font des reproches là-dessus.
Mon principal regret: à force d'utiliser l'anglais j'ai de plus en plus de mal à parler ou écrire l'espagnol (que je comprends par contre toujours bien).
Possible que Epiphany, et tous les navigateurs basés sur WebKit soit marqués "Safari" aussi (en tout cas c'est le cas pour le navigateur de Haiku, on est obligés sinon on se retrouve avec la version mobile de certains sites :()
Les entreprises qui contribuent au libre, c'est pas forcément en payant des dévelopeurs et en faisant des outils gratuits. Par exemple en tant que contributeur d'un projet qui participe presque tous les ans au Google Summer of Code et au Google Code-In, je connaît assez bien l'équipe "Open Source Program Office" de Google, qui a pour objectif de promouvoir le logiciel libre, à la fois en interne (pour aider l'équipe Android à publier leurs sources, par exemple), et en externe (avec les deux programmes que je viens de mentionner, mais ils sont ouverts aux suggestions pour faire encore d'autres choses).
Donc, ça n'est pas forcément visible par tout le monde, et ça occupe peut-être une dizaine de personnes, autant dire pas grand chose chez Google. L'entreprise me semble trop grande pour pouvoir dire si j'aimerais travailler chez eux. ça dépend dans quel service et pour quoi faire.
On pourra dire que c'est du "librewashing", mais en tout cas l'équipe qui s'en occupe fait en sorte que ça soit constructif et efficace.
C'est un peu différent, Apple n'avait pas de problème avec la GPL2 mais par contre ils n'ont pas voulu suivre quand GCC est passé sous GPL3. Du coup, ils sont restés longtemps avec une vieille version de GCC dont ils ont assuré eux-même la maintenance, avant de passer à llvm/clang.
Ici il n'y a pas ce problème, puisque le projet restait sous GPL2.
J'ai travaillé pendant un an à plein temps pour le projet Haiku, que je ne pense pas être un très gros projet. J'ai été financé par les dons (ponctuels ou récurrents) de particuliers et d'entreprises, via l'association Haiku, inc qui gère le budget du projet. C'est donc possible de faire ce genre de chose.
Cependant, cela n'a duré qu'un an. Les raisons pour lesquelles cela n'a pas continué sont multiples. D'une part, l'association Haiku n'avait pas tout à fait assez de revenus pour continuer à financer ce projet. Cela aurait pu s'arranger, mais je n'ai pas souhaité prendre ce risque et préféré reprendre un travail salarié "normal", pour le moment en tout cas.
Cela dit, ce modèle fonctionne plutôt bien pour Haiku, mais pas en France. On a plusieurs développeurs en Allemagne qui sont freelancers, et qui travaillent sur des missions dans différentes entreprises en fonction des besoins. Ils peuvent donc facilement intercaler des périodes de travail dans une entreprise qui paie bien, et des périodes où ils travaillent pour Haiku, avec une rémunération beaucoup moins avantageuse mais suffisante pour payer le loyer et s'acheter à manger. Ce qui permet au moins de trouver un équilibre, en attendant mieux.
J'espère que le projet sera un jour un peu plus populaire et récoltera suffisamment de dons pour pouvoir financer un développeur à plein temps (ou à temps partiel, pourquoi pas après tout?). Mais on sera encore loin de pouvoir financer toute l'équipe.
Merci à tous ceux qui donnent du temps ou de l'argent au libre, en tout cas :).
Il y a bien eu l'ajout d'une IA dans cette version Linux qui n'existait pas pour la version DOS. Donc ça montre bien qu'il est possible de faire évoluer ce code pour y ajouter des fonctionnalités.
Sur les assembleurs modernes, on peut définir des labels locaux, en général avec un préfixe ou un suffixe dédié (par exemple un . ou un $). La portée est entre deux labels globaux. Du coup, toutes les boucles peuvent s'appeler ".loop" ou quelque chose de ce genre.
ça permet aussi de migrer des morceaux du code vers du C "propre" petit à petit. C'est possible de mélanger le C et l'assembleur aussi, mais pas forcément évident surtout si c'est de l'assembleur écrit pour MS-DOS (avec accès direct à la RAM vidéo, tout ça).
Toi tu n'as jamais essayé de programmer une Atari 2600. Ce n'était certainement pas du BASIC, en tout cas.
La console n'a pas assez de RAM pour un frame buffer, donc il faut générer à la volée, ligne par ligne, ce qui s'affiche à l'écran pendant que la télévision balaye ce dernier. TOUT le code doit donc être écrit en tenant compte de ces timings.
Le jeu ET est plutôt bien conçu, mais trop ambitieux pour la console et les moyens de l'époque, ce qui le rend difficile à comprendre (graphismes peu lisibles à cause de la faible résolution des images) et à jouer (maniabilité pas terrible).
En tout cas, ce n'est pas un jeu développé "à l'arrache" sur un coin de table. Même si le résultat n'est pas franchement convaincant, c'était déjà pas facile d'en arriver jusque là étant donné les contraintes.
"No Superuser, No System Administration – There was no intention to specify all aspects of an operating system. System administration facilities and functions are excluded from this standard, and functions usable only by the superuser have not been included. Still, an implementation of the standard interface may also implement features not in POSIX.1-2008. POSIX.1-2008 is also not concerned with hardware constraints or system maintenance."
La version actuelle de POSIX a donc supprimé la notion de super-utilisateur (il en reste quelques traces, cependant), ainsi que toutes les commandes liées à l'administration système. Pas de "su", pas de "chroot", par exemple.
Donc, la présence ou l'absence d'un utilisateur root n'est pas liée à POSIX. Peut-être aux systèmes "UNIX-like", éventuellement.
Même aujourd'hui, il y a toujours une "guerre" de performances entre C et Fortran qui pousse à garder ces possibilités d'optimisation. C'est comme ça que C99 a ajouté le "strict aliasing", les "restrict" sur les pointeurs, et quelques autres trucs qui permettaient à Fortran d'aller plus vite que le C à l'époque.
ça n'empêche pas de le réécrire, en fait. Mais ça permet déjà d'avoir un code fonctionnel, à partir duquel on peut réécrire les choses petit à petit.
Parce que réécrire du code assembleur en C et le porter de DOS vers SDL en même temps et sans pouvoir tester tant que tout n'est pas fini, c'est pas forcément évident.
Je demande à voir quelle serait l'erreur levée. Comme c'est indiqué dans le premier commentaire sur reddit, ce code a un cas d'exécution valide, si NeverCalled est appelé (ce qui est possible, puisque cette fonction n'est pas statique) avant main() (ce qui est possible, par exemple en C++ en initialisant un objet statc/global).
Le compilateur optimise ce cas valide, et a le droit d'ignorer l'autre cas (celui ou le pointeur est NULL et donc le comportement indéfini). Lui faire faire la même chose que l'autre cas, c'est un choix raisonable.
Ceux qui trouvent ça inacceptable, il faut changer de langage comme ça a été dit plein de fois au-dessus. Et accepter d'avoir du code un peu moins performant mais beaucoup plus sûr.
Il y a déjà eu quelques corrections dans C99, par exemple, sur le comportement de l'opérateur % avec des opérandes négatifs (c'est juste un exemple, il y en a probablement d'autres dans C99 et C11).
Mais le C reste un langage bas niveau et qui tient compte des possibilités de très nombreuses architectures, notament des trucs franchement euh… "créatifs" pour certains systèmes embarqués: bytes qui ne font pas 8 bits (avec CHAR_BITS), mémoire adressée par segment:offset comme sur les 386, architectures ou l'espace mémoire est découpé en une partie pour le code et l'autre pour les données (AVR8, par exemple). Le tout en préférant toujours l'approche qui donnera les meilleures performances quitte à avoir un comportement indéfini, ou au mieux, défini par l'implémentation (là au moins on sait ce qu'il se passe pour un compilateur donné).
Je ne pense pas que le langage se prête bien à l'écriture de code sur et sans comportements indéfinis. Donc oui, à mon avis, il serait mieux de changer de langage, même si cela demandera beaucoup d'efforts.
Ce qui m'inquiète là dedans, c'est pas forcément qu'il y aie une limite. C'est plutôt les langages où ça finit par faire une erreur de segmentation ou un autre truc du genre. Résultat, n'importe qui peut faire planter ton API REST en envoyant une requête de 27Ko (c'est à dire pas grand chose).
S'il y a juste une exception et qu'elle peut être interceptée et testée par l'applicatif, je pense que ça n'est pas vraiment un problème à condition que ce soit documenté et que les applications qui en ont besoin (pour des raisons de sécurité et de continuité de service, pas parce qu'elles ont vraiment besoin de parser des très gros fichiers JSON avec 100 niveaux d'imbrication) puissent réagir en conséquence.
# Travail bilingue
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 3.
Ici le code est écrit et commenté en anglais, mais tout le reste (réunions, documentation, …) est en français. Toute l'équipe est en France et parle très bien le français, je ne sais pas pourquoi il y a des morceaux en anglais. Le bugtracker et le wiki sont un mélange des deux selon l'humeur (avec certains tickets dont le titre est en français et la description en anglais, ou l'inverse). Pareil pour les description des changements dans l'outil de suivi de version. Pas besoin d'anglais parlé pour le travail.
La conséquence la plus pénible: on doit faire 2 fois, en anglais et en francçais, l'effort de nommer les concepts qu'on manipule. L'avantage: on a 2 fois plus de vocabulaire pour réfléchir et s'exprimer précisément. Parfois on a besoin de néologismes (je pense à "plurividuel" qui nous a servi une ou deux fois).
J'ai appris l'anglais en contribuant à un logiciel libre principalement développé par des allemands à l'époque. Donc surtout à l'écrit (IRC, mail) et rarement à l'oral (une semaine par an en gros). J'ai donc un accent tout pourri mais y'a que les français qui me font des reproches là-dessus.
Mon principal regret: à force d'utiliser l'anglais j'ai de plus en plus de mal à parler ou écrire l'espagnol (que je comprends par contre toujours bien).
[^] # Re: Je pense que tu va pas aimer mes réponses
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 10.
ça s'appellerait pas une audioconférence?
[^] # Re: Mes stats (donc 0% pertinent)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal part de marché Linux ?. Évalué à 3.
Possible que Epiphany, et tous les navigateurs basés sur WebKit soit marqués "Safari" aussi (en tout cas c'est le cas pour le navigateur de Haiku, on est obligés sinon on se retrouve avec la version mobile de certains sites :()
[^] # Re: Et les poles open-source de ces entreprises ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Travailler pour les GAFAM. Évalué à 6.
Les entreprises qui contribuent au libre, c'est pas forcément en payant des dévelopeurs et en faisant des outils gratuits. Par exemple en tant que contributeur d'un projet qui participe presque tous les ans au Google Summer of Code et au Google Code-In, je connaît assez bien l'équipe "Open Source Program Office" de Google, qui a pour objectif de promouvoir le logiciel libre, à la fois en interne (pour aider l'équipe Android à publier leurs sources, par exemple), et en externe (avec les deux programmes que je viens de mentionner, mais ils sont ouverts aux suggestions pour faire encore d'autres choses).
Donc, ça n'est pas forcément visible par tout le monde, et ça occupe peut-être une dizaine de personnes, autant dire pas grand chose chez Google. L'entreprise me semble trop grande pour pouvoir dire si j'aimerais travailler chez eux. ça dépend dans quel service et pour quoi faire.
On pourra dire que c'est du "librewashing", mais en tout cas l'équipe qui s'en occupe fait en sorte que ça soit constructif et efficace.
Il y a d'autres choses dans le même genre dans d'autres domaines, par exemple: https://makingscience.withgoogle.com/?lang=fr
[^] # Re: C’est toujours mieux qu’un open-bar.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et ca continue encore et encore ... avec la pomme ... la grande rigolade. Évalué à 9.
Moi je vois une pointe d'ironie là au début du journal quand même…
# Combien d'usagers?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal part de marché Linux ?. Évalué à 10.
21%, si tu as 5 visiteurs y compris toi-même, c'est peut être normal?
[^] # Re: Aigreur, quand tu nous tiens
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ils l'ont voulu, ils l'ont obtenu, et ils l'ont dans le baba.... Évalué à 3.
Supprimons les horaires! Comme ça, plus de problèmes de retard!
[^] # Re: alerte?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Apple change la licence de CUPS. Évalué à 2.
C'est un peu différent, Apple n'avait pas de problème avec la GPL2 mais par contre ils n'ont pas voulu suivre quand GCC est passé sous GPL3. Du coup, ils sont restés longtemps avec une vieille version de GCC dont ils ont assuré eux-même la maintenance, avant de passer à llvm/clang.
Ici il n'y a pas ce problème, puisque le projet restait sous GPL2.
[^] # Re: Qui viendra ??
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Capitole du Libre 2017 : programme des festivités des 18 et 19 novembre. Évalué à 2.
Présent! Sur le stand de Haiku et la conférence qui va avec.
[^] # Re: Modèle économique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gratipay ferme ; l'avenir du financement du libre. Évalué à 3.
C'est un peu ce que fait le Software Freedom Conservancy, non?
https://sfconservancy.org
[^] # Re: Modèle économique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gratipay ferme ; l'avenir du financement du libre. Évalué à 10.
J'ai travaillé pendant un an à plein temps pour le projet Haiku, que je ne pense pas être un très gros projet. J'ai été financé par les dons (ponctuels ou récurrents) de particuliers et d'entreprises, via l'association Haiku, inc qui gère le budget du projet. C'est donc possible de faire ce genre de chose.
Cependant, cela n'a duré qu'un an. Les raisons pour lesquelles cela n'a pas continué sont multiples. D'une part, l'association Haiku n'avait pas tout à fait assez de revenus pour continuer à financer ce projet. Cela aurait pu s'arranger, mais je n'ai pas souhaité prendre ce risque et préféré reprendre un travail salarié "normal", pour le moment en tout cas.
Cela dit, ce modèle fonctionne plutôt bien pour Haiku, mais pas en France. On a plusieurs développeurs en Allemagne qui sont freelancers, et qui travaillent sur des missions dans différentes entreprises en fonction des besoins. Ils peuvent donc facilement intercaler des périodes de travail dans une entreprise qui paie bien, et des périodes où ils travaillent pour Haiku, avec une rémunération beaucoup moins avantageuse mais suffisante pour payer le loyer et s'acheter à manger. Ce qui permet au moins de trouver un équilibre, en attendant mieux.
J'espère que le projet sera un jour un peu plus populaire et récoltera suffisamment de dons pour pouvoir financer un développeur à plein temps (ou à temps partiel, pourquoi pas après tout?). Mais on sera encore loin de pouvoir financer toute l'équipe.
Merci à tous ceux qui donnent du temps ou de l'argent au libre, en tout cas :).
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
Y'avait pas eu une campagne pour Plee the Bear il y a quelques années?
# Multitalk
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal BEd : un éditeur graphique pour Beamer (présentations LaTeX). Évalué à 4.
Un concurrent qui n'utilise pas Beamer:
https://github.com/JohannesBuchner/multitalk
Peut-être quelques idées à récupérer dedans :)
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 1.
Il y a bien eu l'ajout d'une IA dans cette version Linux qui n'existait pas pour la version DOS. Donc ça montre bien qu'il est possible de faire évoluer ce code pour y ajouter des fonctionnalités.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
Puisqu'on parle de #balancetonporc et de Rust, pour les dénonciations ça se passe ici:
https://github.com/ansuz/RIIR
https://transitiontech.ca/random/RIIR
[^] # Re: Processus de conversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Sur les assembleurs modernes, on peut définir des labels locaux, en général avec un préfixe ou un suffixe dédié (par exemple un . ou un $). La portée est entre deux labels globaux. Du coup, toutes les boucles peuvent s'appeler ".loop" ou quelque chose de ce genre.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
ça permet aussi de migrer des morceaux du code vers du C "propre" petit à petit. C'est possible de mélanger le C et l'assembleur aussi, mais pas forcément évident surtout si c'est de l'assembleur écrit pour MS-DOS (avec accès direct à la RAM vidéo, tout ça).
Le temps de la https://www.svgalib.org est révolu!
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Toi tu n'as jamais essayé de programmer une Atari 2600. Ce n'était certainement pas du BASIC, en tout cas.
La console n'a pas assez de RAM pour un frame buffer, donc il faut générer à la volée, ligne par ligne, ce qui s'affiche à l'écran pendant que la télévision balaye ce dernier. TOUT le code doit donc être écrit en tenant compte de ces timings.
Le jeu ET est plutôt bien conçu, mais trop ambitieux pour la console et les moyens de l'époque, ce qui le rend difficile à comprendre (graphismes peu lisibles à cause de la faible résolution des images) et à jouer (maniabilité pas terrible).
En tout cas, ce n'est pas un jeu développé "à l'arrache" sur un coin de table. Même si le résultat n'est pas franchement convaincant, c'était déjà pas facile d'en arriver jusque là étant donné les contraintes.
Oh et pour la musique chiptune faite "à la main": https://www.linusakesson.net/hardware/chiptune.php
[^] # Re: Droit root, petite nuance
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche F-Droid 1.0 est sorti. Évalué à 3.
Dans la specification POSIX (http://pubs.opengroup.org/onlinepubs/9699919799/) je n'ai trouvé que ceci à propos d'un utilisateur "root":
"No Superuser, No System Administration – There was no intention to specify all aspects of an operating system. System administration facilities and functions are excluded from this standard, and functions usable only by the superuser have not been included. Still, an implementation of the standard interface may also implement features not in POSIX.1-2008. POSIX.1-2008 is also not concerned with hardware constraints or system maintenance."
La version actuelle de POSIX a donc supprimé la notion de super-utilisateur (il en reste quelques traces, cependant), ainsi que toutes les commandes liées à l'administration système. Pas de "su", pas de "chroot", par exemple.
Donc, la présence ou l'absence d'un utilisateur root n'est pas liée à POSIX. Peut-être aux systèmes "UNIX-like", éventuellement.
[^] # Re: Comportement attendu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compilateur trop intelligent. Évalué à 4.
Même aujourd'hui, il y a toujours une "guerre" de performances entre C et Fortran qui pousse à garder ces possibilités d'optimisation. C'est comme ça que C99 a ajouté le "strict aliasing", les "restrict" sur les pointeurs, et quelques autres trucs qui permettaient à Fortran d'aller plus vite que le C à l'époque.
[^] # Re: Processus de conversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 10.
ça n'empêche pas de le réécrire, en fait. Mais ça permet déjà d'avoir un code fonctionnel, à partir duquel on peut réécrire les choses petit à petit.
Parce que réécrire du code assembleur en C et le porter de DOS vers SDL en même temps et sans pouvoir tester tant que tout n'est pas fini, c'est pas forcément évident.
[^] # Re: Erreur?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compilateur trop intelligent. Évalué à 1.
Je demande à voir quelle serait l'erreur levée. Comme c'est indiqué dans le premier commentaire sur reddit, ce code a un cas d'exécution valide, si NeverCalled est appelé (ce qui est possible, puisque cette fonction n'est pas statique) avant main() (ce qui est possible, par exemple en C++ en initialisant un objet statc/global).
Le compilateur optimise ce cas valide, et a le droit d'ignorer l'autre cas (celui ou le pointeur est NULL et donc le comportement indéfini). Lui faire faire la même chose que l'autre cas, c'est un choix raisonable.
Ceux qui trouvent ça inacceptable, il faut changer de langage comme ça a été dit plein de fois au-dessus. Et accepter d'avoir du code un peu moins performant mais beaucoup plus sûr.
# Beaver Debugger
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal CGDB 0.7.0 est sorti... il y a plusieurs mois :S. Évalué à 2.
Il y avait ça qui marchait pas mal:
http://pasnox.tuxfamily.org/project/beaverdbg
L'idée était de prendre la partie "debugger" de Qt Creator sans la partie IDE. Mais je ne crois pas que ça soit tenu à jour :(
[^] # Re: Existe-t-il des compilateurs C/C++ qui donnent une sémantique à tous les programmes ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compilateur trop intelligent. Évalué à 5.
Il y a déjà eu quelques corrections dans C99, par exemple, sur le comportement de l'opérateur % avec des opérandes négatifs (c'est juste un exemple, il y en a probablement d'autres dans C99 et C11).
Mais le C reste un langage bas niveau et qui tient compte des possibilités de très nombreuses architectures, notament des trucs franchement euh… "créatifs" pour certains systèmes embarqués: bytes qui ne font pas 8 bits (avec CHAR_BITS), mémoire adressée par segment:offset comme sur les 386, architectures ou l'espace mémoire est découpé en une partie pour le code et l'autre pour les données (AVR8, par exemple). Le tout en préférant toujours l'approche qui donnera les meilleures performances quitte à avoir un comportement indéfini, ou au mieux, défini par l'implémentation (là au moins on sait ce qu'il se passe pour un compilateur donné).
Je ne pense pas que le langage se prête bien à l'écriture de code sur et sans comportements indéfinis. Donc oui, à mon avis, il serait mieux de changer de langage, même si cela demandera beaucoup d'efforts.
[^] # Re: J’attends toujours un exemple…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 7.
Ce qui m'inquiète là dedans, c'est pas forcément qu'il y aie une limite. C'est plutôt les langages où ça finit par faire une erreur de segmentation ou un autre truc du genre. Résultat, n'importe qui peut faire planter ton API REST en envoyant une requête de 27Ko (c'est à dire pas grand chose).
S'il y a juste une exception et qu'elle peut être interceptée et testée par l'applicatif, je pense que ça n'est pas vraiment un problème à condition que ce soit documenté et que les applications qui en ont besoin (pour des raisons de sécurité et de continuité de service, pas parce qu'elles ont vraiment besoin de parser des très gros fichiers JSON avec 100 niveaux d'imbrication) puissent réagir en conséquence.