YBoy360 a écrit 674 commentaires

quand il y a "ing" à la fin d'un mot, ça veut dire qu'on peut ajouter "entrain de " avant.

Par exemple => "I am mangering" se traduit par "je suis entrain de manger"

c'est ce que j'appelle, à tord, un hack (c'est tout sauf un hack, puisque justement ça permet d'éviter les customisations), il faut faire une interface dbus, mettre tous les WM d'accord, je me rappelle que KDE et Gnome n'était pas d'accord pour faire une interface dbus commune à un moment. Mais tant qu'on peut se débarrasser de la décoration, il n'y a pas de problèmes.

DBus remplace les XAtoms et les fameux window manager hints très limité, auxquelles je me rappelle avoir été confronté, le tout entre plusieurs Unix. Horrible comme souvenir. Je suis bien content de plus m'occuper de ça!

j'utilise Chromium qui n'affiche pas la décoration de Kwin, bon Ok, au début on est pas habitué, mais je m'y suis fait au point de trouver toutes ces décorations identiques entre fenêtres, ennuyeuses.. il y a un gain potentiel de place si les appli dessinent elle-même la décoration, c'est la possibilité de dessiner le menu directement dans la déco, sans passer par des hacks ou Pied ne veut plus rendre ses appli compatible avec petit dragon.

comment peut-on comparer Wayland à DirectFB? Je crois que directFB impose un gestionnaire de fenêtre (un peu comme Weston, ou une implémentation alternative du protocole)?

J'ai l'impression surtout que directFB n'utilise pas EGL, ou que la différence doit être de cet ordre…

c'est dingue, on me dit que mysql n'utilise pas grep!

ils remettent en question la sacro-sainte et énigmatique philosophie de la drosophile à crotte de marsoin en chaleur, si belle par sa pureté resplendissante dans le noire : "si un truc peut faire un truc, alors elle peut tout faire le truc, même d'autres truc, puisque tout est fichier et Kiss" …

pour ceux qui développent en entreprise, OpenERP permet de faire des choses très simplement et rapidement.

L'une des particularités, c'est de pouvoir modifier le modèle existant, ou l'affichage d'une donnée sans affecter le code où celle-ci à été déclarée (utile lors des mise à jour). On peut déployer dynamiquement ces propres modules. Ajouter un workflow est un jeu d'enfant. On peut même faire ses propres appli en utilisant juste les modules de base.

J'ajouterai que le schéma de la base avec les gros modules installés est vraiment TRÈS clair et compréhensible (comparativement d'autres ERP que je ne nommerai pas).

pour 2 : Il vaut mieux faire du "Linux Only", que du "distro only", c'est plus portable.

moi de même, strictement aucun problème avec des Mageia 2. Avant SystemD, il se pouvait que mon ordi ne s'éteigne pas également …

Je tiens à signaler quand même, qu'un des effet de bord sympa de SystemD, c'est la vitesse de boot : j'arrive à 8 secondes avec un core/1 giga sous VirtualBox avec une Mageia 3 (sans compter l'initrd de 2 secondes).

je peux pas éditer le précédant commentaire (on peut ajouter un checksum mais pas de marqueur), mais en fait si la taille est de 100 pour les données non compressé, et que le fichier est corrompu et la taille devient 10, le malloc foire pas et tu as un bel écrasement lorsque tu vas écrire les données.

ça marche par accident de tester si le malloc est NULL dans ce cas.

Ok dans ce cas tu fais ce que j'ai dis plus haut. tu mets un marqueur après ton buffer compressé ou un checksum sur la taille.

1/ Franchement, relis. Puis tu as 2 de QI ou quoi?? si la longueur est supérieur à la taille de ton fichier, tu te doutes qu'il y a un problème non? C'est pas moins c?? que de voir si ton malloc foire.

regarde du code sérialisant des objets, les conteneurs vidéo ou les spec de n'importe quel format de compression, ou la structure de n'importe qu'elle FS.

