gnx a écrit 420 commentaires

En x86 pas cher et pas puissant, quelqu'un a testé les Vortex86 qui sont sur les 86duino ? Architecture XX^e siècle, mais boostée en fréquence. Je me demande ce que ça donne comme utilisabilité, ou au moins dans les benchmarks.

Oui, je suis d'accord sur ces points là ; suite au commentaire précédent, j'ai dévié sur ma marotte ARM :-)

D'ailleurs la dernière petite machine que j'ai acheté est une Zbox. Par contre, même en visant le moins puissant et le moins cher, du côté x86, on reste en général :

• dans une gamme de prix supérieure : 3 à 6 fois le prix des petites cartes ARM, et dans le même ordre de grandeur du matériel classique bas de gamme (tour+alim+CM+RAM).
• dans une gamme de puissance supérieure (j'ai pris dans le plus bas de gamme et ça me fait un ordi 3 fois plus puissant que la config principale (antédiluvienne mais qui faisait ce dont j'avais besoin) que j'ai utilisée durant l'année passée.

Donc un peu surdimensionné pour de petits serveurs personnels que peuvent assurer les cartes ARM de 30 à 70€, sans autre problème que le fait qu'il faut effectivement serrer les fesses à cause des composants chinois mal documentés (on peut se demander si les fabricants eux-mêmes savent quels blocs IP ils ont collés dedans), et pour lesquels les noyaux et drivers sont portés à l'arrache, au coup par coup, souvent au pif et par on ne sait trop qui.

D'ailleurs, quand on dit ARM, on devrait inclure tous les procs/SoC conçus avec des patchworks de coeurs CPU et d'IP achetés ailleurs : si ceux à base de MIPS par exemple étaient plus répandus, ce serait le même bazar.

Je ne serai pas aussi impétueux, mais j'avoue que, le monde ARM, je suis en train d'en revenir. Je ne suis pas certain qu'il puisse y avoir "un pas dans la bonne direction" dans ce monde là, tellement il est bordélique.

Mais au final, la version qui pour moi est la plus lisible et efficace est celle-ci :

    /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
    int intcmp(const void* p1, const void* p2) 
    {
        return *(int*)i1 - *(*int*)i2;
    }

… Et ça vient, entre autres, de la concision de l'écriture (moins de choses à lire = moins de choses à comprendre).

Oui, mais c'est la seule qui ne compilera pas :-D

(Quant à l'erreur dans le commentaire, c'est la même que dans les autres versions :-) )

Hum… la canneberge c'est cranberry.

S c’est les bons. Par contre […] pour faire une L il faut être très très “bon”

C'te blague !

À défaut, tu pourrais travailler dans le recherche publique comme ingénieur de recherche par ex

Les places sont très rares et c'est sur concours

Et encore, "concours", c'est le nom officiel pour cacher qu'en pratique, ça tient plus de la cooptation.

Poettering :

We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail. We are writing an OS here for the general purpose, not just a toy for a clique of kernel developers.

J'en ai rencontrés des mecs imbus d'eux-même, mais celui-ci vaut le détour. Quel abruti…

Je pense qu'il veut plutôt parler des 2 if enchaînés sans accolade.

if (flag_file)
if (access(flag_file, F_OK) < 0) {
r = -errno;
goto finish;
}

À moins que je l'aie loupé, p n'est pas affecté ailleurs.

