reno a écrit 3881 commentaires

Une version de démo d'une distribution GNU/Linux ça fait bizarre…

Ah? Tu ne connais pas un certain RedHat qui gagne pas mal d'argent en vendant du support pour une distribution Linux?
Pourtant il me semble qu'il est assez connu!

Linutop OS 5.0 pour PC 79.00EUR

Ça inclut du support ?

Ça, c'est une bonne question.

C'est Groklaw, je me permettrai donc d'ignorer totalement ce qui y est ecrit étant donne l'habitude prise sur ce site de choisir les extraits soigneusement et eviter les parties qui ne vont pas dans le sens du site, c'est a dire pro-OSS/Libre.

Tu as tort: connaître le biais du site n’empêche d'en retirer des informations intéressante, dans le cas présent les transcrits me semble suffisamment long pour éviter la distorsion.

Sinon, je vois mal ce que les avocats auraient pu faire contre un gars qui a depose un brevet. Le proces n'a jamais ete sur le fait que les brevets etaient Mal(TM), mais si Samsung/Apple avaient viole des brevets, donc le gars n'avait rien de disqualifiant.

1) Il me semble que les avocats peuvent rejeter des jurés sans avoir à se justifier.
2) Un gars qui a un brevet (logiciel) sera probablement biaisé en faveur des brevets existants, la perception du procès était que c'était Apple qui attaquait Samsung pour violation de ses brevets, même si en fait les plaintes venaient des 2 cotés.
Donc je maintiens: les avocats de Samsung ont mal fait leur boulot.

J'espère que les développeurs de wayland ont la même idée que nous derrière la tête car ce serait juste génial.

?
Je ne comprends pas ta dernière phrase..
Il n'est pas possible d'avoir du NX sur Wayland directement (mais du NX sur du X sur du Wayland oui).

Le monde linux n'a pas l'air de comprendre le principe "c'est tres facile de rendre une api public, extremement dur de la supprimer ensuite".

Les devs du noyau comprennent très bien.
Les bureaux eux ne veulent pas le faire car ils préfèrent se focaliser sur la dernière mode (KDE, Gnome), je me demande si une compatibilité "à la Windows" serait faisable pour des bureaux "stables" genre XFce?

Euh, tu as regardé la polémique sur le rapporteur principal (celui qui a un brevet comme par hasard) qui semble ne pas avoir compris du tout la notion de 'prior art'?
http://www.groklaw.net/article.php?story=20120828225612963

Incompétent ou malhonnête, j'hésite encore..

Ceux qui sont aussi incompétents, ce sont les avocats de Samsung pour avoir laisser un gars avec un brevet dans un jury!

Dire que je pensais qu'Aaron Seigo de KDE était mauvais au niveau communication (les 2/3 de ses blogs sont dur à lire) mais là dans le genre embrouiller le monde "GNOME OS n'est pas une distribution" i.e un OS .. respect! Il faut le faire!

"GNOME integration platform" ça lui aurait arraché la bouche?

Ça dépend de ce que tu entends par là: ils ont commencé par être compatible avec l'existant en supportant un serveur X sur Wayland, donc tu garde la transparence réseau si tu continue a utiliser X.
Maintenant si tu parle de la transparence réseau en utilisant un toolkit Wayland 'natif', effectivement ils ne travaillent pas du tout dessus, mais bon je ne trouve pas ça anormal: d'abord le faire fonctionner en local (et il y a du travail!!), ensuite se poser la question du LAN (qui ne devrait d'ailleurs pas poser trop de problème).
En WAN, ça devrait être la cata par contre, m'enfin même X est pas terrible en WAN: ça fait longtemps que NX aurait du être intégré à X!

décoration gérée par le client = si l'application est occupée, déplacer la fenetre peut être saccadée
C'est à dire ? Je ne vois pas trop pourquoi ça ferait ça, faut dire que j'y connais pas grand chose…

Et bien quand tu clique sur le bord de la fenêtre et que tu maintiens le bouton appuyé pour la déplacer, c'est l'application qui va recevoir le clic(*) et qui va demander au serveur d'affichage "déplace ma fenêtre de X pixel", donc si l'application est occupée le déplacement sera saccadé.

Super comme conception!
Bon, les développeurs de KDE ont prévu d'étendre Wayland pour gérer les décorations coté serveur d'affichage, donc tout n'est pas perdu..

*: dans X c'est le gestionnaire de fenêtre car c'est lui qui gère la décoration des fenêtres.

C'est un raccourci un peu rapide, mais ZFS, DTrace, Capsicum, FreeBSD a des techno impressionantes coté serveur (bon c'est un peu facile quand Sun choisit une license compatible BSD mais pas GPL).
Coté desktop Linux a des avantages (KMS), mais pour ce qui est de Wayland pour moi c'est une régression sur pas mal de point: décoration gérée par le client = si l'application est occupée, déplacer la fenetre peut être saccadée, super comme conception!

Pour le son FreeBSD a OSS intégré dans le noyau ce qui a aussi des avantages: 2 contexte switch en moins (car pas de démon intermédiaire), et ré-échantillonage intégré au noyau..

Sur de petit exemples comme ça, c'est amusant les optimisations de bas niveau, c'est quand tu essaye de faire un "gros" programme que tu vois rapidement l'intérêt des langage de haut niveau comme Python/OCaml..

Tes char tiennent sur 7bits, les originaux sur 8bits sinon c'est amusant comme idée: maximiser la performance du push, au détriment d'avoir un pop/read lent.
Autre méthode avec le même stockage qu'à l'origine:

static inline char fifo_read(fifo_t *f) {
      char res;
      int8 cnt = 0;
      fifo_t copie = *f;
      do {
        res = copie & 0x7f; /*on peut calculer res après aussi */
        copie >>= 8;
        cnt++;
      } while (copie != 0);

      *f &= ~((1 << 8*cnt)-1);
      return res;
}

Après il y a des fonctions qui donne le numéro du bit de poids fort qui peuvent être plus performante mais moins portable.

Hum, la lisibilité c'est important, mais bon pas tant que ça sur du code aussi court..

A mon avis le push pourrait indiquer s'il y a eu overflow ou pas en retournant une valeur.

Tu utilise quel version du C?
Si c'est le C99, un bool est plus lisible que des valeurs "magiques" codés dans un char pour le code retour de sf_pop, après le bool est probablement codé sur un entier que sur un char, mais bon..

Bah, le "& 0xFF" ne sert à rien puisque data est initialisé à 0 au départ et que c'est un unsigned int..

En d'autre terme l'OS a de l'importance.

Les OS ont plus grand chose a apporter a ce niveau.

Jelly Bean et le projet "Butter", ça ne contredis pas ce que tu dis?
Moi j'en ai l'impression..

"Tiens, une femme qui s'intéresse au logiciel libre", sur le même ton que s'il vivait un événement exceptionnel. Si ce n'est pas du machisme je ne sais pas ce que c'est.

Euh, si tu regardes les photos d'un rassemblement de contributeurs du noyau Linux, tu verras qu'effectivement les femmes sont rares, il a donc dis que ce qui lui passait par la tête, ce n'est pas malin ni poli mais pour aller jusqu'à "machiste" il faut rajouter d'autre composante: ton méprisant, condescendant ou autre..

personne n'oserait dire "Tiens, un noir qui s'intéresse au logiciel libre".

Pas si sûr que ça! D'ailleurs il y a pas si longtemps j'ai vu quelqu'un se féliciter que le nom d'un contributeur Linux était asiatique car il y a peu de contributeurs Linux d'origine asiatique, ça revient au même..

Comme le procès Samsung / Apple qui se déroule à l'heure actuelle?
A part montrer le pathétique de la situation à tout le monde ("j'ai patenté le rectangle aux bords ronds", "il m'a copié" / "lui aussi a copié X"), pour le moment ça ne change strictement rien..
Ceci dit, il n'en sont qu'au premier procès, pour que ça change quoi que ce soit, il faudrait que ça monte jusqu'à la cour suprême: pas impossible, mais le processus prend énormément de temps.

Parce que normalement on a des fonctions a plusieurs entrées, quand je dit la fonction qui calcule l'aire d'un triangle, elle a pour paramètre la longueur et la hauteur donc si tu affiches
long -> haut -> résultat, ça ne correspond pas a ma vision normale d'une fonction a entrées multiple, un tuple de variable (j'ai bien compris que c'est possible en Ocaml, j'ai juste été surpris que ça ne soit pas la coutume).

Et en Ocaml, si tu veux avoir plusieurs sorties, tu es obligé d'utiliser un tuple pour les sorties, je trouve qu'il y a une certaine asymétrie mais bon c'est débatable.

L'OS ne compte pas, ce sont les applis qui comptent

Hum, l'IHM de l'OS ainsi que la fluidité des IHMs (qui dépend de l'OS) comptent aussi.

Effectivement je m'était trompé sur le cas avec plusieurs sorties, il faut utiliser un tuple de données donc tu as:
entree1 -> … -> entreeN -> (sortie1, sortie2, …, sortieM)
mais ce que j'aimerais avoir moi c'est:
(entree1, … , entreeN) -> (sortie1, sortie2, …, sortieM)
ça rend l'affichage du type des entrées et des sorties identiques.

C'est possible, mais il faudrait que tu m'explique en quoi je ne sais pas de quoi je parle!
Quand je définis une fonction f(x:int, y:int)->int et que l'interpréteur affiche
f: x:int -> y:int -> int (pas la vrai syntaxe d'OCaml) donc comme une fonction de fonction qui retourne un résultat alors qu'on lui a donné une fonction qui prend 2 valeurs et retourne un résultat.
Certes mathématiquement c'est la même chose, mais visuellement je trouve le choix d'OCaml (et d'Haskell) moins lisible..

Je me demande si le valideur averti du problème de version: il devrait commencer par ça..

J'ai toujours du mal avec les langages qui préfèrent les math aux utilisateurs, je m'explique: pour moi une fonction a des entrées et des sorties mais sous prétexte qu'il y a la curryfication, au lieu d'avoir des fonction avec plusieurs entrées et plusieurs sorties, on a: fonction: entree1 -> entree2 -> … sortie1 -> sortie2 (1)
Beurk, ce n'est pas parce que la curryfication existe qu'il faut la montrer systématiquement!

1: par exemple si on tape le programme du dessus dans l'interpréteur OCaml on a en sortie:
val process_file : (in_channel -> 'a) -> string -> 'a = < fun >
mais la fonction dans le code du programme avait des entrées et des sorties, pourquoi l'interpréteur n'affiche pas:
val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
ça serait beaucoup plus fidèle au code..

Quand tu es un abattoir, tu as 3 options:
1-ne pas faire de halal: tu perds environ 7.5% du marché.
2-faire du halal pour tous (sans le dire): 7.5% de marché potentiel en plus.
3-avoir 2 filières séparée, même marché que (2) mais à priori plus cher.

Je ne suis pas expert mais ça me parait logique que les abattoirs choisissent (1) ou (2).
(1) dans les régions où il y a peu de musulmans mais personne n'en parle, (2) dans les autres et là ça fait débat..