2/ J'ai l'impression que tu me cherches, Je perds encore une fois mon temps : il n'y a pas de gestion d'erreur spécifique à chaque malloc, regarde le code, TOUS les programmes sérieux/critiques ne font rien d'autre que : soit attendre, soit sortir. Pas de message d'erreur inutile spécifique, pas de je désalloue un truc inutile pour pouvoir continuer, pas de : oui alors je vais revenir dans un état cohérent ou je ne sais quelle autre Microsofterie. Sous Linux, lorsque malloc retourne NULL, t'es même pas sûr de pouvoir faire un appel de fonction…

Maintenant regardes ce qu'il se passe dans le imalloc de init au cas ou un autre goret coderait comme toi : ça part en boucle infinie! Mais c'est pas génial ça!

Dans le monde réel te répondre c'est déjà un peu partir en boucle, en ayant l'impression de devenir un peu moins intelligent à chacun de tes messages.

ça veut dire quoi "beaucoup de gens du domaine", du domaine de quoi?

tu la trouves technique cette discussion au point qu'il faille ranger les intervenants dans un "domaine"?? pas moi. C'est un peu le b.a. ba.

Il ne s'agit pas de ne pas vérifier les erreurs, il s'agit de ne pas pondre du code pour agir spécifiquement au cas ou un malloc retourne null dans un OS moderne. Si tu saisies pas la différence?

A/ n'importe quoi : d'abord on parle de gérer par le code de sortie de malloc au cas ou on donne un paramètre corrompu … mais bon, on est pas à ça près, Je te prends au mot : si mon programme fais un écrasement mémoire, n'est-il pas plus judicieux de cracher ou l'erreur à lieu, plutôt que de se rattraper aux branches pour crasher 0.1 seconde plus tard (mais trop tard, tu sais plus ou est l'erreur à eu lieu)..
regarde la sérialisation de données (ou même, plus généralement n'importe qu'elle structure de données du type FS, compression ou autres), tu croies vraiment qu'il vaut mieux vérifier le retours d'un malloc plutôt que, à la lecture, vérifier les bornes avec une séquence d'octets magigues (du style B16B00B5)

B/ Je pense que tu es payé à me faire perdre mon temps (et aux autres), il n'y a pas de gestion d'erreur spécifique comme je le dis : ces programme ne font rien, RELIS.

donc on peut rien faire, il faut se fier au malloc pour savoir si ton fichier est corrompu… Regarde la structure de n'importe qu'elle système de fichier ou conteneur de données : les allocations se font par chunk. t'es libre de mapper directement tes données en mémoire depuis ton fichier, mais en cas de corruption, c'est pas le malloc qui échoue qui va te renseigner.

Dans l'OS que j'utilise, init/systemD/OpenSSL ne font rien (c.a.d. sortent ou attendent), sous Windows, bah tu me montres un exemple, j'ai pas accès au code.

je comprends pas que tes commentaires soient autant surnotés, si tu codes comme un goret, et que tu mets directement ce que tu scannes en paramètre d'un malloc, un fichier corrompu fera craché ton programme même avec un malloc de 100 qui va réussir …

Il y a une différence entre traiter les erreurs et s'occuper d'un malloc qui retourne NULL. Quand tu scannes ton fichier, c'est là que tu gères l'erreur. Personne n'a sorti un exemple de code critique qui gérait spécifiquement le cas malloc retourne null.

tu devrais essayer d'utiliser Word/Wordpad/MySQL quand tu as plus de mémoire.

sinon, pour "init" (le bon vieux, bien critique)

/*
 *  Non-failing allocation routines (init cannot fail).
 */
static void *imalloc(size_t size)
{
    void    *m;

    while ((m = malloc(size)) == NULL) {
        initlog(L_VB, "out of memory");
        do_sleep(5);
    }
    memset(m, 0, size);
    return m;
}

D'un coté il y a la bonne méthode, de l'autre … l'autre.

il me serait pas venu à l'idée de mesurer un delta en consommation mémoire en regardant VmPeak et encore moins VmSize, sur de si petites modifications (je dis pas que c'est dénué de sens, c'est juste comme mesurer le niveau d'un bassin pour compter les poissons qu'il y a dedans alors qu'on les connait tous par leur nom).