Ah si, mais ça ne change rien (p est toujours et par définition >= 0 avant qu'on lui ajoute k).

   size_t p = 0;

Puis ligne 163 :

           if ((k = read(fd, buffer + p, sizeof(buffer) - p)) <= 0) {
                   r = k < 0 ? -errno : -EIO;
                   goto finish;
           }

           p += k;

           if (p < 1)
                   continue;

À moins que je l'aie loupé, p n'est pas affecté ailleurs.

On a alors :
- k >= 1, sinon on est allé à finish (sortie de la fonction) ;
- p qui vaut 0 au départ et auquel on ajoute une/des quantité(s) strictement positive(s) ;
- donc toujours p >= 1 au moment du test ;
- donc le test ne sert à rien, le continue n'est jamais atteignable.

Je crois avoir lu qu'il y avait des test unitaires sur systemd.
Bon, ça peut se couvrir en TU en faisant un overflow en ajoutant plusieurs fois de grosses valeurs de k, mais quand on voit qu'il faut recourir à ce moyen pour passer dans la branche, ça doit faire se demander si on doit conserver le code et si la conception est correcte.

Ce n'est pas un bug en soi, le bout de code est juste inutile, mais on peut se demander si c'est bien ce qui était voulu, du coup, et si ce n'est pas une erreur. Un commentaire assumant le côté ceinture et bretelle lèverait le doute.

D'une part :

• Il se peut qu'il y ait d'autres causes d'échec de asprintf.

Et d'autre part, t'en parleras à Lennart, alors :

• C'est dans ses règles de codage ;
• C'est verifié dans les autres appels de fonctions du même genre (et même dans le bout de code que j'ai cité, c'est bien ce que fait le test de packet pour le strdup.

Non, là, ce qu'il a fait, c'est qu'il a vraiment voulu tester que asprintf avait bien fonctionné, mais comme c'est un malin, il a fait un seul test commun à strdup et asprintf (les 2 branches du if). Sauf que ça ne marche pas comme ça.

Vers la ligne 102

   if (accept_cached) {
           packet = strdup("c");
           n = 1;
   } else
           asprintf(&packet, "*\002%c%s%n", (int) (strlen(message) + 1), message, &n);

   if (!packet) {
           r = -ENOMEM;
           goto finish;
   }

Bien qu'avant il y ait char *packet = NULL;, rien ne garantit d'après le man de asprintf qu'en cas d'erreur, asprintf n'ait pas changé la valeur de packet par quelque chose de différent de NULL => Boum. Ça commence bien.

Il faut tester le retour de asprintf.

Ou même juste une carrière technique tout court, même inintéressante, ça ne court pas les rues. Le modèle dominant en France est :
- soit tu es dans une grosse boîte et tu ne fais que de la paperasse et de la gestion des sous-traitants (très peu de technique);
- soit tu te fais exploiter chez un sous-traitant (SSII ou autres) qui n'a aucun projet à soi (et aucune idée) où tu valses de contrat en contrat (on ne peut pas parler de carrière).

de bonne foie

de bonne fois.

Attention, au bout de 3 essais infructueux, vos comptes seront bloqués.

Ce que je regarde dans mon taf, c'est de po

Oui, le plus important pour travailler, c'est d'avoir un bon cla

Le temps de parcours est imprécis. Il estime 24 minutes alors que le temps moyen est aux alentours de 20 minutes, soit quand même 25% d'erreur.

4/20=1/5=20%

Décidément… d'une part, je ne parle pas de ça, je parle du fait d'écrire du C non standard. Mais peut-être que Poettering a déclaré que c'est bon pour la portabilité, ça aussi, et génial pour dérouler des tests avec plusieurs compilos, tant qu'on y est. C'est pas comme si ça pouvait aider à trouver des bugs.

Et sinon, pour le truc que vous (deux) ramenez ici, hors propos et qui a déjà été traité 50 fois par les pro et les anti, je recolle la réponse habituelle :
oui, les scripts Debian sont compatibles avec des distributions utilisant des scripts Debian, les scripts RedHat sont compatibles avec des distributions utilisant des scripts RedHat, et les scripts/unités systemd sont compatibles avec les distributions utilisant des scripts/unités systemd. Super.

Mince, les scripts SysV de Debian ne tournaient que sous Debian

Quel rapport ?

Par exemple, ça utilise largement des fonctionnalités de gcc

Donc, ça ne tourne qu'avec un noyau Linux… ça ne compile qu'avec GCC… c'est quoi la suite ? bientôt ça marchera seulement avec une distribution RedHat installée sur un Western Digital tournant sur un Core i5 avec un BIOS AMI ?

100% opensource ? Mouais, ni plus ni moins que la plupart des autres cartes (les cubieboard 2 et cubietruck utilisent le même SoC), j'ai l'impression : tu as le schéma mais par contre, pour ce qui est du SoC (voire de certains composants annexe, je n'ai pas vérifié), ce sont toujours les mêmes problèmes dans le monde ARM : docs inexistantes, incomplètes, fausses et/ou sous NDA, des blobs binaires plus ou moins indispensables suivant les fonctionnalités requises, etc.

Ah le Seigo, brillant représentant des personnages à l'égo hypertrophié gravitant autour de Linux ces temps-ci : le gars s'est pointé il y a quelque temps sur une mailing-list que je suivais depuis plusieurs années, au trafic stable et "sympathique" (j'entends par là ni trop élevé ni trop faible à mon goût, disons entre 5 et 10 messages par jour, au doigt mouillé), il a plus ou moins voulu expliquer à tout le monde qu'ils s'y prenaient mal et comment ils devraient fonctionner d'après lui (de ce que j'en ai suivi, car le type est tellement verbeux qu'il m'a rapidement épuisé), c'est un peu parti en sucette et depuis, il a disparu mais j'ai l'impression que tout le monde a également disparu vu que le trafic est tombé a 1 message par semaine… Belle apparition.

Par contre, des retards de 3 à 6 mois dans l'électronique, c'est plutôt la règle que l'exception, donc il ne faut pas trop être surpris ni inquiet, AMHA. Si en plus, le financement est bancal et l'investissement faiblard, on peut rajouter un peu plus de délai.

La plupart des imprimantes grand public ont depuis quelques temps le Wi-Fi, donc sont des imprimantes réseaux.

s/ensa/oni/

NSFW?

pourquoi ne pas faire du live scroll par paquet de 10 news , cad quand on scroll jusqu'en bas, on charge les 10 news suivantes.

Nooooooooooooooooooon, pitié…