Oui, d'accord, seulement son code ne sert qu'a fermer ce que l'OS ne ferme pas lorsque le process est tué, il ne s'agit pas de faire des choses compliqués genre afficher un message d'erreur ou faire une sauvegarde, il ne maintient aucune variable d'état. C'est exactement ce que je dis de faire (pas traiter l'erreur au cas par cas).

Le problème avec son approche, c'est qu'en fonction des options de compilation et de l'architecture tu ne pourras pas avoir d'info sur l'endroit ou l'erreur à eu lieu. tandis qu'avec un bon vieux SIGSEGV j'ai une info sur l'endroit exacte (c'est discutable du point de vu de l'utilisateur).

ou dans le gestionnaire de signaux, ça serait pas le bon endroit?

c'est exactement ce que je pensais, vouloir tester toutes les allocations, ça n'est pas gratuit en place mémoire, et ça rend le code moins lisible. De plus il vaut mieux un crash net, qui libère des ressources pour que le reste puisse fonctionner.

Je crois que je n'ai jamais vu ce cas de figure (malloc qui retourne null), j'aime pas le code mort.

bah sur le plan de l'architecture il est "simplement stupide" :
-> de garder des outils qui font la même chose séparé (cron, xinet, init ..) avec des config qui leur sont propre,
-> de placer hors d'init des outils censé monitorer/gérer des services.

non, c'est même pas ça pour moi, c'est "faire ça hors d'init, ça oblige à refaire ce que fait init ailleurs".

Inet, xinet, cron et autres, c'est le même type de problématiques, ce sont des outils redondants, en plus chacun à sa propre sémantique pour la configuration.

Maintenir plusieurs outils qui font la même chose en parallèle, c'est super KISS.

c'est exclusif à Windows le format binaire ?? syslog zip les fichiers log, c'est aussi un format binaire.

non, l'une des raison de Journalctl c'est que les meta données sont crées par journald et non par le service (cas syslog). En cas de corruption d'un service, tes logs peuvent être corrompus.

par exemple si veux les logs d'un boot précédant je fais :
# journalctl _BOOT_ID=5cfd5397b3904a4eacfbf599bd20fa17

toutes les lignes de log ont le même format pour les méta-informations, ce qui permet de faire ça simplement. Aujourd'hui c'est compliqué ce genre de requête. à mon avis ajouter toutes ces méta-informations au format texte n'aurait aucun avantage.

Le format binaire n'empêche d'utiliser des outils textes, mais je peux choisir le format texte que je veux avant de le traiter et je peux cibler très rapidement. (c'est étrange que personne n'ait cité cet avantage dans les précédentes discutions).

C'est propre à Gentoo ce problème d'udev et de usr qui peut pas être sur une autre partition?

Je suis globalement d'accord pour dire que certaines nouvelles techno ont mis plus de temps à mûrir qu'elles n'auraient dû, et que d'autres font carrément du tord à l'utilisateur fidèle/final (je pense à Gnome 2.0, je ne connais pas Gnome 3.0). Cependant, j'apprécie énormément SystemD, que j'ai trouvé très simple à prendre en main, et que je trouve très prometteur.

Certes, ça va faire du boulot pour les admin, ça obligera peut-être certains de créer leur propre init (pour l'embarqué je croyais que c'était la règle), mais j'ai du mal à voir en quoi il ne réponds pas aux besoins du plus grand nombre, simplement de manière compréhensible.

Je pense que le mécontentement viens plus de l'admin, qui monitor des applications et surveille le système, qui ne veut surtout pas être emmerder par un truc qui en fait trop, que du développeur qui déteste les forks, les scripts et le code non optimisé.